Vim4 Wifi fault

Hello,
I am recently in the process of moving my work from Vim3 to Vim4. I have found a few networking issues with Vim4.

  • First, the Ethernet network works perfectly, but when the WLAN network is connected, it will be difficult to communicate data via wifi, as shown by a huge latency.
  • Second, even if Ethernet is disconnected, when I enable wlan0 and wlan1 to work at the same time, they connect to hotspots of different frequencies (802.11ac 5ghz TP-Link Anchor C50 AC1200, TPlink TL-WR842N 2.4Ghz) and the latency will be significantly higher. They seem to be multiplexing a channel over time and switching at no more than 10hz. This makes it impossible not only to connect different devices using two different networks at the same time, but even to be disconnected from any one device.
  • Thirdly, when I just connect wlan0 or wlan1 on a hotspot at 5ghz frequency (802.11ac TP-Link Anchor C50 AC1200), testing via ping command I found that the latency of vim4 is stable around 200ms on the LAN, while the vim3 only has 2ms latency in the same case. When I use it to drive a camera and watch it remotely over wifi, the latency is very noticeable, which usually does not exist on the vim3.
  • Fourth, the Ethernet PHY always starts up with boot, but the wifi seems to have some trouble. When I disconnect the ethernet connection, I can’t remote login with ssh via wifi after boot, while when Ethernet is connected, ssh can remote login to it, and then ssh remote login via wifi is also then possible.

These above mentioned do not seem to be OS related. I’ve tried it with ubuntu22 and ubunut20, both official and compiled. Could this be a driver issue? Because the speed and latency of connecting to the public network via wifi is acceptable (<10ms, 80MBps), while the latency of communication within the LAN is noticeable compared to vim3.

1 Like

why not try check how it going with oowow

OOWOW networks

ethernet always works, and same u can play with different WiFi modes station/hotspot and both same time

i have check it many times with different equipment -

Yes I also tried using oowow to test the wifi. the result was the same, with a ping test latency of 200ms. however, this does not seem to be a wifi issue, as the ping test latency plummets to less than 10ms whenever a video stream, such as nomachine or camera, is turned on. Also, I was posting the realsense d435i camera stream via ros message and I found that the video lag was not due to wifi latency or blockage, but because vim4 was not publishing the frame at all.

However, issue 2 were not resolved.

  • I connected wlan0 to a 5ghz router, at this point ros messaging was turned on and everything was communicating fine. However, if I connect wlan1 to another router at 2.4ghz at the same time, the communication on wlan0 is almost broken and even ssh does not work properly. At this time, the communication on wlan1 is also almost interrupted. It appears that vim4 constantly switches channels at the software level rather than supporting dual channels in hardware.

This is just because I didn’t set this wifi to apply to all users. Ignore it.

Yes I also tried using oowow to test the wifi. the result was the same, with a ping test latency of 200ms. however, this does not seem to be a wifi issue, as the ping test latency plummets to less than 10ms whenever a video stream, such as nomachine or camera, is turned on. Also, I was posting the realsense d435i camera stream via ros message and I found that the video lag was not due to wifi latency or blockage, but because vim4 was not publishing the frame at all.

its depend from your network environment !!!

