I'm running 5 nodes in 11b ahdemo + vap configuration, everything unbridged and on separate subnets, even lan ports. It's really self-explanatory, but for the uninitiated - being poor and not having money for a "proper" mesh router with two or more wireless cards I'm running batman on ahdemo interface for mesh routing and each router also has a vap for client access (atheros hardware here, Broadcom routers 105.0.4.4 and 105.0.4.5 attach to the mesh via another vap). I have chosen 11b over 11g for slightly better range and better stability.
I'm experiencing strange behavior. Throughput between notes is roughly 2mbits (around 300KB/sec scp transfers).
I have included my digraph in PS so that you can better visualize my network.
After a minute, for example node 5 would stop responding to pings from node 3, or node 1 from 4 etc, so basically two-hop nodes, direct neighbours always seem ok. But the funny thing is that hosts on the internet, i.e. traffic that goes to the tunnel always respond to pings. I have tried experimenting with one-way tunnel mode but I have been unsuccessfull. Tried "--one-way-tunnel 1 --two-way-tunnel 0" on both gw and client batman nodes but nothing happens, batmand -c -d 2 always shows 2WT capability for the gateway.
I have tried --dups-ttl 2 --re-brc-delay 15 --window-size 100 (reading from bmx tutorial pdf) and it has helped somewhat, but not completely. The problem is still there but to a lesser extent.
I don't know whether this is down to ahdemo (maybe Antonio can help here with his experience) or down to batman. Any ideas?
Also, is my throughput ok compared to yours? The most I ever got was around 450KB/s (roughly 5.5mbits data rate, distance 100m outside with 9dbi omni antennas and atheros 5112 - buffalo whr-hp-ag108 at both ends) but the 11Mbits evades me - even on a -55 signal and 40 rssi! It really is heart breaking, especially seeing such a good signal. Two nodes roughly 300m apart get 240KB/s at most. I know better is possible because in ap mode with that signal I used to get 1MB/s transfers (that was before I started using batman and ahdemo).
Best regards,
Pele
P.S. digraph topology { "105.0.4.4" -> "105.0.4.5"[label="1.15"] "105.0.4.4" -> "105.0.3.3"[label="1.05"] "105.0.4.4" -> "10.0.4.0/255.255.255.0"[label="HNA"] "105.0.4.4" -> "10.1.4.0/255.255.255.0"[label="HNA"] "105.0.4.4" -> "105.0.2.4/255.255.255.255"[label="HNA"] "105.0.3.3" -> "105.0.0.1"[label="1.16"] "105.0.3.3" -> "105.0.4.4"[label="1.19"] "105.0.3.3" -> "105.0.3.2"[label="1.05"] "105.0.3.3" -> "105.0.4.5"[label="1.12"] "105.0.3.3" -> "10.0.3.0/255.255.255.0"[label="HNA"] "105.0.3.3" -> "10.1.3.0/255.255.255.0"[label="HNA"] "105.0.3.3" -> "105.0.0.3/255.255.255.255"[label="HNA"] "105.0.3.3" -> "105.0.2.3/255.255.255.255"[label="HNA"] "105.0.3.3" -> "105.0.1.3/255.255.255.255"[label="HNA"] "105.0.4.5" -> "105.0.4.4"[label="1.27"] "105.0.4.5" -> "105.0.3.3"[label="1.03"] "105.0.4.5" -> "10.0.5.0/255.255.255.0"[label="HNA"] "105.0.4.5" -> "105.0.2.5/255.255.255.255"[label="HNA"] "105.0.3.2" -> "105.0.0.1"[label="1.03"] "105.0.3.2" -> "105.0.3.3"[label="1.03"] "105.0.3.2" -> "10.0.2.0/255.255.255.0"[label="HNA"] "105.0.3.2" -> "10.1.2.0/255.255.255.0"[label="HNA"] "105.0.3.2" -> "105.0.0.2/255.255.255.255"[label="HNA"] "105.0.3.2" -> "105.0.2.2/255.255.255.255"[label="HNA"] "105.0.3.2" -> "105.0.1.2/255.255.255.255"[label="HNA"] "105.0.0.1" -> "105.0.3.3"[label="1.03"] "105.0.0.1" -> "105.0.3.2"[label="1.01"] "105.0.0.1" -> "10.0.1.0/255.255.255.0"[label="HNA"] "105.0.0.1" -> "10.1.1.0/255.255.255.0"[label="HNA"] "105.0.0.1" -> "105.0.2.1/255.255.255.255"[label="HNA"] "105.0.0.1" -> "105.0.1.1/255.255.255.255"[label="HNA"] "105.0.0.1" -> "0.0.0.0/0.0.0.0"[label="HNA"] }
Hi,
On Mittwoch 12 Dezember 2007, Predrag Balorda wrote:
I'm running 5 nodes in 11b ahdemo + vap configuration, everything unbridged and on separate subnets,
the attached dot file is a good idea. It really helps to imaging part of your setup - but not all of it :-(
I am not sure which of the annouced HNAs are interfaces and which not. Is each batmand running only on one interface?
If not, do you open multiple vap ahdemo interfaces per node? That might not work and I am not sure if it makes sense.
When you say different subnets - what netmasks are used for: 105.0.4.4 105.0.4.5 105.0.3.3 105.0.0.1 105.0.3.2
After a minute, for example node 5 would stop responding to pings from node 3, or node 1 from 4 etc, so basically two-hop nodes, direct neighbours always seem ok.
so I guess 5 is 105.0.4.5 and 3 is 105.0.3.3 ? Confusing because according to your dot file these two are in fact neighbors, maybe via 105.0.2.5 <-> 105.0.2.3
But that might mean, that batman on node *.3 is running on FOUR interfaces : *.3.3, *.0.3, *.1.3, *.2.3 And is *.1 running on THREE interfaces *.0.1, *.1.1, *.2.1 So these two nodes are potential neighbors via 3 links ????
If you are meshing via wlan interface and the nodes have only one wlan interface then batman should operate only one one interface (vap or not).
But the funny thing is that hosts on the internet, i.e. traffic that goes to the tunnel always respond to pings. I have tried experimenting with one-way tunnel mode but I have been unsuccessfull. Tried "--one-way-tunnel 1 --two-way-tunnel 0" on both gw and client batman nodes but nothing happens, batmand -c -d 2 always shows 2WT capability for the gateway.
Hmm, should work. You are using the same revision on all nodes? Which one? Note, you can not change one/tow-way-tunnel parameter on the fly. You must restart the daemons to change them. Also note that it takes a while (Duplicate Address Detection) until a restarted node is accepted by its neighbors. Afterwards the client node should show the 1WT with -d2. Example:
on the GW-node: ~# killall bmxd ~# bmxd -g 5000 --one-way-tunnel 1 --two-way-tunnel 0 eth1:bmx
Then on the GW-client node ( which is already runnging as bmxd -r 3 --one-way-tunnel 1 --two-way-tunnel 0 ath0:bmx )
bmxd -cd3 [ 3512899] Drop packet: DAD alert! OGM from 103.131.83.5 via NB 103.131.83.5 with out of range seqno! rcvd sqno 22828, last valid seqno: 39757 at 3489200! Maybe two nodes are using this IP!? Waiting 51 more seconds before reinitialization...
...wait 51 more seconds and you'll see...
[ 3564050] Drop packet: DAD alert! OGM from 103.131.83.5 via NB 103.131.83.5 with out of range seqno! rcvd sqno 22862, last valid seqno: 39757 at 3489200! Maybe two nodes are using this IP!? Waiting 0 more seconds before reinitialization... [ 3565740] Gateway class of originator 103.131.41.5 changed from 0 to 49, addr 103.131.41.5, new supported tunnel types -, OWT [ 3566200] Adding default route to 103.131.41.5 (gw_flags: 49, packet_count: 1, gw_product: 0) [ 3566210] Gateway client - client_to_gw_tun() [ 3566210] Trying to name tunnel to bat0 ... [ 3566230] success! [ 3566240] Adding default route via bat0 0.0.0.0 (table 148)
root@ng1e:~# /tmp/bmxd --neta -cbd 2 WARNING: You are using BatMan-eXp 0.3-alpha rv867 (compatibility version 13) ! Originator bestNextHop (#/ 50) => 103.131.41.5 103.131.83.5 ( 50), gw_class 49 - 4MBit/1024KBit, reliability: 0, supported tunnel types -, 1WT root@ng1e:~#
I have tried --dups-ttl 2 --re-brc-delay 15 --window-size 100 (reading from bmx tutorial pdf) and it has helped somewhat, but not completely. The problem is still there but to a lesser extent.
--dups-ttl 2 --window-size 100 is default since a while.
Since revision 788 (when frame aggregation became default) the --re-brc-delay has become irrelevant because the generated frames are delayed anyway. Sorry, I have to update the document to reflect that.
I don't know whether this is down to ahdemo (maybe Antonio can help here with his experience) or down to batman. Any ideas?
Also, is my throughput ok compared to yours? The most I ever got was around 450KB/s (roughly 5.5mbits data rate, distance 100m outside with 9dbi omni antennas and atheros 5112 - buffalo whr-hp-ag108 at both ends) but the 11Mbits evades me - even on a -55 signal and 40 rssi! It really is heart breaking, especially seeing such a good signal. Two nodes roughly 300m apart get 240KB/s at most. I know better is possible because in ap mode with that signal I used to get 1MB/s transfers (that was before I started using batman and ahdemo).
I dont know why but ahdemo (or ad-hoc mode in general) is usually less performat than managed mode. IMO the ad-hoc implementations never experience as much devotion as developers spent in the managed mode.
ciao, axel
Best regards,
Pele
P.S. digraph topology { "105.0.4.4" -> "105.0.4.5"[label="1.15"] "105.0.4.4" -> "105.0.3.3"[label="1.05"] "105.0.4.4" -> "10.0.4.0/255.255.255.0"[label="HNA"] "105.0.4.4" -> "10.1.4.0/255.255.255.0"[label="HNA"] "105.0.4.4" -> "105.0.2.4/255.255.255.255"[label="HNA"] "105.0.3.3" -> "105.0.0.1"[label="1.16"] "105.0.3.3" -> "105.0.4.4"[label="1.19"] "105.0.3.3" -> "105.0.3.2"[label="1.05"] "105.0.3.3" -> "105.0.4.5"[label="1.12"] "105.0.3.3" -> "10.0.3.0/255.255.255.0"[label="HNA"] "105.0.3.3" -> "10.1.3.0/255.255.255.0"[label="HNA"] "105.0.3.3" -> "105.0.0.3/255.255.255.255"[label="HNA"] "105.0.3.3" -> "105.0.2.3/255.255.255.255"[label="HNA"] "105.0.3.3" -> "105.0.1.3/255.255.255.255"[label="HNA"] "105.0.4.5" -> "105.0.4.4"[label="1.27"] "105.0.4.5" -> "105.0.3.3"[label="1.03"] "105.0.4.5" -> "10.0.5.0/255.255.255.0"[label="HNA"] "105.0.4.5" -> "105.0.2.5/255.255.255.255"[label="HNA"] "105.0.3.2" -> "105.0.0.1"[label="1.03"] "105.0.3.2" -> "105.0.3.3"[label="1.03"] "105.0.3.2" -> "10.0.2.0/255.255.255.0"[label="HNA"] "105.0.3.2" -> "10.1.2.0/255.255.255.0"[label="HNA"] "105.0.3.2" -> "105.0.0.2/255.255.255.255"[label="HNA"] "105.0.3.2" -> "105.0.2.2/255.255.255.255"[label="HNA"] "105.0.3.2" -> "105.0.1.2/255.255.255.255"[label="HNA"] "105.0.0.1" -> "105.0.3.3"[label="1.03"] "105.0.0.1" -> "105.0.3.2"[label="1.01"] "105.0.0.1" -> "10.0.1.0/255.255.255.0"[label="HNA"] "105.0.0.1" -> "10.1.1.0/255.255.255.0"[label="HNA"] "105.0.0.1" -> "105.0.2.1/255.255.255.255"[label="HNA"] "105.0.0.1" -> "105.0.1.1/255.255.255.255"[label="HNA"] "105.0.0.1" -> "0.0.0.0/0.0.0.0"[label="HNA"] }
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
On Thu, 13 Dec 2007 18:24:52 +0100 Axel Neumann axel@open-mesh.net wrote:
I dont know why but ahdemo (or ad-hoc mode in general) is usually less performat than managed mode. IMO the ad-hoc implementations never experience as much devotion as developers spent in the managed mode.
It's even worser. In the backoff algorithm (collision detection) the wifi spec says that in ad-hoc mode the waiting time in collision cases is *2. Which means that in ad-hoc mode when the air is very dense, ad-hoc networks the only half the airtime managed networks get. personally i suspect that it is even worse and causes many of the ad-hoc network problems and gets worser with more hops.
kindly regards daniel
b.a.t.m.a.n@lists.open-mesh.org
-
Axel Neumann -
daniel.poelzleithner -
Predrag Balorda