Hi,
I setup the Vim3 with Gnome Linux 4.9.241 distribution (tried several others too with the same results). I plugged in a wired network connection and updated the distribution. Then I unplugged it.
Next, I set it up as a wireless access point (I am getting the same errors if I use NetworkManager or hostapd for this part). I’m using dnsmasq for the dhcp server. The level of wifi security doesn’t seem to have any impact on the issue.
I can then use wifi to connect iPhone (multiple versions), Samsung (Multiple versions), or Macbook to the Vim3 and everything works fine. The phones can connect to each other via the wifi without any problem.
BUT, as soon as I connect a Xiaomi phone to it something in Linux under the hood gets broken on the Vim3. I think the wifi driver is getting messed up for some reason. All the connected devices (i.e. phones) lose the ability to communicate shortly after I connect the Xiaomi phone. I can leave them running for hours without a problem as long as I don’t connect this one phone.
Once I connect the Xiaomi the following gets logged in the /var/log/syslog (Note the repeating “Link UP” messages - these messages don’t get repeatedly logged for any of the other phones like this one:
Apr 14 16:53:32 localhost kernel: [ 145.505362@5] wl_notify_connect_status_ap: connected device 34:1c:f0:fb:d4:50
Apr 14 16:53:32 localhost hostapd: wlan0: STA 34:1c:f0:fb:d4:50 IEEE 802.11: associated
Apr 14 16:53:32 localhost kernel: [ 145.514096@0] CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Apr 14 16:53:32 localhost hostapd: wlan0: STA 34:1c:f0:fb:d4:50 RADIUS: starting accounting session C3AC40575D41A1E9
Apr 14 16:53:32 localhost hostapd: wlan0: STA 34:1c:f0:fb:d4:50 WPA: pairwise key handshake completed (RSN)
Apr 14 16:53:32 localhost dnsmasq-dhcp[5326]: DHCPDISCOVER(wlan0) 34:1c:f0:fb:d4:50
Apr 14 16:53:32 localhost dnsmasq-dhcp[5326]: DHCPOFFER(wlan0) 10.10.0.68 34:1c:f0:fb:d4:50
Apr 14 16:53:32 localhost dnsmasq-dhcp[5326]: DHCPREQUEST(wlan0) 10.10.0.68 34:1c:f0:fb:d4:50
Apr 14 16:53:32 localhost dnsmasq-dhcp[5326]: DHCPACK(wlan0) 10.10.0.68 34:1c:f0:fb:d4:50 M2007J3SG-Mi10TPro
Apr 14 16:53:32 localhost kernel: [ 145.742819@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:53:33 localhost kernel: [ 145.861709@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:53:41 localhost kernel: [ 153.858902@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:53:46 localhost kernel: [ 158.888942@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:54:02 localhost kernel: [ 175.066544@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:54:18 localhost kernel: [ 191.007150@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:54:22 localhost kernel: [ 194.927944@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:54:33 localhost kernel: [ 206.323045@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:54:59 localhost kernel: [ 232.223708@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:55:01 localhost CRON[5933]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Apr 14 16:55:04 localhost kernel: [ 237.252561@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:55:09 localhost kernel: [ 242.273690@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:55:41 localhost kernel: [ 273.882656@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:55:49 localhost kernel: [ 282.617568@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:55:54 localhost kernel: [ 287.627147@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:56:01 localhost kernel: [ 294.470251@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 16:56:05 localhost kernel: [ 298.455621@5] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
After it tips over the SSID continues to be visible but nothing can connect to it now and if devices were previously connected they remain connected but cannot actually communicate with it.
Any thoughts? This seems like a driver issue but…
Thanks,
Bruce.
That was my thought as well, and other devices do work (iPhone, Samsung are fine).
However, even if I reset the Xiaomi to factory defaults I get the same results.
Presumably that would remove any spyware?
Connecting this phone to the access point leaves the Vim3 advertising the SSID but nothing can connect to it and all the connectivity gets broken.
I don’t understand how spyware would break the entire access point like that so it has to be rebooted to become functional again? Seems like a bug…
Thanks,
Bruce.
alsdfjqwoeprjqwp;mfvsadpvmwqeor
Interesting.
I’ll flash the image again and set it up fresh and re-test with the phone rest to factory defaults.
I’ll let you know what happens either way once I get it done.
This does lead me a few additional questions though:
- Do you know if there’s a patch to address this vulnerability (or one coming)?
- Is there a log message I could look for that would reveal the exploit was used?
- Is there a package I can install to protect against this kind of thing?
Thanks, I appreciate the help!
Bruce.
Will do, thanks.
That basically means this device cannot be used in a production setting as an access point then I guess.
If a phone can break it and this vector has been around for a long time and there’s no protection against it then it kind of reads like “don’t use this device for this purpose if you require it to be reliable”.
Bruce.
Sorry - that’s not where I’m coming from at all. I really like this board.
Is there a way to address the issue I guess is my question?
Not trying to blame Vim - just trying to get to a point where I can rely on it as an access point in the field.
If the issue is hardware then a new board rev would fix it I guess. Sometimes there’s a software fix too.
I’ve been a software engineer (including some time in RTOS and Linux kernel space) for over 30 years. I’m just trying to find a solution to a strange problem.
I do appreciate your help, and I’m sorry for this making you feel uncomfortable.
Bruce.
No offense taken.
I too been around since the days of single floppy disk drive. I did delete my comments, internet security is a very complicated issue.
Agreed re security, very complex.
This is my first time into the Wifi arena so I’m casting about a little here.
I also haven’t seen this issue with off the shelf AP’s (Linksys, Rukus) and this phone so I expected this was something that could be addressed somehow since I expect those devices are both also running Linux.
Anyway, thanks for trying.
I’ll see where your earlier suggestions take me but I probably won’t pursue this board being an AP in production unless I can find a way to address this…and if I do find a solution I’ll post the solution here.
Cheers,
Bruce.
Bad actors are always going to find a new way to breach a system. You might not have noticed it with your other AP devices because they were successful at breaching them and reset the system.
Only way to make a network secure is to air-gap from the internet. When its connected to the internet you just have to limit your exposure.
You can get a security gateway place that upstream directly after the modem. Get one that does deep packet and looks at all your outbound.
The design we’re planning on is to be disconnected from the public net “most of the time”. However, as soon as you allow someone’s phone then you’re (obviously) exposed to anything they’ve been exposed to as well.
In this specific case though the phone is making the wifi non-functional while the board is NOT connected to the public net. There’s just a couple other phones that are connected in a private network setup. The Vim3 is also running dnsmasq so we’re in our own bubble here.
The other AP devices are also disconnected from both corporate and public networks as well so there’s not much to breach.
I looked at wireshark traces and didn’t see anything leaping out at me with regards to DoS stuff so I figured something weird was breaking a driver behind the scenes. Also, the recurring syslog message that I only see when this phone connects kind of grabbed my attention.
And I take your point on deep inspection, nothing thought about on that front yet either.
I guess if this phone is considered a bad actor I would prefer it get kicked off the network rather than everything just stopping working…dunno, just thinking out loud here.
Bruce.
Exact same thing I was thinking about that phone. Its much cheaper to toss it in the trash than spend hours tilting at windmills.
LOL, I wish I had never come across it too.
But since I have I’m stuck with the fact that it causes an issue that isn’t OK in the field.
I may end up buying an AP and connecting it to this board or something if I can’t solve the wifi problem any other way.
Thanks,
Bruce.
Well, just to provide an update:
I flashed a new card for the Vim3 (thanks @foxsquirrel) and reset the Xiaomi phone to factory defaults.
I setup hostapd and dnsmasq again. This time I’m connected to the internet through the Vim3 and have also setup ip-forwarding, IP-Tables and DNS info to be served through dnsmasq.
I connected a Samsung Galaxy S8 to the AP and had no problems. Fired up youtube and started running a 1 hour video.
About 20 minutes into that video I connected the Xiaomi phone (reset to factory defaults) to the Wifi and the Vim3 logged the following and stopped streaming the video to the Samsung at the same time. The SSID continued to be advertised but no phone can succeed in connecting and attempts don’t cause any new logging in /var/log/syslog:
Apr 14 20:30:23 localhost kernel: [ 1510.148415@2] wl_notify_connect_status_ap: connected device 34:1c:f0:fb:d4:50
Apr 14 20:30:23 localhost kernel: [ 1510.148699@2] CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Apr 14 20:30:23 localhost hostapd: wlan0: STA 34:1c:f0:fb:d4:50 IEEE 802.11: associated
Apr 14 20:30:23 localhost hostapd: wlan0: STA 34:1c:f0:fb:d4:50 RADIUS: starting accounting session FE24F933FF4FCFE9
Apr 14 20:30:23 localhost hostapd: wlan0: STA 34:1c:f0:fb:d4:50 WPA: pairwise key handshake completed (RSN)
Apr 14 20:30:26 localhost dnsmasq-dhcp[5975]: DHCPDISCOVER(wlan0) 34:1c:f0:fb:d4:50
Apr 14 20:30:26 localhost dnsmasq-dhcp[5975]: DHCPOFFER(wlan0) 10.10.0.68 34:1c:f0:fb:d4:50
Apr 14 20:30:26 localhost dnsmasq-dhcp[5975]: DHCPREQUEST(wlan0) 10.10.0.68 34:1c:f0:fb:d4:50
Apr 14 20:30:26 localhost dnsmasq-dhcp[5975]: DHCPACK(wlan0) 10.10.0.68 34:1c:f0:fb:d4:50 M2007J3SG-Mi10TPro
Apr 14 20:30:26 localhost kernel: [ 1513.349810@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:26 localhost kernel: [ 1513.509644@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:26 localhost kernel: [ 1513.561067@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1513.820641@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1513.910168@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1514.094137@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1514.171588@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1514.209492@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1514.328692@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1514.423410@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1514.463930@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1514.514603@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1514.588851@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:27 localhost kernel: [ 1514.633580@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:28 localhost kernel: [ 1514.673862@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:28 localhost kernel: [ 1514.715005@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:28 localhost kernel: [ 1514.784501@2] wl_iw_event: Link UP with 10:2c:6b:cb:37:5b
Apr 14 20:30:50 localhost hostapd: wlan0: STA b8:d7:af:6b:0f:bb IEEE 802.11: disassociated
Apr 14 20:30:50 localhost kernel: [ 1537.463599@2] wl_notify_connect_status_ap: event WLC_E_DEAUTH(5) status 0 reason 4
Apr 14 20:30:50 localhost kernel: [ 1537.463604@2] wl_notify_connect_status_ap: deauthenticated device b8:d7:af:6b:0f:bb
Apr 14 20:30:50 localhost kernel: [ 1537.466258@2] wl_cfg80211_del_station: Disconnect STA : b8:d7:af:6b:0f:bb scb_val.val 3
@numbqq, @Frank (or anyone else) if you have any ideas I’d love to hear them.
Thanks,
Bruce.