Is there any WLAN logging we can read for the Repetier pi image WLAN0 handling?

TT_Vert

I'm on a pi3 on latest repetier server pro 1.4.15. I find lately when allowing repetier server to handle wifi it doesn't connect quite often. Then sometimes if i let it sit long enough (5-60 minutes) it'll connect, other times it just won't. I do not now know why. It's not a signal strength issue as I have multiple devices also in this area (5' from AP) and i have zero issues w/ any of them. When connected latency is good so it's certainly not an issue w/ signal integrity. I confirmed I have my region specified as US. I have disabled any static mapping on my router for that MAC just to ensure nothing odd was going on there. I'm not a pi expert so I don't really know where to go w/ this. I feel like there is some conflicting configuration here but I don't even know where to begin to look. Any input would be greatly appreciated.

Dave

Repetier

It all gets logged to /var/log/syslog with all attempts to connect.

Note that when you have default settings to switch to AP on missing network it can take some time to switch back when you get disconnected for some reason. Setting AP to never enable would keep config and reconnect much faster. Only problem is when you have no display or wired connection to fix connection in case something gets wrong.

Last solution is to provide a explicit wpa_solution config file. Then server does not interfere with wifi at all just lets linux connect. From image doc:

Bypass the Wi-Fi configuration through Repetier-Server. If a file /boot/wpa_supplicant-wlan0.conf exists, we will copy this file to wpa_supplicant for Wi-Fi configuration and prevent modification of Wi-Fi settings by Repetier-Server. The /boot folder is also accessible if you mount the sd card on a Windows computer, so it can be defined without direct access. Make sure to use unix line encoding! There is a sample config file /boot/wpa_supplicant wlan0.conf.sample for convenience which you can easily customize and rename.

TT_Vert

<a rel="nofollow" target="blank">Repetier</a> said:

It all gets logged to /var/log/syslog with all attempts to connect.

Note that when you have default settings to switch to AP on missing network it can take some time to switch back when you get disconnected for some reason. Setting AP to never enable would keep config and reconnect much faster. Only problem is when you have no display or wired connection to fix connection in case something gets wrong.

Last solution is to provide a explicit wpa_solution config file. Then server does not interfere with wifi at all just lets linux connect. From image doc:

Bypass the Wi-Fi configuration through Repetier-Server. If a file /boot/wpa_supplicant-wlan0.conf exists, we will copy this file to wpa_supplicant for Wi-Fi configuration and prevent modification of Wi-Fi settings by Repetier-Server. The /boot folder is also accessible if you mount the sd card on a Windows computer, so it can be defined without direct access. Make sure to use unix line encoding! There is a sample config file /boot/wpa_supplicant wlan0.conf.sample for convenience which you can easily customize and rename.

Thanks I took a look. The odd thing is everything was fine for a long time and I know I have no issues w/ connection. I just want to be able to see what exactly is occurring in logs when this happens. There is no reason it should be ever disconnecting as I have multiple other wifi devices right near by and those also have never had a wireless connectivity issue. I have never been underpowered on this unit either. I had actually tried to use the supplicant file and it worked until reboot. Upon checking, the supplicant file was back to the default settings which i found odd. I really like your hotspot option when there is an issue and using your web UI to configure the wifi so i'd like to keep it unless I have no choice. Doing some research it seems others have run into bugs that may be related to the status_code=16 error. Oddly, I have NOT seen this status code since yesterday at 3PM so whatever was happening is NOT happening for now. I'd assume if it was a bigger issue you would have been aware of it so it's likely something strange on my end that I need to try to figure out.

Some other known issues that may be relevant here?
Seems a known issue was mmm and disabling fixed it

Seems fast roaming is another issue others have:

Looking at logs I see AUTH failure, does this mean the WPA was not accepted? I do find that odd as it hasn't changed AND It did start to connect again later. I have many of these retries (It seems it tries 3 times and stops)

Jan 6 12:06:47 pi wpa_supplicant[443]: wlan0: CTRL-EVENT-SSID-REENABLED id=0 ssid="DNA"

Jan 6 12:06:47 pi wpa_supplicant[443]: wlan0: Trying to associate with SSID 'DNA'

Jan 6 12:06:48 pi wpa_supplicant[443]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=78:8a:20:5d:07:2c status_code=16

Jan 6 12:06:48 pi wpa_supplicant[443]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="DNA" auth_failures=2 duration=23 reason=CONN_FAILED

