Dear all,
I captured 802.11 frames of BATMAN-adv V.
Here is the script to do this. =============================================== iw phy phy1 interface add mon0 type monitor ifconfig mon0 up ifconfig mon0 tcpdump -c 2000 -i mon0 -y IEEE802_11_RADIO -w mon0.pcap ===============================================
I checked the .pcap file in wireshark and found 4 type of packets: 1. many unicast packets, with length of 200 bytes. I guess it's ELP unicast. 2. some batman-adv broadcast packets of 56 bytes length. I guess it's OGM2? 3. several batman-adv broadcast packets of 16 bytes length. It's ??? 3. many rts/cts/ack packets. 4. some beacon frames.
Here is a ELP unicast packet sample. 16:43:43.438367 26700598255us tsft 2462 MHz 11n antenna 0 7.2 Mb/s MCS 0 20 MHz short GI RX-STBC0 00:00:0d:18:08:02 (oui Unknown) > 00:00:0d:18:08:06 (oui Unknown) SNAP, ethertype Unknown (0x4305), length 200: 0x0000: aaaa 0300 0000 4305 030f 0000 0d18 0802 ......C......... 0x0010: 0000 0000 0000 0000 87f3 6000 800e 0488 ..........`..... 0x0020: 0000 0000 0000 0001 8785 e550 0000 0001 ...........P.... 0x0030: 0000 0001 0000 0000 0800 0000 ffff ffff ................ 0x0040: ffff 0000 0d18 0802 0011 2233 4458 0039 .........."3DX.9 0x0050: aaaa 0300 0000 4305 030f 0000 0d18 0802 ......C......... 0x0060: 204b 4075 0000 01f4 ffff ffff 0401 0014 .K@u............ 0x0070: 0101 0002 56cb 6224 8000 0000 632c bf3d ....V.b$....c,.= 0x0080: 0000 005f 0602 0004 0700 0000 0201 0000 ..._............ 0x0090: 8333 aaff 0000 aaff 0000 c005 0000 00fc .3.............. 0x00a0: ffdd 1800 50f2 0201 0180 0003 a400 0027 ....P..........' 0x00b0: a400 0042 435e 0062 322f 00dd 0900 037f ...BC^.b2/...... 0x00c0: 0101 0000 ff7f dd18 8cbe be01 0101 0202 ................
Here is a 56 bytes (OGM2?) packet. 17:08:42.241883 28209488314us tsft 18.0 Mb/s 2462 MHz 11g -73dBm signal -75dBm signal antenna 0 -77dBm signal antenna 1 00:00:0d:18:08:05 (oui Unknown) > Broadcast SNAP, ethertype Unknown (0x4305), length 56: 0x0000: aaaa 0300 0000 4305 040f 3000 1b34 cd42 ......C...0..4.B 0x0010: 0000 0d18 0802 0024 0000 004d 0401 0014 .......$...M.... 0x0020: 0101 0002 56cb 6224 8000 0000 632c bf3d ....V.b$....c,.= 0x0030: 0000 005f 0602 0004 0700 0000 0201 0000 ..._............
Here is a 16 bytes batman-adv packet. 17:08:42.258522 28209504921us tsft 18.0 Mb/s 2462 MHz 11g -78dBm signal -84dBm signal antenna 0 -80dBm signal antenna 1 00:00:0d:18:08:01 (oui Unknown) > Broadcast SNAP, ethertype Unknown (0x4305), length 16: 0x0000: aaaa 0300 0000 4305 030f 0000 0d18 0801 ......C......... 0x0010: a333 a781 0000 01f4 .3......
I will try to increase the ELP interval and check the performance again.
I noticed 2 macro definitons. #define BATADV_ELP_PROBES_PER_NODE 2 #define BATADV_ELP_MIN_PROBE_SIZE 200 /* bytes */ I wonder why it sends 2 prob ELP packets to each neighbour. Can I change the value of BATADV_ELP_PROBES_PER_NODE from 2 to 1? And can I decrease ELP prob packet size from 200 to 100, in order to decrase the ELP airtime?
Yours Sincerely Ligang
At 2018-08-30 17:06:30, "Sven Eckelmann" sven@narfation.org wrote:
On Donnerstag, 30. August 2018 16:55:38 CEST Ligang LIU wrote:
[...]
One strange thing. Can I ignore this waring, even if I think the wifi driver is ok? [ 30.628792] batman_adv: bat0: WiFi driver or ethtool info does not provide information about link speeds on interface wlan1, therefore defaulting to hardcoded throughput values of 1.0 Mbps. Consider overriding the throughput manually or checking your driver.
[...]
I would say that you cannot ignore it because it means that the wifi driver didn't provide the expected throughput for a station.
But it is most likely better to let Marek and/or Antonio answer this question.
I said it's strange because it seems the throughput value is acttually updated when batman is running, even there is a warning.
Maybe it was just not available when batman-adv asked the first time.
Btw. please structure you mails better. I will not read through this 400KB+ text mail just to find your annotations and questions. One which I saw but which should be answered by a different person is "6-node case".
I described the main results. And the attahed log is just for whom interested in finding the reason. It could be ignored for the others.
I have to emphasize that, the tests show that the output route of V is ok but the delay and throughput are bad. We should try to find where's gone the bandwidth. Do you have any suggestion about it?
Since there is still the problem that the ELP messages are potentially sent too often for low quality links (which also need the automatic retries by the wifi driver/hw). Did you try to increase the interval [1]? Just to make sure that they don't use the complete airtime.
There was also this odd wifi problem which somehow was (maybe) triggered or caused by B.A.T.M.A.N. V: https://www.open-mesh.org/issues/341 Unfortunately, the discussion with the reporter was rather frustrating and at the end stopped completely.
When I remember it correctly, the wifi performance of all nodes (even when not sending data over the batman-adv interface) was rather bad when some B.A.T.M.A.N. V nodes were around (and one of the nodes disappeared?).
Kind regards, Sven
[1] https://www.open-mesh.org/projects/batman-adv/wiki/Tweaking#ELP-interval