NodeMax

Category:Sasecurity
back to http://scratchpad.wikia.com/wiki/Sasecurity
=== Meshboxes not rebooting properly ===
41 miles ?? I'm amazed it's working at all! That's way, way beyond 
anything we've even thought of doing except for experimental fun, and it's 
stretching 802.11b to the breaking point. You can't expect good data-rates under 
such circumstances.
> For the purpose of bandwidth testing, we turned #1 box off, and 
connected
to
> #2 (the central box) via wireless. Downloads from #3 network were 
peaking
> 20KB/sec
> Have checked WiaNa and settings seem ok. (although I have "enable haping"
> and "optimise traffic" set to NO until I find the problem with 
speeds) I
> have however discovered a problem with some duplicate packets during 
ping
> tests.
> example:
> (between box #2 and #3)
> 64 bytes from 1.136.95.32: icmp_seq=15550 ttl=64 time=22.881 ms
> 64 bytes from 1.136.95.32: icmp_seq=15550 ttl=64 time=38.679 ms 
(DUP!)
> 64 bytes from 1.136.95.32: icmp_seq=15551 ttl=64 time=20.681 ms
> 64 bytes from 1.136.95.32: icmp_seq=15551 ttl=64 time=28.541 ms 
(DUP!)
> 64 bytes from 1.136.95.32: icmp_seq=15552 ttl=64 time=15.883 ms
> 64 bytes from 1.136.95.32: icmp_seq=15553 ttl=64 time=5.411 ms
> 64 bytes from 1.136.95.32: icmp_seq=15553 ttl=64 time=18.159 ms 
(DUP!)
> 64 bytes from 1.136.95.32: icmp_seq=15554 ttl=64 time=6.370 ms
> 64 bytes from 1.136.95.32: icmp_seq=15555 ttl=64 time=26.652 ms
> 64 bytes from 1.136.95.32: icmp_seq=15555 ttl=64 time=50.886 ms 
(DUP!)
> 64 bytes from 1.136.95.32: icmp_seq=15555 ttl=64 time=52.652 ms 
(DUP!)
>
> (between box#1 and #3 via #2)
>
> 64 bytes from 1.93.110.174: icmp_seq=0 ttl=63 time=122.969 ms
> 64 bytes from 1.93.110.174: icmp_seq=1 ttl=63 time=9.644 ms
> 64 bytes from 1.93.110.174: icmp_seq=2 ttl=63 time=75.885 ms
> 64 bytes from 1.93.110.174: icmp_seq=3 ttl=63 time=20.273 ms
> 64 bytes from 1.93.110.174: icmp_seq=4 ttl=63 time=56.776 ms
> 64 bytes from 1.93.110.174: icmp_seq=4 ttl=63 time=101.221 ms (DUP!)
> 64 bytes from 1.93.110.174: icmp_seq=6 ttl=63 time=49.440 ms
> 64 bytes from 1.93.110.174: icmp_seq=6 ttl=63 time=107.731 ms (DUP!)
> 64 bytes from 1.93.110.174: icmp_seq=6 ttl=63 time=136.114 ms (DUP!)
>
> Obviously the ping tests were not running when testing bandwidth.
>
> The distance between the links is quite large, #1 is 14 miles from 
#2. #2
is
> 41 miles from #3
> # 1 cannot see #3 without going through #2
> Would adjusting preamble help? if so, how do I go about it?
> > out of interest, how many nodes are you running that can see each 
other
> (at least some
> > of the time)?
> >
> > We have seen issues with scaleability - eg once you get up to say 
ten
> nodes in a mesh
> > then the routing falls over and needs judicious application of 
manual
> blocknode
> > commands to restabilise.
> > > Thanks Ken, think that has sorted things out, however now our 
boxes
> > > are stable we have been able to carry out bandwidth tests. Speeds 
are
> > > terrible, 20k/sec at best while signal strengths vary but are all
> > > between -60dBm and -72dBm with 15-20 SNR
> > >
> > > Any hints/tips on where the traffic shaping settings should be 
for
> > > best throughput?
> > > > Our equipment worked fine until we started moving around the
> > > > channels. Setups vary, all are P2 400MHz or higher with between 
32mb
> > > > and 128mb of ram all are using netgear MA311 PCI adapters. 
Software
> > > > is build25dev81
> > > > All nodes should have a minimum of 64mb of ram and perhaps dev85
> > > > would be a good move.