No changes made and then it connects.

Jan 6 12:12:17 pi dhcpcd[426]: wlan0: waiting for carrier

Jan 6 12:12:18 pi wpa_supplicant[443]: wlan0: Trying to associate with SSID 'DNA'

Jan 6 12:12:19 pi wpa_supplicant[443]: wlan0: Associated with 18:e8:29:a4:d7:d2

Jan 6 12:12:19 pi wpa_supplicant[443]: wlan0: CTRL-EVENT-CONNECTED - Connection to 18:e8:29:a4:d7:d2 completed [id=0 id_str=]

Jan 6 12:12:19 pi wpa_supplicant[443]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0

Jan 6 12:12:19 pi dhcpcd[426]: wlan0: carrier acquired

Jan 6 12:12:19 pi dhcpcd[426]: wlan0: connected to Access Point DNA'</div><div>Jan 6 12:12:19 pi kernel: [ 420.694292] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready</div><div>Jan 6 12:12:19 pi dhcpcd[426]: DUID 00:01:00:01:29:dd:9e:61:b8:27:eb:32:41:d5</div><div>Jan 6 12:12:19 pi dhcpcd[426]: wlan0: IAID eb:fb:0e:55<br/><br/><b>Later on (At this point I may have been making changes to try to correct this)<br/></b><br/><div>Jan 7 11:41:59 pi wpa_supplicant[403]: wlan0: Trying to associate with SSID 'DNA'</div><div>Jan 7 11:41:59 pi hostapd[469]: wlan0: Could not connect to kernel driver<br/></div><div>Jan 7 11:41:59 pi hostapd[469]: Interface initialization failed</div><div>Jan 7 11:41:59 pi hostapd[469]: wlan0: interface state COUNTRY_UPDATE->DISABLED</div><div>Jan 7 11:41:59 pi hostapd[469]: wlan0: AP-DISABLED</div><div>Jan 7 11:41:59 pi hostapd[469]: wlan0: Unable to setup interface.</div><div>Jan 7 11:41:59 pi hostapd[469]: wlan0: interface state DISABLED->DISABLED</div><div>Jan 7 11:41:59 pi hostapd[469]: wlan0: AP-DISABLED</div><div>Jan 7 11:41:59 pi hostapd[469]: wlan0: CTRL-EVENT-TERMINATING</div><div>Jan 7 11:41:59 pi hostapd[469]: hostapd_free_hapd_data: Interface wlan0 wasn't started</div><div>Jan 7 11:41:59 pi hostapd[469]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0</div><div>Jan 7 11:41:59 pi wpa_supplicant[403]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD</div><div>Jan 7 11:41:59 pi wpa_supplicant[403]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US</div><div>Jan 7 11:42:00 pi dhcpcd[414]: wlan0: carrier acquired</div></div></div></div><div><div>Jan 7 11:42:00 pi dhcpcd[414]: wlan0: carrier lost</div><div>Jan 7 11:42:00 pi dhcpcd[414]: wlan0: deleting address fe80::ba27:ebff:fefb:e55</div><div>Jan 7 11:42:00 pi wpa_supplicant[403]: wlan0: Associated with 78:8a:20:5d:07:2c</div><div>Jan 7 11:42:00 pi wpa_supplicant[403]: wlan0: CTRL-EVENT-CONNECTED - Connection to 78:8a:20:5d:07:2c completed [id=0 id_str=]</div><div>Jan 7 11:42:00 pi wpa_supplicant[403]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0</div><div>Jan 7 11:42:00 pi wpa_supplicant[403]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US</div><div>Jan 7 11:42:00 pi dhcpcd[414]: wlan0: carrier acquired</div><div>Jan 7 11:42:00 pi dhcpcd[414]: wlan0: connected to Access PointDNA'

Jan 7 11:42:00 pi dhcpcd[414]: wlan0: IAID eb:fb:0e:55

Jan 7 11:42:00 pi dhcpcd[414]: wlan0: adding address fe80::ba27:ebff:fefb:e55

Jan 7 11:42:00 pi dhcpcd[414]: wlan0: probing address 192.168.15.4/24

Jan 7 11:42:00 pi dhcpcd[414]: wlan0: carrier lost

Jan 7 11:42:00 pi dhcpcd[414]: wlan0: deleting address fe80::ba27:ebff:fefb:e55

