Does C.H.I.P's Wireless Radio supports Adhoc Mode?


#1

With debian running, I would like to know whether the Realtek RTL8723BS (the wireless radio on C.H.I.P) supports ad-hoc mode?

Usually, iwconfig can be used to change the mode of the wireless radio and iw list can be used to see the supported interfaces and their combinations.

Can someone help us know the status? We are trying to build a community wireless mesh networks. If it works, we are definitely getting C.H.I.P.


#2

Does this link answers Your question?


#3

I have already read that thread. It doesn’t answer my question. But the following links does

  1. C.H.I.P. Mesh networks
  2. http://cit.odessa.ua/media/pdf/Intel-Compute-Stick/NT-SM02BD.pdf

So the radio support ad-hoc mode and the batman-adv mesh protocol is part of Linux kernel.


#4

@prashere In theory, it should work, I’ve not been able to compile the kernel with batman-adv enabled due to a buggy buildroot. Yes, Batman is included in the kernel, unfortunately it isn’t enabled on the Debian image.

My only interest in CHIP is for building a mesh network, and I haven’t been able to do this yet.


#5

Good news! (and a little bad news)

By switching to an alternative driver for the RTL8723BS, you should be able to get ad-hoc networking to work.

The driver is here: https://github.com/hadess/rtl8723bs

With the official NTC 8723bs driver, I was able to create and connect to ad-hoc networks, but nothing else worked (could not ping machines, etc). With this driver, it works just fine.

So the bad news… one, you have to compile this yourself, and load it up. Two, for some reason, only one wlan device is available with this driver, and not the two you get with NTC’s driver… for now, at least. If I find out how to get both wlan devices working with the alternate driver, I’ll be sure to follow up here.


#6

Fantastic work here! If you succeed, be sure to add your knowledge to the wiki. :slight_smile:


#7

So, I had success with this, using the NTC-provided driver. But, only from buildroot! When I used CHIP-buildroot to flash my device, and deployed out the stock environment it had, ad-hoc mode worked like a charm, first time, no problems at all. This was on branch chip/stable (c4a3224).

Granted, most people do not want to run from buildroot, but this is at least promising that it’s possible!


#8

Akidan,

Thanks for testing the adhoc stuff a bit … I had also noticed that adhoc was broken in the CHIP debian builds and its on my todo list to get a new build out that fixes it up.

The driver from hadess was once upon a time building in buildroot (package/rtl8723bs), but I have not tested it in a while, so it may be completely bit-rotted.

You raise two interesting points that I would like to understand a bit further:

  1. When you say adhoc worked in buildroot chip/stable, was that still building package/rtl8723bs_mp_driver for you? (that appears to be the default in configs/chip_defconfig)

  2. Did you use iwconfig to configure adhoc in both cases (buildroot chip/stable and the 4.4 debian) or did you use iw, wpa_supplicant something else?

I ask 2 because those tools use vastly different configuration interfaces into the kernel … the 8723bs driver really should not have changed significantly, so I am trying to think of why adhoc would have regressed.

Also, are you trying to use any form of layer 2 security (WPA2) or just an open network with security at the IP layer or higher?

Thanks
Jason


#9

Hey, Jason! Thanks so much for looking into this. I do not have the answer to #1 for you right now but I can find out. (I’ve totally torn up my CHIP’s filesystem since then trying to do my own rootfs from scratch, but I don’t mind replacing that. ;))

Regarding #2, primarily, I’ve been using iwconfig. I tried to use iw, and NetworkMonitor, but to be honest I always end up find iw confusing so I go back to iwconfig…

While I would like to get WPA2 working, for sure, I was not trying to with these initial attempts. This was just plain ol’ ad-hoc unencrypted asking-to-get-hacked mode. :slight_smile:

I can reproduce these issues very consistently though, so I’m sure I can get you a specific set of steps I’m doing in each environment to reproduce. Give me a little time and I’ll get you an answer to #1 as well - just gotta go back and verify what steps I took…


#10

@jason Answer to #1:

Yes, it was using package/rtl8734bs_mp_driver. I looked in the .config file and verified this was being built. If you need more info let me know, but here’s steps I took to create my buildroot (assuming you have chip/stable checked out):

