DnsIssues

Category:Sasecurity
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!
Category:Mesh
Category:Mesh dns