( i have test with 2/5 Ghz and wifi 6 - didnt see any problem

1 Like

Which system did you test on before, ubuntu22 or both, maybe it might be an issue with the system too. Also, I am connected to two separate routers with different addresses. One is on channel 48 and the other on channel 11. This can’t be the reason, right?

I’ve just started working with a VIM4 using the official Ubuntu 22 image, I believe late July 2022. Refreshed in oowow and installed yesterday Sep 13, 2022. @w407022008 @hyphop I too am seeing the wifi 0 drop off connection to Mikrotik router quite often, several times an hour.

As shown below, seems to be this WLC_E_DEAUTH error. When Googling this message, I do see some reports of wifi driver issues with other computer hardware.

Any ideas? This is a show stopper, I have 50 devices of various kinds attached to the Mikrotik access points with no issues

Some more info that might be related. The VIM4 is connecting to a WDS configured wifi of three Mikrotik routers. The Mikrotik’s are running version 6.48 firmware. I have had no issues with any devices connecting and staying connected to this network in two years of operation. Devices will switch from one to another of the routers based signal strength.

In reading others that have run across this ‘WLC_E_DEAUTH_IND’ message one reoccurring theme does seem to be the problematic device was connected to a WDS wifi network.

[Sep14 10:44] [dhd][wlan0] wl_handle_link_down : Link down Reason: WLC_E_DEAUTH_IND
[  +0.000009] [dhd][wlan0] wl_iw_event : disconnected with 48:8f:5a:aa:e8:93, event 6, reason 6
[  +0.001462] [dhd][wlan0] wl_ext_iapsta_event : [S] Link down with 48:8f:5a:aa:e8:93, WLC_E_DEAUTH_IND(6), reason 6
[  +0.001258] [dhd][wlan0] wl_iw_event : [0 times] disconnected with 00:00:00:00:00:00, event 11, reason 8
[  +0.000088] [dhd][wlan0] wl_handle_link_down : Disconnect event sent to upper layerevent:6 e->reason=100663296 reason=6 ie_len=0

happening every 5 minutes or so!!!

[Sep14 11:40] [dhd][wlan0] wl_handle_link_down : Link down Reason: WLC_E_DEAUTH_IND
[  +0.000009] [dhd][wlan0] wl_iw_event : disconnected with 48:8f:5a:c0:c6:25, event 6, reason 6
[  +0.001451] [dhd][wlan0] wl_ext_iapsta_event : [S] Link down with 48:8f:5a:c0:c6:25, WLC_E_DEAUTH_IND(6), reason 6
[  +0.001275] [dhd][wlan0] wl_iw_event : [0 times] disconnected with 00:00:00:00:00:00, event 11, reason 8
[  +0.000013] [dhd][wlan0] wl_handle_link_down : Disconnect event sent to upper layerevent:6 e->reason=100663296 reason=6 ie_len=0 from 48:8f:5a:c0:c6:25
[  +0.002918] [dhd][wlan0] wl_ext_iapsta_event : [S] Link down with 00:00:00:00:00:00, WLC_E_DISASSOC(11), reason 8
[  +0.001286] [dhd][wlan0] wl_iw_event : Link Down with 00:00:00:00:00:00, reason=2
[  +0.000969] [dhd][wlan0] wl_ext_iapsta_event : [S] Link down with 00:00:00:00:00:00, WLC_E_LINK(16), reason 2
[  +0.015811] [dhd] CFG80211-ERROR) wl_notify_connect_status_sta : Unexpected event:16 in assoc idle state
[  +0.242782] [dhd][wlan0] wl_ext_set_chanspec : channel 48, 0xe32a
[  +0.001838] [dhd][wlan0] wl_conn_debug_info : Connecting with 48:8f:5a:c0:c6:25 ssid "gfi", len (3), channel=48, sec=wpa2psk/mfpn/aes, rssi=-69
[  +0.094201] [dhd][wlan0] wl_iw_event : Link UP with 48:8f:5a:c0:c6:25
[  +0.000177] [dhd][wlan0] wl_ext_iapsta_event : [S] Link UP with 48:8f:5a:c0:c6:25
[  +0.002807] [dhd][wlan0] wl_bss_connect_done : Report connect result - connection succeeded
[  +0.003675] [dhd][wlan0] wl_add_keyext : key index (0)

An update on my research on this issue of VIM4 dropping off wifi. I moved my VIM4 from 3 node WDS Mikrotik WiFi network to a simple single WiFi access point WiFi network. The VIM4 has been running withOUT any network drop offs for several hours. Different from the experience of the VIM4 on the WDS WiFi network, where it was dropping off the network about every 5 minutes. Full visibility to changes I made, in addition to moving from the WDS to single access point WiFi network, the VIM4 was reconfigured to use a static IP address rather than a DHCP delivered IP address. The Mikrotik was configured to deliver the same IP address to the VIM4 on the WDS WiFi and the lease period was 10 minutes. It does appear that the VIM4 WiFi driver is having issues with a WDS WiFi network. I do not think the other differences between the two WiFi networks would be the cause of the problem.

