WiFi connected but device not reachable

Technical Support
, , ,
1

Hello Toradex team,

I hope you are all doing great!

Hardware:

uname:

  • Linux verdin-imx8mp-14773156 5.15.129-6.5.0+git.6f8fd49366db #1-TorizonCore SMP PREEMPT Fri Dec 22 11:15:52 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

Images tested:

  • torizon-core-docker-verdin-imx8mp-Tezi_6.5.0+build.8.tar (STABLE Release)

Guest OS:

  • macOS (M1 Pro ARM64)
  • Linux ubuntu (VM x86_64)

Issue:

Hello,

The issue I’m facing is related to the WiFi. My device is correctly connected to internet through WiFi. When you check the ifconfig for mlan0, I have an IP address as expected:

mlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.X  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX  prefixlen 64  scopeid 0x0<global>
        inet6 XXXX::XXXX:XXXX:XXXX:XXXX  prefixlen 64  scopeid 0x20<link>
        ether XX:XX:XX:XX:XX:XX  txqueuelen 1000  (Ethernet)
        RX packets 451710  bytes 273671226 (260.9 MiB)
        RX errors 0  dropped 1559  overruns 0  frame 0
        TX packets 92766  bytes 10931485 (10.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The device itself can ping any IP address inside our outside the network but the opposite is not possible. I’m unable to connect/ping to the device from my network:

torizon@verdin-imx8mp-XXXXXXXX:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=2.138 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=8.058 ms

$ ping 192.168.1.X
PING 192.168.1.X (192.168.1.X): 56 data bytes
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: Host is down
Request timeout for icmp_seq 1
...
$ ping verdin-imx8mp-XXXXXXXX.local
[NOTHING]

I can see this problem happening when the device remains connected for more than a few hours/days.

Am I the only one facing this issue ? Is it something that I need to configure to avoid this issue ?

Thanks in advance

Best regards,
M

2

Hello @unablesalt,

I will try to reproduce your issue.

Do you have any customization on your Torizon OS 6.5.0 image?

Best Regards,
Bruno

3

Hello @bruno.tx,

I have applied some customization but nothing related to the WiFi. Just a custom .nmconnection for my 4G module.

Also, this issue was there on the 6.4 also, it wasn’t my focus at that time but now that we are using the WiFi more and more, I would like to understand what’s happening.

Best,
M

4

Hello @unablesalt,

I have started the test about 18h ago and there are still no issues pinging the device.
I will leave it running for longer and continue testing.

To make sure the setup is similar, can you clarify a few points:

  • Which frequency are you using on the Wi-Fi? 2.4 GHz, 5 GHz, or is the issue present regardless of this?
  • Do you see any correlation between the problem and distance from the WiFi AP?
  • When the host cannot ping the module, it is connected to the WiFi AP via WiFi as well?

Best Regards,
Bruno

5

Hello @bruno.tx,

Thank you for taking the time to test my issue.

For the 3 questions:

  • Device is connected to the 2.4GHz, and I don’t think the issue is related to the frequency but I can try to connect to 5 GHz and keep you updated
  • I don’t see any correlation related to the distance, the device is close enough (~5m) with nothing in between (other than humans that walk in the office)
  • Yes, the host is connected on the same WiFi as the device when I’m trying to ping it. When the device is plugged via Ethernet through the same router I don’t have the issue, I can ping it whenever I want. That’s why I raised a ticket about that :blush:

I checked the journalctl of the device, and I can see multiple time the same kind of message related to the WiFi:

Mar 13 12:46:04 verdin-imx8mp-XXXXXXXX systemd-resolved[719]: mlan0: Bus client set DNS server list to: 192.168.1.1
Mar 13 12:46:57 verdin-imx8mp-XXXXXXXX systemd-resolved[719]: mlan0: Bus client set DNS server list to: 192.168.1.1, XXXX:XXXX:XXXX:XXXX:XX:XXXX::
[...]
Mar 13 12:50:42 verdin-imx8mp-XXXXXXXX systemd-resolved[719]: mlan0: Bus client set DNS server list to: 192.168.1.1
Mar 13 12:51:22 verdin-imx8mp-XXXXXXXX systemd-resolved[719]: mlan0: Bus client set DNS server list to: 192.168.1.1, XXXX:XXXX:XXXX:XXXX:XX:XXXX::
[...]
Mar 13 13:00:06 verdin-imx8mp-XXXXXXXX systemd-resolved[719]: mlan0: Bus client set DNS server list to: 192.168.1.1
Mar 13 13:00:08 verdin-imx8mp-XXXXXXXX systemd-resolved[719]: mlan0: Bus client set DNS server list to: 192.168.1.1, XXXX:XXXX:XXXX:XXXX:XX:XXXX::

I’m not specialist in network, but do you think that the problem could be due the lease of the WiFi that renew in loop ?

Best regards,
M

6

Hello @unablesalt,

Thanks for the clarifications.

Looking at the journald logs, it would seem they are related to DNS.
This could be a problem if only the device’s hostname was not working.
However, pinging the device directly via its IP does not work as well, so we bypass the name resolution and still get the problem.

This issue could be related to the router dropping the module from its hosts table.
A way to check if this is the case would be to view if the router still lists the module as a client when the issue occurs.

I am now trying to ping the device from a host connected via Wi-Fi, and there is still no problem. My setup uses 5 GHz, but I will change this to 2.4 GHz and leave it for longer.

Best Regards,
Bruno

7

Hello @bruno.tx,

I hope you are doing great !

So I checked if the device remains registered on the router and that’s the case. It’s clearly strange what’s happening here… I’ll buy a new router and check if the same problem occurs.

Best,
M

8

Hello @unablesalt,

Thanks for the update.

I left a device running here for some time and it was still reachable.
Checking the router, the DHCP lease was renewed consistently at half of its time.

The default time on the router was 2 hours, but the behavior was consistent with a lower time of 2 minutes.

One more test that could be done is to see if the problem occurs with a default Torizon OS 6.5.0 image.
If it does, than the router is likely the issue.

Best Regards,
Bruno

1 Like
9

Hello again,

Thank you for your update!

That’s a good idea to test with a default image, I’ll try this out during the weekend and give you an answer on Monday.

Have a good weekend.

Best,
M