# remove all local modifications
git reset --hard HEAD && git clean -dffx
make chip_defconfig
make
cd path/to/CHIP-tools
sudo ./chip-fel-flash.sh -f -u path/to/CHIP-buildroot/output

After flashing, I had a strange issue with the soft blocking on the rfkill switches being on, but I’ve never had that before. I did echo 0 > /sys/class/rfkill/rfkill0/soft for rfkill0 through 2 to fix that. Then:

ifconfig wlan1 up 192.168.2.2
iwconfig wlan1 mode ad-hoc channel 1 essid chip

At this point I was able to connect from another computer with ip 192.168.2.1 to the chip ad-hoc network, and successfully ping back and forth between machines.

So, here is the same attempt on Debian. At the time I was doing this, I was using 4.3, so I will use the same her for consistency (CHIP 4.3 No GUI fastboot, flashed from the web flasher)
The only difference in configuration this time was I had to get wifi up to install iwconfig with wireless-tools:

nmcli d wifi connect myssid password hunter2 ifname wlan0
apt update
apt install wireless-tools
ifconfig wlan1 up 192.168.2.2
iwconfig wlan1 mode ad-hoc channel 1 essid chip

At this point, iwconfig shows that no cell is associated, and in dmesg, there is the following warning:

[  474.970000] ------------[ cut here ]------------
[  474.970000] WARNING: CPU: 0 PID: 289 at net/wireless/ibss.c:67 cfg80211_ibss_joined+0x140/0x144 [cfg80211]()
[  474.970000] Modules linked in: bnep 8723bs(O) cfg80211 hci_uart btbcm btintel cmac ecb bluetooth usb_f_acm u_serial g_serial libcomposite configfs
[  474.970000] CPU: 0 PID: 289 Comm: RTW_CMD_THREAD Tainted: G           O    4.3.0 #10
[  474.970000] Hardware name: Allwinner sun4i/sun5i Families
[  474.970000] [<c00191dc>] (unwind_backtrace) from [<c0015160>] (show_stack+0x20/0x24)
[  474.970000] [<c0015160>] (show_stack) from [<c0356658>] (dump_stack+0x90/0xa0)
[  474.970000] [<c0356658>] (dump_stack) from [<c00272cc>] (warn_slowpath_common+0x94/0xc4)
[  474.970000] [<c00272cc>] (warn_slowpath_common) from [<c00273b8>] (warn_slowpath_null+0x2c/0x34)
[  474.970000] [<c00273b8>] (warn_slowpath_null) from [<bf125984>] (cfg80211_ibss_joined+0x140/0x144 [cfg80211])
[  474.970000] [<bf125984>] (cfg80211_ibss_joined [cfg80211]) from [<bf200eb8>] (rtw_cfg80211_ibss_indicate_connect+0x168/0x170 [8723bs])
[  474.970000] [<bf200eb8>] (rtw_cfg80211_ibss_indicate_connect [8723bs]) from [<bf1fc7a0>] (rtw_os_indicate_connect+0x34/0x70 [8723bs])
[  474.970000] [<bf1fc7a0>] (rtw_os_indicate_connect [8723bs]) from [<bf1bc104>] (rtw_indicate_connect+0x38/0x54 [8723bs])
[  474.970000] [<bf1bc104>] (rtw_indicate_connect [8723bs]) from [<bf1c86e8>] (start_create_ibss+0x134/0x144 [8723bs])
[  474.970000] [<bf1c86e8>] (start_create_ibss [8723bs]) from [<bf1cade0>] (createbss_hdl+0xd8/0xf0 [8723bs])
[  474.970000] [<bf1cade0>] (createbss_hdl [8723bs]) from [<bf1a8bcc>] (rtw_cmd_thread+0x2f0/0x430 [8723bs])
[  474.970000] [<bf1a8bcc>] (rtw_cmd_thread [8723bs]) from [<c00465b4>] (kthread+0xec/0x104)
[  474.970000] [<c00465b4>] (kthread) from [<c00109b8>] (ret_from_fork+0x14/0x3c)
[  474.970000] ---[ end trace 4668a0defb23fe46 ]---
[  474.970000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready

Sometimes, you can even get it to kernel panic, with certain options (I recorded one attempt here: Kernel panic when setting certain wireless settings?)

I’ll work on trying 4.4 and giving you the results from that, too.