I would appreciate some input from a Khadas member on this issue. Thx!

khadas@Khadas:~$ uname -a
Linux Khadas 5.4.125 #1.1 SMP PREEMPT Thu Jul 21 17:05:37 CST 2022 aarch64 aarch64 aarch64 GNU/Linux
khadas@Khadas:~$ cat /etc/fenix-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=VIM4
VENDOR=Amlogic
VERSION=1.1
ARCH=arm64
INITRD_ARCH=arm64
IMAGE_VERSION=1.1-220721
################ GIT VERSION ################
UBOOT_GIT_VERSION=khadas-vims-u-boot-2019.01-v1.1-release
LINUX_GIT_VERSION=khadas-vims-linux-5.4-v1.1-release
FENIX_GIT_VERSION=v1.1
#############################################
khadas@Khadas:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"
khadas@Khadas:~$

can u confirm its same happens with oowow ? (just start oowow with preconfigured wifi)

  1. check it for 2.4 G
  2. check it for 5 G
  3. check it under high load for example intensive ping or download
  4. check for idle usage

Hello @hyphop I’m not really versed in how to operate your oowow subsystem. That said, I booted into it played around with some of the functions. Some questions for you, to your points:

1 and 2) I do not know now to force the VIM4 to connect to a 2.4 G connection on my mikrotik wifi, all access points have the same SSID for both 2.4 and 5 G. My experience it is it up to the client to select which access point by MAC address and which frequency to connect via. I do not see a way to select frequency in oowoow, I do see each access points MAC address, so I could select that but not the frequency.

  1. I have a ping going from a linux machine to the VIM4 machine, I do not see the ‘drop off’ that was so clear under your Ubunti 22 image. However, I do not know how to monitor this under oowoow, it could be happening, but I am not watching it all the time.

  2. I have the VIM4 sitting in oowow attached to the WDS WiFi network, but that really does NOT show anything. My experience under your Ubuntu image was that the VIM4 would be connected to the WDS network and then drop off and quickly (with in 5 or so seconds) reconnect to the WiFi network. Again, I do not know how to monitor this in your oowow subsystem.

Thanks for your help! This is any important problem to solve in order for me to use and recommend your product.

– Dave

yes at this moment only by SSID for example router have diff SSID and separated SSID_5G

I have a ping going from a linux machine to the VIM4 machine, I do not see the ‘drop off’ that was so clear under your Ubunti 22 image. However, I do not know how to monitor this under oowoow, it could be happening, but I am not watching it all the time.

just to go shell form main menu

same time can ping oowow from pc by hostname vim4-XXXXX or vim4-XXXXX.local

Thanks for your reply and info.

So as I said, I have a ping TO the VIM4 from another device on the internal network, the VIM4 is attached to the WDS WiFi network in oowoow. So far, I am collecting the ping results in a text file, I do NOT see the drop off that I saw with the VIM4 running your Ubuntu image. I have started a ping from the oowoow ‘rescue shell’, that name was a bit scary to enter (IMHO, you should rename). It is pinging the router device on the WDS WiFi so far successfully, however, I am not going to sit an watch it to see if it fails. Is there a LOG??? Need better tools if you want me to help debug.

So far my opinion is that the WiFi network stack in oowow seems to be handling the WDS WiFi network ‘better’ / ‘okay’ vs. the Ubuntu WiFi stack which seems to fail totally.

  1. oowow host name generated unique for all devices vim4-XXXXX - where XXXXX last chars from serial number check more info dl.khadas.com - Index of /products/oowow/docs/ its can find easily your oowow devices in local network any time
  2. oowow provide basic linux/rescue shell - which willbe enouth in most cases sure if your linux skills same enouth :wink:
  3. same easy get ssh access to oowow, before need change oowow firewall setting to allow

