Menu
▾
▴
[Openvpn-users] Re: Follow-up on error: MULTI: Outgoing TUN queue full
|
From: Daniel B. <da...@da...> - 2006-02-06 17:22:41
|
Jeff thank you for the hint and sorry for the late answer. That fixed it. Strange thing that the TLS layer is the only one checking for that write timeout. This gets me to one last hurdle which is the browsing of foreign Windows workgroups missing a Domain Master Browser by Windows clients through a P2P tunnel. There is a solution for basically any setup possible using only one Samba machine inside the WAN using WINS, DMB or PDC, browse lists synchronization, etc. so as to have VPN clients resolve and browse most WAN servers and services except ad-hoc workgroups without a DMB. Since Samba is not presently able to perform as a DMB for more than one domain or workgroup, I believe implementing a solution at that level is overly complicated. A Windows client first broadcasts a name query for a <1D> LMB for the workgroup which doesn't traverse the tunnel. It then queries the WINS server for <1B> DMBs for the workgroup but the workgroup has none. Another LANMAN query is finally performed which is even less likely to succeed. WINS never stores or returns <1D> type records and having Samba translate <1B> queries to <1D> local broadcasts comes with so much additional headaches that it's likely easier to just switch everything to TAP and review any firewall and network security policies concerned. The VPN however could have a minimum of diligence to forward <1D> requests to a configurable list of local WAN broadcast addresses which would theoretically provide a transparent access to all browsing services available on the WAN. If Windows LMBs are capable of answering broadcast requests from external IPs the configuration option shouldn't even concern the VPN server and could just be pushed to the client. Question is whether I was clear enough and since I don't believe plug-ins can handle packet mangling yet, whether the issue is interesting enough to have some room in the main code branch. Daniel ----- Original Message ----- From: "Jeff Stearns" <jps...@sa...> To: "Daniel BODEA" <da...@da...> Sent: Monday, January 30, 2006 3:25 AM Subject: Re: [Openvpn-users] Follow-up on error: MULTI: Outgoing TUN queue full > One thing to check is your tunnel driver. I found a bug in the poll > () function in one of the tun drivers; it causes problems like this. > I posted a message about it about 2 months ago. I think that the > patch is now mentioned in the OpenVPN INSTALL or README document. > > -jeff stearns > > On Jan 29, 2006, at 11:52 AM, Daniel BODEA wrote: > > > Hey everyone, > > > > The snippet below is the last piece I saw on this issue so I'm > > following up > > on it. I have the same problem on a 2.2 Linux and I won't be able > > to migrate > > to 2.4 for some time so I have to find a solution in the mean time. > > > > I have a few more details besides everything that's been already said. > > > > The whole thing seems to work like a charm with a shared static > > key, TCP and > > UDP. No problem whatsoever. If however I switch the configuration > > files to > > use PKI keys and certificates, with TCP I get the "queue full" > > error and > > with UDP the tunnel just hangs and restarts upon timeout. I believe > > these > > two symptoms coincide because they both occur when I initiate some > > large > > transfer through the tunnel. The tunnel seems to hold indefinitely > > with > > small packets, pings and all but then I haven't waited that long > > either so I > > couldn't say if it's related to buffers filling up or events > > triggering too > > fast. > > > > I'm a developer myself and I'm willing to have a take at the code > > but I > > don't have _that_ much time either which means I require some educated > > pointers and guesses. So based on this new data, can anyone > > translate the > > problem to some potential fix points in the code? I'm sure it works > > ok with > > static keys so would it be fair to say it's not related to the TUN/TAP > > driver? > > > > Daniel > > > > [snip] > > > > On Sat, 17 Sep 2005, cisco wrote: > > > >> Le vendredi 16 septembre 2005 ?3:15 +0200, Holmberg, Magnus - Flygt > >> (External) a ?it : > >> > I Get a lot of > >> > > >> > Fri Sep 16 12:39:09 2005 us=547188 mymachine/X.X.X.X:4374 MULTI: > >> > Outgoing TUN queue full, dropped packet len=78 > >> > > >> > in my log and the vpn tunnel hangs. > >> > > >> > > >> > Anyone know how to solve this? Does it work if I downgrade to an > >> old > >> > version? If so how old and are there any security issues with the > >> > older versions? > >> > > >> > I currently use 2.0.2 version > >> > > >> > BR > >> > > >> > Magnus > >> > >> > >> I have the same problem this sumer whith openvpn 2.0 linux 2.2.25 > >> > >> I made a copy of topic > >> > >> The only way I made it work is on Kernel 2.4 > >> > >> all the best > >> > >> > Subject: Re: [Openvpn-users] MULTI: Outgoing TUN queue full, > >> dropped > >> packet openvpn 2.0 linux 2.2.25 > >> > Date: Tue, 12 Jul 2005 11:51:33 -0600 > >> > > >> > On Tue, 12 Jul 2005, cisco wrote: > >> > > >> > > every thing work well, until the VPN froze for few minutes > >> > > > >> > > on the server I get the log > >> > > > >> > > openvpn/83.214.128.57:65036 MULTI: Outgoing TUN queue full, > >> dropped > >> > > packet len=40 > >> > > > >> > > I try in proto udp it does the same except than it crash > >> > > > >> > > us=595883 Assertion failed at multi.c:1559 > >> > > > >> > > James Change Log:2004.12.20 -- Version 2.0-rc6 > >> > > speak about some change > >> > > " Made the "MULTI TCP: I/O wait required blocking in > >> > > multi_tcp_action, action=7" error nonfatal and replaced > >> > > with "MULTI: Outgoing TUN queue full, dropped packet". > >> > > So far the issue only seems to occur on Linux 2.2 > >> > > in --mode server --proto tcp mode. It occurs when > >> > > the TUN/TAP driver locks up and refuses to except > >> > > new packet writes for a second or more." > >> > > http://openvpn.net/archive/openvpn-users/2004-12/msg00563.html > >> > > > >> > > What is the solution ??? > >> > > > >> > > Openvpn 2.0 > >> > > linux 2.2.25 > >> > > tun 1.1 http://vtun.sourceforge.net/tun/index.html > >> > > > >> > > Ps: I try on a knoppix 2.4.26 with the same config I did not > >> succeed > >> to > >> > > stalled it > >> > > >> > Yes, this has been reported a few times, but only on Linux 2.2. I > >> would take a > >> > look at it, though I don't currently have access to a 2.2 box. > >> > > >> > Here's a patch to try: > >> > > >> > --- event.c~ 2005-04-10 21:43:56.000000000 -0600 > >> > +++ event.c 2005-07-12 11:39:01.997309472 -0600 > >> > @@ -37,6 +37,8 @@ > >> > > >> > #include "memdbg.h" > >> > > >> > +#define SELECT_PREFERRED_OVER_POLL > >> > + > >> > /* > >> > * Some OSes will prefer select() over poll() > >> > * when both are available. > >> > > >> > this would help to confirm or rule out the possibility that the > >> change > >> > from select (in 1.6) to poll (in 2.0) might be causing the problem. > >> > > >> > James > >> > >> Sorry for the delay > >> > >> I try your patch but the problem still the same > >> do you have a other idea > > > > It's not clear to me whether this is a bug in OpenVPN or the Linux 2.2 > > tun/tap driver. Someone with access to Linux 2.2 needs to debug > > this. I > > might be willing to volunteer if someone provides me access to a box. > > > > James > > > > [/snip] > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through > > log files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD > > SPLUNK! > > http://sel.as-us.falkag.net/sel? > > cmd=lnk&kid=103432&bid=230486&dat=121642 > > _______________________________________________ > > Openvpn-users mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openvpn-users |