Jan 7 11:42:00 pi dhcpcd[414]: wlan0: carrier acquired

Jan 7 11:42:00 pi dhcpcd[414]: wlan0: IAID eb:fb:0e:55

Jan 7 11:42:00 pi dhcpcd[414]: wlan0: adding address fe80::ba27:ebff:fefb:e55

Jan 7 11:42:00 pi dhcpcd[414]: wlan0: probing address 192.168.15.4/24

Jan 7 11:42:02 pi wpa_supplicant[403]: wlan0: CTRL-EVENT-DISCONNECTED bssid=78:8a:20:5d:07:2c reason=3 locally_generated=1

Jan 7 11:42:02 pi dhcpcd[414]: wlan0: carrier lost

Jan 7 11:42:02 pi wpa_supplicant[403]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD

Jan 7 11:42:02 pi wpa_supplicant[403]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US

Jan 7 11:42:02 pi hostapd[597]: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE

Jan 7 11:42:02 pi hostapd[597]: Using interface wlan0 with hwaddr b8:27:eb:fb:0e:55 and ssid "RepetierServer"

Jan 7 11:42:02 pi dhcpcd[414]: wlan0: deleting address fe80::ba27:ebff:fefb:e55

Jan 7 11:42:02 pi avahi-daemon[381]: Withdrawing address record for fe80::ba27:ebff:fefb:e55 on wlan0.

Jan 7 11:42:02 pi avahi-daemon[381]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::ba27:ebff:fefb:e55.

Jan 7 11:42:02 pi avahi-daemon[381]: Interface wlan0.IPv6 no longer relevant for mDNS.

Jan 7 11:42:02 pi systemd[1]: systemd-rfkill.service: Succeeded.

Jan 7 11:42:02 pi dhcpcd[414]: wlan0: carrier acquired

Jan 7 11:42:02 pi hostapd[597]: wlan0: interface state COUNTRY_UPDATE->ENABLED

Jan 7 11:42:02 pi hostapd[597]: wlan0: AP-ENABLED

Jan 7 11:42:02 pi systemd[1]: Started Access point and authentication server for Wi-Fi and Ethernet.

Jan 7 11:42:02 pi dhcpcd[414]: wlan0: IAID eb:fb:0e:55

Jan 7 11:42:02 pi dhcpcd[414]: wlan0: adding address fe80::ba27:ebff:fefb:e55

Jan 7 11:42:02 pi dhcpcd[414]: wlan0: probing address 192.168.15.4/24

Jan 7 11:42:02 pi wpa_supplicant[403]: wlan0: Trying to associate with SSID 'DNA'

Jan 7 11:42:02 pi dhcpcd[414]: wlan0: carrier lost

Jan 7 11:42:02 pi dhcpcd[414]: wlan0: deleting address fe80::ba27:ebff:fefb:e55

Jan 7 11:42:02 pi wpa_supplicant[403]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD

Jan 7 11:42:02 pi wpa_supplicant[403]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US

Jan 7 11:42:02 pi dhcpcd[414]: wlan0: carrier acquired

Repetier

hostapd/dnsmasq are when AP gets enabled. I assume the switch was triggered. This can happen if a scan for the DNA network does not show in AP list. Sometimes the query gets shorter or even empty also we ignore already empty. Have some ideas for next release to not react that fast for a switch and maybe I find a solution to even see if connection is still valid. Need to recheck the logic.

TT_Vert

That is very strange and the SSID is always broadcasting. Also remember there were times it did NOT even connect to my AP at all, rather it just enabled the Repetier AP for me to connect to it. Does status_code=16 mean that the WPA key was incorrect? That is what is interesting to me because if it says that and then minutes later it connects to that AP without me changing anything that means something isn't right.

Dave

Repetier

Main problem is when it disconnects an existing connection or when you check available AP lists. Then server will try to query AP available and see if there is something to connect to. As I saw now list is not always complete so I made a new dev version that keeps the seen router for a while, only when it does not show up 5 times in a row it would assume the AP is gone. Until this happen linux would try to reconnect with latest connection. Should make it not switch so fast to AP mode and come back quicker and disconnect not from a single bad scan result.

Unfortunately I'm no linux wifi expert and con say what all the error codes mean. Our scripts just set configuration for the router and we leave everything to linux here.

You can try it with running
installDev
on ssh connection. New version also now reads gpio output from pin state so externally changed output pin gets detected.