I suppose I could rig up something that looks at the status of A, and remotely kills B if I hasn't seen any packets recently - and vice-versa, but it sure would be better for openvpn to be able to detect that internally.
Unfortunately, since my situation is using tap devices (it's a bridge to a remote data center), it doesn't appear to let me set IPs on the tap devices, or at least I haven't had any luck communicating with those IPs if I configure them. That rules out implementing keepalives externally since I can't seem to force traffic to go over the tap devices. I could probably write raw ethernet frames, but receiving them on the other end would likely be problematic... -- Nathan ------------------------------------------------------------ Nathan Neulinger nn...@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Principal KD0DMH > -----Original Message----- > From: Neulinger, Nathan [mailto:nn...@mst.edu] > Sent: Saturday, December 26, 2009 5:56 PM > To: openvpn-de...@lists.sf.net > Subject: [Openvpn-devel] Inability of openvpn to detect partial failure > ofUDP link > > As currently written, openvpn appears to be unable to detect the > partial > failure (unidirectional) of a UDP based tunnel. > > Attached is a note I sent to i...@openvpn.net about this yesterday, > figured I'd mention progress on the devel list as well. > > Basic summary, assume bridged link from A <-> B, and a unidirectional > failure, openvpn configured with keepalives: > > A ------> B > A: sends pings, never gets any traffic or ping packets, constantly > restarts/exits > B: sends pings (they never actually make it to A), but sees pings > from A, thinks everything is fine. > > I've written some code to implement a ping request/reply facility - > however, here's where I'm hitting up against a secondary snag. It looks > like in the code right now, there isn't really any way to cleanly > request a packet be sent. encrypt_sign() sortof appears to do this, > but, > with how it (and the other code is implemented), it appears to only > permit a SINGLE packet to be generated by ANY of the various tasks > spawned off in the event loop. > > If a second packet is generated in the same pass through the event > loop, > the packet waiting to be sent by process_io just gets stomped > on/overwritten silently. > > I fully believe that this stomping has the potential to occur during > other regular activity as well, but it may just be that it is > ordered/timed in a way that it doesn't usually cause any issue. For > example, if an OCC reply was sent in the same interval as a ping, the > ping is always going to be overwritten, but in that case w/ default > code, the ping isn't important since sending the OCC packet will have > the same effect. > > It seems like some sort of combination of: > * short circuit the event loop as soon as a single packet is queued > * reduce minimum (while no other I/O) event_wait time > > or - much more invasively, implement ability to queue multiple packets > to be sent. > > Any thoughts on this issue? > > -- Nathan > > ------------------------------------------------------------ > Nathan Neulinger nn...@mst.edu > Missouri S&T Information Technology (573) 612-1412 > System Administrator - Principal KD0DMH >
