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.
- 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.
- 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…?