examples how to

ping 192.168.31.1 | tee /tmp/ping.log
# wait and check log files after 
cat /tmp/ping.log

or

# collect all on your pc
ssh root@vim4-XXXXX ping 192.168.31.1 | tee /tmp/ping .log

and i can continue again and again … :wink:

PS: oowow pretty tools for common users same as for advanced users

PSS: can try ping -s1500 -i0.01 HOST - hi load or via nc -l -p < /dev/zero etc …

PSSS: need to clarify what a problem common wifi driver or ubuntu network stack

So I have left the VIM4 in oowow mode for about 8 hours on the WiFi with WDS. As far as I can tell, I have not seen the VIM4 in this mode drop off the WiFi. I ran pings to and from the VIM4 while it was in oowow mode, seems to have stayed on WiFi with no problems like I experiences with the VIM4 booted in Ubuntu.

What are next steps? You seem to be oowow person, do I need to contact someone involved with Ubuntu on VIM4 in your forum or company? Do I need to file a bug report of some kind?

I don’t understand what you are saying in this statement:
‘PSSS: need to clarify what a problem common wifi driver or ubuntu network stack’

I need a solution for the problem in Ubuntu, I do not understand the connection between oowow and Ubuntu.

Please advise. I need to understand if a fix is planned or in progress for Ubuntu and what time frame would be for something to test or a fix. Or do I need to look for a different SBC to meet my needs?

Thanks,

Dave

Hello @deepvim

I will check this issue on our side.

Are you use the desktop or server image ?

Hello @numbqq Thank you! I am running the Desktop image.

Hello @deepvim

I have tested the Wi-Fi connect for about 1hour, I can’t get the same errors as yours, although there has some ping drops but no Wi-Fi errors.

--- 192.168.31.242 ping statistics ---
4747 packets transmitted, 4741 received, 0.126396% packet loss, time 4753102ms
rtt min/avg/max/mdev = 1.375/78.667/1828.383/137.811 ms, pipe 2

Hi @numbqq Thank you for working on this. Just to make sure we have similar setups… You are connecting the VIM4 to a WiFi network with multiple access points that are connected to each other using WDS? My setup is stock Mikrotik systems, the only thing that is ‘special’ is that the three Mikrotik units are providing a single SSID on both 2.4 and 5.0 GHz using the WDS protocol. This WiFi has been up for two years with over 100 unique devices tested on it via WiFi, the VIM4 is the first device I have every had WiFi issues with. I do have other WiFi 6 based clients running Ubuntu 22, they are Intel based however.

I am going to do a complete reinstall of the current Ubuntu 22 Desktop image on the VIM4 now via oowow.

I am seeing three major issues right now with the VIM4 and Ubuntu:

  1. this WiFi issue
  2. unable to mount CIFS network volumes
  3. IO errors reading and writing to a Kingston A2000 250 GB nvme volume :
[39985.679376] JBD2: Detected IO errors while flushing file data on nvme0n1p1-8

I hope I can get these resolved. Again thanks for your help and work.
– Dave

Hi @numbqq ,
I did a complete reinstall of the current Ubuntu 22 Desktop from your oowow system and I continue to see two network issues with the VIM4 connected to the Mikrotik WDS access points :

  1. I continue to see the VIM4 disconnect and reconnect to the access points, seems to occur about every 5 minutes or so:
