From: Joan D. <jd...@ci...> - 2016-04-25 15:21:28
|
Hello, I'm trying to improve the Dead Peer Detection in order to reduce the traffic (it's a client request). The idea is to send the R_U_THERE packet only if there isn't any incoming traffic the last DPD delay time, instead of sending this packet every DPD delay time, regardless of the incoming traffic. This is the same approach used in different DPD implementations like Openswan. The code should be reschedule the R_U_THERE packet every time there is any incoming traffic, like this: iph1->dpd_fails = 0; sched_cancel(&iph1->dpd_r_u); isakmp_sched_r_u(iph1, 0); But the problem is I can't find where is managed all the incoming traffic, especially the ESP packets. My question is, where is managed all the incoming traffic? Otherwise, another option it's just to know when was received the last packet, and use this information to reschedule the R_U_THERE packet. But I don't know if it's possible to get such information. Could someone help me? Thanks! Best regards, Joan |
From: Rainer W. <rwe...@mo...> - 2016-04-25 15:45:01
|
Joan Duran <jd...@ci...> writes: > I'm trying to improve the Dead Peer Detection in order to reduce the > traffic (it's a client request). The idea is to send the R_U_THERE > packet only if there isn't any incoming traffic the last DPD delay > time, instead of sending this packet every DPD delay time, regardless > of the incoming traffic. This is the same approach used in different > DPD implementations like Openswan. > > The code should be reschedule the R_U_THERE packet every time there is > any incoming traffic, like this: > > iph1->dpd_fails = 0; > sched_cancel(&iph1->dpd_r_u); > isakmp_sched_r_u(iph1, 0); That's not a good idea because you'll end up re-scheduling the timer in very quick succession (whenever an ESP datagram is received). A better idea is to use a simple, periodic timer and check if there was traffic during the last interval: If so, the timer's just re-scheduled, otherwise, an R_U_THERE is sent. > But the problem is I can't find where is managed all the incoming > traffic, especially the ESP packets. > > My question is, where is managed all the incoming traffic? The kernel does this. The racoon (fork) my employer uses utilizes such a scheme: It's based on an additional AF_KEY msg (I added to the [Linux] kernel) which can be used to read the octet counters associated with a kernel ph2 SA (aka XFRM state). In this way, the IKE daemon can work out if new data was received since the last check and then send or not send a DPD probe. |
From: Joan D. <jd...@ci...> - 2016-04-27 10:37:18
|
Thank you Rainer for your advise! I'm trying to modify the ph1handle struct in order to add some variables to check the traffic, but after adding any variable, the racoon daemon always crash. Do you have any clue? ________________________________________ De: Rainer Weikusat <rwe...@mo...> Enviat el: dilluns, 25 / abril / 2016 17:44 Per a: ips...@li... Tema: Re: [Ipsec-tools-devel] Improved DPD Joan Duran <jd...@ci...> writes: > I'm trying to improve the Dead Peer Detection in order to reduce the > traffic (it's a client request). The idea is to send the R_U_THERE > packet only if there isn't any incoming traffic the last DPD delay > time, instead of sending this packet every DPD delay time, regardless > of the incoming traffic. This is the same approach used in different > DPD implementations like Openswan. > > The code should be reschedule the R_U_THERE packet every time there is > any incoming traffic, like this: > > iph1->dpd_fails = 0; > sched_cancel(&iph1->dpd_r_u); > isakmp_sched_r_u(iph1, 0); That's not a good idea because you'll end up re-scheduling the timer in very quick succession (whenever an ESP datagram is received). A better idea is to use a simple, periodic timer and check if there was traffic during the last interval: If so, the timer's just re-scheduled, otherwise, an R_U_THERE is sent. > But the problem is I can't find where is managed all the incoming > traffic, especially the ESP packets. > > My question is, where is managed all the incoming traffic? The kernel does this. The racoon (fork) my employer uses utilizes such a scheme: It's based on an additional AF_KEY msg (I added to the [Linux] kernel) which can be used to read the octet counters associated with a kernel ph2 SA (aka XFRM state). In this way, the IKE daemon can work out if new data was received since the last check and then send or not send a DPD probe. |
From: Rainer W. <rwe...@mo...> - 2016-04-29 17:52:45
|
Joan Duran <jd...@ci...> writes: > Thank you Rainer for your advise! > > I'm trying to modify the ph1handle struct in order to add some > variables to check the traffic, but after adding any variable, the > racoon daemon always crash. > Do you have any clue? You could try a rebuild from scratch (make clean; make) to ensure that the header changes (you should have changed the struct ph1handle or struct ph2handle in handler.h) are actually known to all code. Apart from that, "it crashes" doesn't exactly communicate much about the problem. Running with 'log debug;' (in racoon.conf) might provide some inside. Or enable core dumps (usually disabled on Linux), eg ulimit -c 32768 and run the server in forgeground from this shell (racoon -F). After it crashed, there should be a file named core in the current directory. This can be loaded into a gdb session, gdb racoon core to enable post-mortem debugging of the issue. |
From: Joan D. <jd...@ci...> - 2016-04-29 21:52:58
|
Thank you Rainer, you are so right. I'm working in an embedde device and using bitbake as a crosscopile tool, and I assumed it always rebuild everything, which is wrong. After clean the project, I rebuilded it and now works. Thank you again, Joan ________________________________________ De: Rainer Weikusat [rwe...@mo...] Enviat el: divendres, 29 / abril / 2016 19:52 Per a: ips...@li... Tema: Re: [Ipsec-tools-devel] Improved DPD Joan Duran <jd...@ci...> writes: > Thank you Rainer for your advise! > > I'm trying to modify the ph1handle struct in order to add some > variables to check the traffic, but after adding any variable, the > racoon daemon always crash. > Do you have any clue? You could try a rebuild from scratch (make clean; make) to ensure that the header changes (you should have changed the struct ph1handle or struct ph2handle in handler.h) are actually known to all code. Apart from that, "it crashes" doesn't exactly communicate much about the problem. Running with 'log debug;' (in racoon.conf) might provide some inside. Or enable core dumps (usually disabled on Linux), eg ulimit -c 32768 and run the server in forgeground from this shell (racoon -F). After it crashed, there should be a file named core in the current directory. This can be loaded into a gdb session, gdb racoon core to enable post-mortem debugging of the issue. ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Ipsec-tools-devel mailing list Ips...@li... https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel |