Wifi exp board on legato21 (R15)

@jyijyi the AP interface is up and running but we are now facing an issue with the bridging as we would like to use the device as a bridge between eth0 and wlan0 interfaces.
I see this has already been done and it works with the previous release R14 (LE19), but with the new release R15 (LE21) it seems that the bridging fails and I am not sure what is the reason for this.

wifiService[1438] | Configuration file: /tmp/hostapd.conf
wifiService[1438] | rfkill: Cannot open RFKILL control device
wifiService[1438] | nl80211: Failed to add interface wlan0 into bridge br0: Operation not supported

Now, for some reason the wifiService on the previous release R14 didn`t run this command, I thought it could be related to the new recipe version of hostapd or wpa_supplicant, so I have used the 2.6 version (R14) while this is the 2.9 version on the R15 release.
hostapd v2.6
wpa_supplicant v2.6

Still the problem persists and we can`t figure out what is the problem, any idea?
your help is much appreciated.

did you rebuild the yocto image to include the hostapd in R15?

yes the hostapd now is fine, we can bring up the wlan0 interface but we are having a problem with the bridging to eth0.

just to fill in with the whole logs, this is where it fails:
Nov 24 14:35:13 fx30 user.info Legato: INFO | wifiService[1439] | WIFIAP_HOSTAPD_START
Nov 24 14:35:13 fx30 user.info Legato: INFO | wifiService[1439] | Configuration file: /tmp/hostapd.conf
Nov 24 14:35:13 fx30 user.info Legato: INFO | wifiService[1439] | rfkill: Cannot open RFKILL control device
Nov 24 14:35:14 fx30 user.info Legato: INFO | wifiService[1439] | nl80211: Failed to add interface wlan0 into bridge br0: Operation not supported
Nov 24 14:35:14 fx30 user.info Legato: INFO | wifiService[1439] | nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Nov 24 14:35:14 fx30 user.info Legato: INFO | wifiService[1439] | nl80211 driver initialization failed.
Nov 24 14:35:14 fx30 user.info Legato: INFO | wifiService[1439] | wlan0: interface state UNINITIALIZED->DISABLED
Nov 24 14:35:14 fx30 user.info Legato: INFO | wifiService[1439] | wlan0: AP-DISABLED

in the start-up script is just passing the hostapd.conf to the hostapd, which is the same command for the old legato version as well.

WIFIAP_HOSTAPD_START)
echo “WIFIAP_HOSTAPD_START”
(/bin/hostapd /tmp/hostapd.conf -i${IFACE} - B) && exit 0

if we remove the first line from the hostapd.conf, the configuration works fine.

This is what the hostapd.conf looks like:
driver=nl80211
wmm_enabled=1
beacon_int=100
dtim_period=2
rts_threshold=2347
fragm_threshold=2346
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=AP_VU050687491510
channel=6
max_num_sta=10
country_code=US
ignore_broadcast_ssid=0
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
wpa_passphrase=xxxxxx
hw_mode=g

while if we add the first line to be:
bridge=br0
driver=nl80211
wmm_enabled=1
beacon_int=100
dtim_period=2
rts_threshold=2347
fragm_threshold=2346
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=AP_VU050687491510
channel=6
max_num_sta=10
country_code=US
ignore_broadcast_ssid=0
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
wpa_passphrase=xxxxxx
hw_mode=g

it will fail.

if we deploy the old version R14, it will work all right, so we basically rebuild the same apps with the older R14 release, the configuration file is:
bridge=br0
driver=nl80211
wmm_enabled=1
beacon_int=100
dtim_period=2
rts_threshold=2347
fragm_threshold=2346
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=AP_VU050687491510
channel=6
max_num_sta=10
country_code=US
ignore_broadcast_ssid=0
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
wpa_passphrase=xxxxxxx
hw_mode=g

and it brings up the interface without any problem.
we were wondering if you have seen this problem before and if you know if this is related to the drivers or hostapd version (which we have already tried to downgrade) and the wpa_supplicant (same)

we believe this is related to the drivers for the wl18xx but not sure where to look to be honest…

no idea, i have never gone so deep in the WIFI.
BTW, I guess you want to share WIFI data to ethernet, will you consider NAT?

well, yes if we can get what we need… :slight_smile:
how do you setup the NAT instead?
I think we did give it a try but didn`t go past that…

Here is a script for sharing cellular data (rmnet_data0) to ethernet interface (eth0) by NAT in FX30.
cfg_gateway_eth0_auto.sh (7.1 KB)

You might change it to share the wifi data (wlan0) to ethernet interface (eth0).

Other user says it should be working fine:

I have tried with this but can`t get it to work, the eth0 and wlan0 are already up and running so my setup is a lot easier.
wlan0 has a DHCP already enabled and is correctly assigning the IP to the client, eth0 is set to static, the client is connecting with a static IP.
These are the
eth0 Link encap:Ethernet HWaddr 00:14:3E:9D:BA:57
inet addr:192.168.13.31 Bcast:192.168.13.255 Mask:255.255.255.0
inet6 addr: fe80::214:3eff:fe9d:ba57/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1600 errors:0 dropped:0 overruns:0 frame:0
TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:74056 (72.3 KiB) TX bytes:3936 (3.8 KiB)

wlan0 Link encap:Ethernet HWaddr 64:69:4E:77:D5:2E
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::6669:4eff:fe77:d52e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:618 errors:0 dropped:0 overruns:0 frame:0
TX packets:656 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:72055 (70.3 KiB) TX bytes:87715 (85.6 KiB)

The client connected through wlan0 has IP 192.168.1.11 (dhcp) while the client connected on eth0 has 192.168.13.10 (static). I would like the two to communicate with each other, this below is the setup for the iptables:

iptables --flush
iptables -I INPUT -j ACCEPT
iptables --table nat --flush
iptables --table nat --delete-chain
sysctl -w net.ipv4.ip_forward=1
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
iptables -A FORWARD -i wlan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o wlan0 -m state --state NEW -j ACCEPT
iptables -A INPUT -m udp -p udp --sport 67:68 --dport 67:68 -j ACCEPT

After this from the shell of the fx30 I can still ping both clients but the client on the eth0 can`t ping the client on the wlan0 and viceversa.

For the FX30 connected WIFI connection through wlan0 with IP 192.168.1.11, can the FX30 browse internet?
For the client connected on eth0 has 192.168.13.10 (static), can it browse internet?

The wlan0 is setup as an AP not as a client.

so your cellular data is shared to wifi as AP, then you should also share cellular data to ethernet client eth0 instead of sharing the wifi AP data wlan0 to eth0.

nope, the cellular data is independent from the wlan0 and eth0, which should be bridged together. The two clients (eth0 and wlan0) are communicating with each other and with an app which then send data over the cellular network.

hard to understand …

any grapy showing your idea?

I think the AP mode is for sharing cellular data to wifi client…

Have you tried to share cellular data to both wifi client and ethernet client?

I meant, the cellular data is not the problem here, we just want to bridge the ethernet (wired) to wifi client connected through wifi AP. Have you tried to bridge the wifi in AP mode to the ethernet wired?

no, I never tried that

You might need to study ip route table:

BTW, you might also get some idea from this:

I have moved some steps forward but then got stuck and can’t proceed any further. I am testing exactly the same app with both versions R14 and R15, it seems that occasionally the R14 gave an error with the driver but it then recovers, while with the R15 version if the app fails and restart, then it will get stuck and won’t bring the wlan0 up. will be troubleshooting this later to see how to solve it but I can bring the wlan0, add it to a br0 together with eth0 and then remove the routes even with the new release R15.

  1. Now, with the R14 once the wlan0 is brought up, added to the br0 (bridge) together with the eth0, then everything works well, for instance a client connecting over wlan0 will be assigned with a valid IP according to the file:
    /etc/dnsmasq.d/dnsmasq.wlan.conf

While with the R15 this will not work. So is there a different file we should use for the DHCP assignment?

If I assign a static IP to the client connecting to the wlan0, then I can ping the client connected on the eth0 side, so I was thinking the problem may be with the DHCP server on the device itself. However, if we just bring up the wlan0 without adding it to the bridge and removing the routes, then the DHCP server works and the client will be assigned with a valid IP.

  1. Similar issue with the eth0, with the R15 once this is added to the bridge and the route are removed, then the client connected to this interface is unable to communicate with the legato app anymore. I can’t ping this client from the fx30 or the fx30 from the client even if they have the IP address on the same subnet. This happens as soon as the interface is added to the bridge.

I am suspecting this to be related with some sort of security with the R15 which wasn`t present on the R14 and which somehow prevents and doesn’t allow the communication over the bridge.

The legato app is exactly identical and just built for the two legato versions, so the R14 will be legato 19 while the R15 will be legato 21 and with the latest something seems not working as on the previous one…

I have tried to find for answers in other forums but being a custom yocto build this has been challenging, hopefully someone from the development team will help? Surely there is a clear reason for this but possibly a simple solution as well.

>>>with the R15 once this is added to the bridge and the route are removed, then the client connected to this interface is unable to communicate with the legato app anymore

First of all, how do you bridge the ethernet interface to the wifi interface?

For the legato app, are you setting up TCP server for communicate with client in eth0?
Have you tried to use some linux application (or nc tool) so that legato framework is isolated? ( this can see if legato framework is related to the issue)

BTW, to make it easier, I was wondering if you can reproduce the issue in USB ECM interface?
For example, if you bridge the USB interface to other interface like ethernet, will it see the issue?

the wlan0 and eth0 are added to the bridge with the same method, this works fine as once this is done I can ping the client connected on the ethernet interface by the client connected over wifi.

I don`t think the problem with the legato framework, as once the bridge is created I can’t ping anymore the client connected on the ethernet interface from shell:
root@fx30:~# ping 192.168.0.141 (before the eth0 and wlan0 are added to the bridge)
PING 192.168.0.141 (192.168.0.141): 56 data bytes
64 bytes from 192.168.0.141: seq=0 ttl=64 time=1.823 ms
64 bytes from 192.168.0.141: seq=1 ttl=64 time=1.222 ms
64 bytes from 192.168.0.141: seq=2 ttl=64 time=1.227 ms

root@fx30:~# ping 192.168.0.141 (after eth0 and wlan0 are added to the bridge)
PING 192.168.0.141 (192.168.0.141): 56 data bytes
(no reply…)

I am not using the legato app which connects to the client over eth0 at this stage, the eth0 is initialized to the default ip 192.168.0.31 according to the /etc/network/interfaces file.

root@fx30:~# route
Destination Gateway Genmask Flags Metric Ref Use Iface
default 100.118.214.141 0.0.0.0 UG 0 0 0 rmnet_data0
100.118.214.140 * 255.255.255.252 U 0 0 0 rmnet_data0
192.168.0.0 * 255.255.255.0 U 0 0 0 br0
192.168.2.0 * 255.255.255.0 U 0 0 0 ecm0
192.168.225.0 * 255.255.255.0 U 0 0 0 bridge0

and this shows that both interfaces are added to the bridge interface (br0):
root@fx30:~# bridge link show master br0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19
11: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100

Same steps with the R14 (legato 19) and it works well:
root@fx30:~# ping 192.168.0.141 (after the bridge is created)
PING 192.168.0.141 (192.168.0.141): 56 data bytes
64 bytes from 192.168.0.141: seq=0 ttl=64 time=1.717 ms
64 bytes from 192.168.0.141: seq=1 ttl=64 time=1.771 ms
64 bytes from 192.168.0.141: seq=2 ttl=64 time=2.304 ms
64 bytes from 192.168.0.141: seq=3 ttl=64 time=2.307 ms

root@fx30:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.106.129.113 0.0.0.0 UG 0 0 0 rmnet_data0
10.106.129.96 * 255.255.255.224 U 0 0 0 rmnet_data0
192.168.0.0 * 255.255.255.0 U 0 0 0 br0
192.168.2.0 * 255.255.255.0 U 0 0 0 ecm0
192.168.225.0 * 255.255.255.0 U 0 0 0 bridge0

root@fx30:~# bridge link show master br0
3: eth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19
13: wlan0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100

I am trying to understand if this is related to some additional filtering which doesn`t allow to bridge traffic between wlan and eth, maybe some safety path which is present in the latest legato version (yocto) and not on the previous one?
Have been looking into different forums but so far have found no solution to the problem, therefore asking here hoping that someone will kindly reply to this providing indication for the possible solution…

also, with the R14 (legato 19) when the client connects to the wlan0 it will be assigned with a valid IP by the DHCP server according to the file /etc/dnsmasq.d/dnsmasq.wlan.conf:

Wireless LAN adapter Wi-Fi: (this is from the client connected to wlan)
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 192.168.0.11
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.199
where 192.168.0.199 is the IP of the bridge br0.

using the R15 (legato 21) release, this will not work and the client will not be assigned with a valid IP, and I assume this is because the client cannot connect to the DHCP server.

Wireless LAN adapter Wi-Fi: (this is from the client connected to wlan)
Connection-specific DNS Suffix . :
Autoconfiguration IPv4 Address. . : 169.254.31.148
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

…however, if I assign a static IP to the client (192.168.0.55) then I can confirm that the bridge interface is working as I can ping the client connected on eth0 interface.
Wireless LAN adapter Wi-Fi: (this is from the client connected to wlan, IP is STATIC now)
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 192.168.0.55
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Then I can ping the client on the eth0 from the client connected on wlan0:
PS C:\Users\xxxxx> ping 192.168.0.141
Pinging 192.168.0.141 with 32 bytes of data:
Reply from 192.168.0.141: bytes=32 time=9ms TTL=64
Reply from 192.168.0.141: bytes=32 time=7ms TTL=64
Reply from 192.168.0.141: bytes=32 time=5ms TTL=64
Reply from 192.168.0.141: bytes=32 time=9ms TTL=64
Ping statistics for 192.168.0.141:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 9ms, Average = 7ms

This is an odd operation, can`t figure out what is the problem as it actually seems that the bridge is working but not as per the previous legato version…?