FANDOM


back to http://scratchpad.wikia.com/wiki/Sasecurity

Thanks for sharing this info with me guys. Roy, I've actually been logged in and seen vtund error messages on this node! Therefore I suspect there is a bug with vtund under certain conditions that maybe exist when connected via a crossover??? I can't see how this would differ than being connected through a hub or switch, but you never know - I've seen stranger things.

I suppose at this point, since I have a spare hub (not a switch) - I will try that option. If that works, I will share the results with the list.

I have one node that does this (mine), I have the main network node (X2) in the loft and my test node on the bench. The one on the bench does exactly what you are experiencing, it is connected to the firewall by a cross over cable, it did it a lot but has just started to get more infrequent.

The strange thing is I used to be connected directly to the node in the loft and that used to hang and need rebooting, I moved to the one on the bench and that did the same and the one in the loft stopped hanging, this was all on build25dev85.

Since moving to build25dev87 the node on the bench hardly ever hangs but does loose the gateway and internet connectivity. I have checked logging on the node and notice that there is a problem with vtund each time this happens but I am still investigating.


14/07/2004 03:17 Daemon.Info 192.168.50.2 vtund[25614]: Terminated

14/07/2004 03:17 Daemon.Info 192.168.50.2 vtund[25614]: Connecting to 1.200.5.46

14/07/2004 03:17 Daemon.Info 192.168.50.2 vtund[29737]: VTun client ver 2.6 06/04/2003 started

14/07/2004 03:17 Daemon.Info 192.168.50.2 vtund[29737]: Connecting to 1.200.5.46

14/07/2004 03:17 Daemon.Info 192.168.50.2 vtund[29737]: Session gateway131[1.200.5.46] opened

14/07/2004 03:17 Daemon.Info 192.168.50.2 vtund[29737]: ZLIB compression[level 2] initialized.

14/07/2004 03:17 Daemon.Info 192.168.50.2 vtund[29737]: BlowFish encryption initialized

14/07/2004 03:17 Daemon.Info 192.168.50.2 vtund[29737]: Traffic shaping(speed 2048K) initialized.

14/07/2004 03:17 User.Notice 192.168.50.2 /sbin/hotplug: no runnable /etc/hotplug/net.agent is installed

14/07/2004 03:18 User.Notice 192.168.50.2 /sbin/hotplug: no runnable /etc/hotplug/net.agent is installed

14/07/2004 03:18 Daemon.Error 192.168.50.2 modprobe: modprobe: Can't locate module br1

14/07/2004 03:18 Daemon.Error 192.168.50.2 modprobe: modprobe: Can't locate module wlan1

14/07/2004 03:18 Daemon.Error 192.168.50.2 modprobe: modprobe: Can't locate module wlan1

None of the nodes with clients connect via switches/hubs have the problem.

Cheers!

Roy.


I've encountered an weird DNS issue that I hope others may have seen & resolved:

I have a client that has a desktop PC plugged into a MeshAP that is located at his house. They are connected via a crossover cable. There are also wireless clients that are in his neighborhood.

They will be surfing away, when suddenly, for no reason, the internet connectivity drops out. The box is still logged onto the network; you have excellent ping times to neighbors; and the SNR is great. It just quits - usually for about 30 seconds, then resumes.

This client has 2 separate pathways to the internet. Both paths are 3 hops. I have even blocked one neighbor to force it to take one pathway over another, and vice-versa. No matter which pathway it uses.. the same results. Therefore I don't think the bug is in one of the boxes "downstream", unless it's the gateway - and if so, other boxes should see similar problems.

It seems to happen when the wired client is active (via the crossover cable). The client runs WinXP and everything is setup normal (obtain ip automatically - obtain DNS automatically). However, I've shelled into the box and watch it do this. When this happens, it even quits pinging the gateway, and occasionally even goes into the "searching for gateway..." mode. However, you can *still* ping the neighbor nodes... you just can't ping the gateway or the internet.

Ok - to eliminate the possibility of a screwy box, I replaced the box (standard old-style MeshAP w/ 32mW PCI adapter) with an identical box in which I placed a brand new radio card & a DOM module for boot. The new box does the same thing with a freshly loaded MeshAP OS and a brand new radio!

I don't think that it could possible be interference either, as one neighbor node is within clear LOS.

Does anyone know if having a client pc attached to eth0 via an ethernet (crossover) cable can cause the MeshAP to "hang" for 30 seconds or so? Could there be anything in this client's WinXP configuration that would barrage the MeshAP with so much data it would temporarily freeze? The client PC is the only common denominator - I've just about eliminated everything else!

Or, is there something else I might be missing in this?? Your thoughts are welcome!