[Fri Sep 16 13:23:52 2022] [dhd] CFG80211-ERROR) wl_cfg80211_get_station : NOT assoc
[Fri Sep 16 13:23:58 2022] [dhd] dhd_is_associated: WLC_GET_BSSID, NOT ASSOCIATED
[Fri Sep 16 13:23:58 2022] [dhd] CFG80211-ERROR) wl_cfg80211_get_station : NOT assoc
[Fri Sep 16 13:23:58 2022] [dhd][wlan1] wl_handle_link_down : Link down Reason: WLC_E_DEAUTH_IND
[Fri Sep 16 13:23:58 2022] [dhd][wlan1] wl_ext_iapsta_event : [S] Link down with 48:8f:5a:81:a9:e6, WLC_E_DEAUTH_IND(6), reason 6
[Fri Sep 16 13:23:58 2022] [dhd][wlan1] wl_ext_iapsta_event : [S] Link down with 00:00:00:00:00:00, WLC_E_DISASSOC(11), reason 8
[Fri Sep 16 13:23:58 2022] [dhd][wlan1] wl_handle_link_down : Disconnect event sent to upper layerevent:6 e->reason=100663296 reason=6 ie_len=0 from 48:8f:5a:81:a9:e6
[Fri Sep 16 13:23:58 2022] [dhd][wlan1] wl_ext_iapsta_event : [S] Link down with 00:00:00:00:00:00, WLC_E_LINK(16), reason 2
[Fri Sep 16 13:23:58 2022] [dhd] CFG80211-ERROR) wl_notify_connect_status_sta : Unexpected event:16 in assoc idle state
[Fri Sep 16 13:23:59 2022] [dhd][wlan1] wl_ext_set_chanspec : channel 3, 0x1003
[Fri Sep 16 13:23:59 2022] [dhd][wlan1] wl_conn_debug_info : Connecting with 48:8f:5a:81:a9:e6 ssid "gfi", len (3), channel=3, sec=wpa2psk/mfpn/aes, rssi=-42
[Fri Sep 16 13:23:59 2022] [dhd][wlan1] wl_ext_iapsta_event : [S] Link UP with 48:8f:5a:81:a9:e6
[Fri Sep 16 13:23:59 2022] [dhd][wlan1] wl_bss_connect_done : Report connect result - connection succeeded
[Fri Sep 16 13:23:59 2022] [dhd][wlan1] wl_add_keyext : key index (0)
[Fri Sep 16 13:23:59 2022] [dhd] kck:
[Fri Sep 16 13:23:59 2022] [dhd]   0000: 7b 81 78 0d de 15 23 e2 90 14 b2 58 cf 42 61 02
[Fri Sep 16 13:23:59 2022] [dhd] kek:
[Fri Sep 16 13:23:59 2022] [dhd]   0000: 15 27 1c f0 a5 0a b9 f6 47 7d 7c 50 1f 2d c6 27
[Fri Sep 16 13:23:59 2022] [dhd] replay_ctr:
[Fri Sep 16 13:23:59 2022] [dhd]   0000: 00 00 00 00 00 00 00 02
[Fri Sep 16 13:23:59 2022] [dhd] dhd_is_associated: WLC_GET_BSSID, NOT ASSOCIATED
[Fri Sep 16 13:23:59 2022] [dhd] dhd_is_associated: WLC_GET_BSSID, NOT ASSOCIATED
[Fri Sep 16 13:24:04 2022] [dhd] dhd_is_associated: WLC_GET_BSSID, NOT ASSOCIATED
[Fri Sep 16 13:24:04 2022] [dhd] CFG80211-ERROR) wl_cfg80211_get_station : NOT assoc
[Fri Sep 16 13:24:10 2022] [dhd] dhd_is_associated: WLC_GET_BSSID, NOT ASSOCIATED
  1. The latency of the VIM4 responding to, for example PING, is VERY bad. Below is a comparison between pinging a Raspberry Pi 3B and the VIM4 both attached to the same WiFi. The ping response time of the VIM4 is on the order of TEN times slower than the Raspberry Pi :
