Static Wifi configuration with wrong password is still detected as active

[kevin.onsolution]

Hello,

I have a Dragino LPS8 LoRa gateway which I have running OpenWRT 19.07.

I have been trying to set up a static WiFi configuration which works fine.

My network config file

config interface 'trm_wwan'
	option proto 'static'
	option metric '2'
	option dns '8.8.8.8'
	option netmask '255.255.255.0'
	option ipaddr '192.168.0.201'
	option gateway '192.168.0.1'

My wireless config file (running on an sta+ap setup on radio0)

config wifi-iface 'ap_0'
	option device 'radio0'
	option ifname 'wlan0'
	option network 'lan'
	option mode 'ap'
	option hidden '0'
	option maxassoc '30'
	option disabled '0'
	option encryption 'psk2'
	option key 'ap-pass'
	option ssid 'ap-ssid'

config wifi-iface 'sta_0'
	option device 'radio0'
	option network 'trm_wwan'
	option mode 'sta'
	option ssid 'OPTUS_360125'
	option encryption 'psk2'
	option key 'WRONGPASSHERE'
	option ifname 'wlan0-1'
	option disabled '0'

The problem is that when I change the password to a wrong password. The LuCi interface will still show its connected. (Tested by running wifi and etc/init.d/network reload and rebooting the device)

I was just wondering why it would say it is connected even though it clearly shouldn't work with the wrong password.

I did a dive into how connectivity is determined, and I am semi certain it checks if "up" is true when running ubus call network.interface.trm_wwan status in my case this will give {up:true}. I'm unsure on why this value would give true even though my network configuration has the wrong password.

[anon89577378]

You did Save and Apply after making the change in LuCI?

Or, uci commit of the WiFi config file from the CLI?

[kevin.onsolution]

I used uci commit wireless and uci commit network then applied wifi and etc/init.d/network reload afterwards to apply the settings. I'm fairly sure I applied the config settings properly. I tried changing the dns for example to 1.1.1.1 in the network config to check if the settings actually do apply

(in luci)

(this is still with putting the wrong password in my wireless config)

[anon89577378]

Did you do /etc/<path/config file> restart?

[kevin.onsolution]

just attempted /etc/init.d/network restart which seems to give the same result

[anon89577378]

You need the wifi config file path and name

[kevin.onsolution]

oh right my bad, when I run that I get this.

I wasn't aware you could run restart on config files as well. I thought you could only use restart on init.d scripts?

[anon89577378]

Actually...my bad.

No wireless config in init.d

Take down your wireless config images.

Your password is included.

Try Restart in LuCI > Network > Wireless.

[kevin.onsolution]

So I clicked restart in here and after waiting a bit it seems to still show my network as still active.

[trendy]

I suppose you are using travelmate on this router, which is actively scanning for available SSIDs to connect. If you configure the wrong PSK, are you able to actually connect to the AP, regardless of what the Luci says? Can you ping the AP or some address on the internet?

[kevin.onsolution]

Yes I am using travelmate. I've actually been trying to incorporate static IP with travelmate but I found I had to modify the travelmate.sh script slightly to allow for that. I'm actually unsure if travelmate even supports static options.

So for trying a wrong encryption method I did something like this

config wifi-iface 'sta_0'
   option device 'radio0'
   option network 'trm_wwan'
   option mode 'sta'
   option ssid 'OPTUS_360125'
   option encryption 'wrong'
   option key 'wrongpass'
   option ifname 'wlan0-1'
   option disabled '1'

When I try the above configuration with a wrong encryption it works fine, travelmate attempts to check if the connection is possible and fails after several attempts. Which causes it to disable. So it works as expected and it won't show the wifi as active in luci as well. The AP eventually becomes accessible after the 5 attempts below.

but when I use option encryption 'psk2' with the wrong password still. In this case the AP is not accessible at all. It shows that it connects to the uplink in travelmate when using this config.

I am unsure if encryption is the reason that a bad password would make the system think it is still connected. I tried 'sae' and 'wpa3' and it does the same thing as 'psk2'.

In all cases with the wrong password I cannot ping the the new static ip address (192.168.0.201) and I cannot ssh into this new address to test if I can ping some address on the internet.

[trendy]

I think it would be best to discuss this problem in the support topic for travelmate.

[kevin.onsolution]

I can reproduce the same problem without travelmate. I removed travelmate from the build and used wwan interface instead with the same faulty config (wrong pass and wrong encryption). The LuCi interface will still show its connected.

• netifd will say wwan is up in logread -e "netifd"
• ubus returns up as true

But even without travelmate I'm just wondering if this is meant to return {up:true} even though my wifi config is incorrect. I kind of have a feeling it might just be something to do with the router tables or firewalls where even with the wrong WiFi details it will still use the ethernet interface to connect but I am unsure how to check that.

[anon89577378]

You already know the config is "faulty", so why not just do a reset and config from scratch.

[kevin.onsolution]

For a bit more context, we want to use this device as an IOT device. So we'll potentially have customers set up their wifi config details. But if it says it is connected, they will think that it is connected even though it actually isn't. Which is the main reason I need to know that the WiFi is actually wrong based on a wrong config.

I know its faulty because I'm just testing it but I guess customers wouldn't be able to know and they would get false positives of it being connected.

[anon89577378]

So the solution sounds like re-configuring it correctly.

A reset and configure from scratch would accomplish that.

[trendy]

The up=true is not the same as connected to the Access Point. The interface can be up and have an address configured since you have it declared with static protocol, but the connection to the Access Point is not established.

[kevin.onsolution]

Oh right makes sense, I didn't know there was a distinction between interface being up and the access point actually having a connection.

I should be able to overcome this issue by adding checks on the WiFi level instead of just the interface.

For example https://openwrt.org/docs/guide-user/network/wifi/wireless-tool/wireless.utilities
I can use iwconfig wlan0-1 command to see if the internet is actually there rather than only just the interface.

Where Access Point : Not Associated would actually show its disconnected from the internet as well.

Also found out you can look down to /proc/net/wireless file to find out if it is active as well.

Strange to me the Luci interface doesn't check if it actually has connection to the access point and only checks the interface is up.

Anyways, thanks for the help guys

[trendy]

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.