Whether Batman-adv need suitable wifi network card (support interface modes ( mesh point ) ) .

Hello Dear Sir :

Whether Batman-adv need suitable wifi network card (support interface modes ( mesh point ) ) .

there are two wifi network card , and i thought Rt2070 will support Batman-adv .

Because Rt2070 will support interface modes ( mesh point ) , and RTL8188CUS can't support interface modes based mesh point .

this is some info via iw list , whether it will be correct understanding ?

Bus 001 Device 005: ID 148f:2070 Ralink Technology, Corp. RT2070 Wireless Adapter

Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* WDS
* monitor
* mesh point

8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

Supported interface modes:
* IBSS
* managed
* AP
* monitor
* P2P-client
* P2P-GO

"mesh point" is for 802.11s. You can use 802.11s (mesh point) interfaces for batman-adv when you set mesh_fwding to 0. But most people use IBSS (adhoc) at the moment for batman-adv. It doesn't really care that much about the underlying interface. It just has to be ethernet compatible and support some basic features like broadcast.

So you could even run infrastructure mode (AP+Sta) with batman-adv. But it doesn't make a lot of sense in most situations :)

The B.A.T.M.A.N. V algorithm implementation has some extra requirements. It must be able to get the expected throughput towards a different device from cfg80211. You can check if the driver supports this by checking iw dev wlan0 station dump and searching for "expected throughput:". The Mpbs value should represent the reality (and not be complete bogus).

The biggest problems here are driver/hw bugs. Even the ath9k hardware (which works quite well) has its fair share of problems.

Both advertise support for IBSS. So you can (in theory) use adhoc on both devices and run batman-adv on top of these adhoc interfaces. But you may end up with driver problems (at least I already had problems with Realtek and Ralink hardware). Maybe someone else here already tested these two chips and tell us more about them.

Kind regards,
Sven

Hello Sven:

Thanks you for your advisement , and i will start via two Rt2070 at first , but i will purchase suitable wifi network card or wifi module recently ,

Whether Atheros (AR54xx、AR91xx、AR92xx、AR93xx及AR95xx) will be suitable for batman-adv ?

their driver is ath9k .

Have a good day with you

Best Regards

Tiger

Please check if the underlying link works. Check iw dev wlan0 station dump and add an ip in a separate ip subnet to the wlan0 and try to ping each other via this ip. Also check batctl o to find out if the batman-adv nodes can see each other.

Kind regards,
Sven

Hello Sven:

HostB wlan0 : mac addr : ether 00:1d:43:10:15:44

HostA wlan0 : mac addr: ether c8:3a:35:c9:ce:71

i run the command at Host A ( Rt2070 ) at ( ping HostA from HostB) iw dev wlan0 station dump:
Station 00:1d:43:10:15:44 (on wlan0)
inactive time: 140 ms
rx bytes: 4977553
rx packets: 126014
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
rx drop misc: 0
signal: -39 dBm
signal avg: -39 dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: no
MFP: no
TDLS peer: no
DTIM period: 0
beacon interval:100
connected time: 10084 seconds

[root@alarmpi ~]# tcpdump -i bat0

07:01:40.635517 ARP, Reply 0.0.0.0 is-at 43:05:43:05:00:00 (oui Unknown), length 28 07:01:50.655521 ARP, Reply 0.0.0.0 is-at 43:05:43:05:00:00 (oui Unknown), length 28

[root@alarmpi ~]# tcpdump -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes 07:02:35.815528 c8:3a:35:c9:ce:71 (oui Unknown) > Broadcast, ethertype Unknown (0x4305), length 66:
0x0000: 000f 3202 d7e6 278c c83a 35c9 ce71 c83a ..2...'..:5..q.:
0x0010: 35c9 ce71 00ff 001c 0401 000c 0104 0001 5..q............
0x0020: 48b5 3b30 0000 0000 0601 0004 0000 0000 H.;0............
0x0030: 0201 0000

and i ping ip address belong to hostB (wlan0 )from HostA and it will be fine .

batctl o No batman nodes in range

-----------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------

and i run same command at Host B ( RTL8188CUS ) at ( ping HostB from HostA)

iw dev wlan0 station dump:

" is blank "

[root@alarmpi ~]# tcpdump -i bat0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bat0, link-type EN10MB (Ethernet), capture size 262144 bytes 06:55:51.505401 ARP, Request who-has bogon tell bogon, length 28 06:55:51.506177 ARP, Reply bogon is-at a6:b8:8a:11:be:a2 (oui Unknown), length 28

tcpdump -i wlan0

06:57:11.425351 c8:3a:35:c9:ce:71 (oui Unknown) > Broadcast, ethertype Unknown (0x4305), length 66:
0x0000: 000f 3202 d7e6 2649 c83a 35c9 ce71 c83a ..2...&I.:5..q.:
0x0010: 35c9 ce71 00ff 001c 0401 000c 0104 0001 5..q............
0x0020: 48b5 3b30 0000 0000 0601 0004 0000 0000 H.;0............
0x0030: 0201 0000 ....
06:57:11.534759 00:1d:43:10:15:44 (oui Unknown) > Broadcast, ethertype Unknown (0x4305), length 66:
0x0000: 000f 3105 d7e6 2649 c83a 35c9 ce71 c83a ..1...&I.:5..q.:
0x0010: 35c9 ce71 0000 001c 0401 000c 0104 0001 5..q............
0x0020: 48b5 3b30 0000 0000 0601 0004 0000 0000 H.;0............
0x0030: 0201 0000