user@macmini2014:~$ ping 192.168.2.212
PING 192.168.2.212 (192.168.2.212) 56(84) bytes of data.
64 bytes from 192.168.2.212: icmp_seq=1 ttl=64 time=5.09 ms
64 bytes from 192.168.2.212: icmp_seq=2 ttl=64 time=35.0 ms
64 bytes from 192.168.2.212: icmp_seq=3 ttl=64 time=2.53 ms
64 bytes from 192.168.2.212: icmp_seq=4 ttl=64 time=1.22 ms
64 bytes from 192.168.2.212: icmp_seq=5 ttl=64 time=1.27 ms
64 bytes from 192.168.2.212: icmp_seq=6 ttl=64 time=1.39 ms
64 bytes from 192.168.2.212: icmp_seq=7 ttl=64 time=1.48 ms
64 bytes from 192.168.2.212: icmp_seq=8 ttl=64 time=3.25 ms
64 bytes from 192.168.2.212: icmp_seq=9 ttl=64 time=1.40 ms
64 bytes from 192.168.2.212: icmp_seq=10 ttl=64 time=1.40 ms
64 bytes from 192.168.2.212: icmp_seq=11 ttl=64 time=2.36 ms
64 bytes from 192.168.2.212: icmp_seq=12 ttl=64 time=112 ms
64 bytes from 192.168.2.212: icmp_seq=13 ttl=64 time=1.64 ms
64 bytes from 192.168.2.212: icmp_seq=14 ttl=64 time=1.44 ms
64 bytes from 192.168.2.212: icmp_seq=15 ttl=64 time=2.89 ms
64 bytes from 192.168.2.212: icmp_seq=16 ttl=64 time=1.35 ms
64 bytes from 192.168.2.212: icmp_seq=17 ttl=64 time=3.96 ms
64 bytes from 192.168.2.212: icmp_seq=18 ttl=64 time=19.5 ms
64 bytes from 192.168.2.212: icmp_seq=19 ttl=64 time=2.68 ms
64 bytes from 192.168.2.212: icmp_seq=20 ttl=64 time=1.87 ms
64 bytes from 192.168.2.212: icmp_seq=21 ttl=64 time=2.06 ms
^C
--- 192.168.2.212 ping statistics ---
21 packets transmitted, 21 received, 0% packet loss, time 20030ms
rtt min/avg/max/mdev = 1.228/9.843/112.686/24.281 ms
user@macmini2014:~$ ping 192.168.2.26
PING 192.168.2.26 (192.168.2.26) 56(84) bytes of data.
64 bytes from 192.168.2.26: icmp_seq=1 ttl=64 time=36.4 ms
64 bytes from 192.168.2.26: icmp_seq=2 ttl=64 time=205 ms
64 bytes from 192.168.2.26: icmp_seq=3 ttl=64 time=20.5 ms
64 bytes from 192.168.2.26: icmp_seq=4 ttl=64 time=44.5 ms
64 bytes from 192.168.2.26: icmp_seq=5 ttl=64 time=67.1 ms
64 bytes from 192.168.2.26: icmp_seq=6 ttl=64 time=91.6 ms
64 bytes from 192.168.2.26: icmp_seq=7 ttl=64 time=212 ms
64 bytes from 192.168.2.26: icmp_seq=8 ttl=64 time=32.7 ms
64 bytes from 192.168.2.26: icmp_seq=9 ttl=64 time=152 ms
64 bytes from 192.168.2.26: icmp_seq=10 ttl=64 time=75.7 ms
64 bytes from 192.168.2.26: icmp_seq=11 ttl=64 time=97.8 ms
64 bytes from 192.168.2.26: icmp_seq=12 ttl=64 time=116 ms
64 bytes from 192.168.2.26: icmp_seq=13 ttl=64 time=141 ms
64 bytes from 192.168.2.26: icmp_seq=14 ttl=64 time=163 ms
64 bytes from 192.168.2.26: icmp_seq=15 ttl=64 time=187 ms
64 bytes from 192.168.2.26: icmp_seq=16 ttl=64 time=5.67 ms
64 bytes from 192.168.2.26: icmp_seq=17 ttl=64 time=27.4 ms
^C
--- 192.168.2.26 ping statistics ---
18 packets transmitted, 17 received, 5% packet loss, time 17027ms
rtt min/avg/max/mdev = 5.672/98.855/212.947/66.057 ms
user@macmini2014:~$

We don’t have Wi-Fi WDS, but I test with AP.

I think thsi issue already resolved?

It’s a know known issue we are working on it. Will keep follow up here.