and i ping ip address belong to hostA wlan0 from HostB and it will be fine .

batctl o No batman nodes in range

------------------------------------------------------------------------------------------------------------

And i thought Rt2070 support Broadcast and RTL8188CUS don't support Broadcast or send ...

because when i ping ip (RTL8188CUS) from Rt2070 , and i can see ping packet via (tcpdump -i bat0 ) and i can see Rt2070 mac addr via (tcpdump -i wlan0 ) at HOSTB,

but i ping ip (Rt2070) from RTL8188CUS and i can't see any ping packet from RTL8188CUS and i can't see RTL8188CUS mac via (tcpdump -i wlan0 ) at HOSTA

Whether it will be master reason ?

Thanks
...

On Mittwoch, 26. Oktober 2016 15:19:02 CEST johnzeng wrote:
[...]

[...]

[...]

Here we see that host A noticed that there is a different device and "connected" to it (actually, it just added it as remote station to its internal list).

This is a good sign - at least when both devices have each other in their respective station lists (*spoiler* they don't).

[...]

Here we see an OGM that is transmitted from this device. So for some reason we don't see the an incoming OGM from host B. Either host B is not really transmitting it, host A is not receiving it or you just didn't capture long enough.

[...]

This means that RTL8188CUS didn't detect a remote IBSS device. This is odd and at first glance looks to me like a bug in the RTL8188CUS driver. But I would recommend to get a third (known to work) device and check to which of the orignal two devices it can connect and which of the other two devices can connect to it.

You could even use the third device to capture raw wifi frames on a monitor interface and check if both devices submit these OGMs and if both devices are beaconing (and reply to probe requests).

But this is basically the main problem here.
The rest of the reply is just to explain some additional things.
---------------------------------------------------------------

[...]

[...]

[...]

This part shows an OGM from host A and host B. So it can receive OGMs from other stations and batman-adv is at least trying to send some data. It is unknown here if the host B is not really sending it or if host A is not really receiving it.

[...]

Both should have working broadcast to get the ARP stuff working for the ping. But of course this only a good test when each ping tests are done with clean ARP tables (Linux is sniffing packets to fill its own ARP table without always sending ARP request). There is a test which you could have done even without the iw dev wlan0 station dump info from above.

This part now is without batman-adv (because the text from you is quite unclear):
--------------------------------------------------------------------------------

But it could be that the ARP table on RTL8188CUS (Host B) was filled by the ARP request from Host A. And this was to only reason why the ping back from host B to host A worked. You can test that by making sure that the ARP table is clean on both hosts and then start pinging from B to A. Also make some captures with tcpdump on both hosts that you later can analyze with wireshark. After your test (when it worked) make sure that the arp table on both hosts contain entries for each other. And than analyze the dumps for ARP packets in wireshark to make sure that host B really submitted and request and host A replied to it.

Kind regards,
Sven

Dear Sven :

Thanks , and i will try to purchase suitable wifi
hardware ,

Because i use raspberry
<http://www.baidu.com/link?url=s_ofbUc1ZEO-1ohz5A3WnLdqY4CNZ948d7JxBMkwZtW_fjTcOKUwMjkloBUHVW475SCTMxAci7HoEvHeH80Fuz9lC1X4W6Hw4BvwQaUIDzq> pi , i have to use wifi card based usb .

whether you can advise a set of usb wifi card
based Atheros ( driver ath9k) ?

Best Regards

Tiger

On Mittwoch, 26. Oktober 2016 20:52:13 CEST johnzeng wrote:
[...]

Sorry, I have zero experience with the USB hardware (ath9k_htc/carl9170). I think Martin was using them some time ago. Or maybe someone else on the ml has more information about them.

But these devices use a firmware running on the device. I know that there were weird problems hunting the carl9170 hardware/firmware [1]. Th ath9k_htc looks a little better but the TODO list for the firmware is also quite large and there also some odd limitations mentioned on the driver page [2].

Kind regards,
Sven

[1] https://wireless.wiki.kernel.org/en/users/drivers/carl9170
[2] https://wireless.wiki.kernel.org/en/users/drivers/ath9k_htc

Hello Dear Sven:

Thanks you really ,

i am searching /lib/modules/4.4.26-1-ARCH/kernel/drivers/net/wireless/ath/

Maybe there are suitable driver and hardware .

Have a good day

Best Regards

Tiger

Yeah, I used them for some lab tests a few years back. The ath9k_htc works quite well with the exception that the chip/firmware/driver only supports 7 or 8 nodes within range due to limited resources on the chip.

// Martin

Sent from my Android device with K-9 Mail. Please excuse my brevity.

After looking at different USB chips, I would also recommend looking into ath9k_htc first. Even if it has limitations, other chips are doing much worse
...

Cheers,
Simon

On Mittwoch, 26. Oktober 2016 07:19:59 CEST johnzeng wrote:
[...]

[...]

All should work in their PCI(e) version and I think I've used all of them in the past - not sure about AR54xx (which were early draft-n devices). The first three are rather old and they would not be my first choice.

Kind regards,
Sven