Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Merkwuerdigkeiten mit einem RasPi im WLAN
352 views
Skip to first unread message
Sebastian Suchanek
Oct 8, 2021, 3:07:19 PM10/8/21
to
Hallo NGs!
Vorweg: das folgende Problem ist etwas verworren und
langwierig zu beschreiben - ich hoffe, ich bekomme es
trotzdem nachvollziehbar erklärt.
Ausgangspunkt ist ein Raspberry Pi 3B+, den ich hier schon
seit einiger Zeit im WLAN betreibe. Als ich den Damals[tm]
eingerichtet habe, war er nur in Reichweite eines einzelnen
Accesspoints (nennen wir in "A"). Ich habe über raspi-config
die SSID und das Passwort (WPA2) eingetragen und das Ding
lief. Irgendwann später habe ich noch einen zweiten
Accesspoint ("B") in Betrieb genommen, der ebenfalls in
Reichweite des fraglichen RasPis ist. Das hat den RasPi
erstmal nicht weiter beeindruckt, er war weiterhin mit AP "A"
verbunden und hat sich auch nach Neustarts wieder mit "A" neu
verbunden.
Seit ein paar Tagen ist der RasPi jedoch bei 100%ig
unveränderter Konfiguration der Meinung, dass ihm AP "B"
besser gefiele und er will sich damit verbinden, allerdings
bekommt er dort keine Verbindung.
Als der RasPi im laufenden Betrieb beschlossen hat, auf AP
"B" zu wechseln, steht in /var/log/syslog nur lapidar:
| [...]
| Oct 6 15:24:14 heizungspi dhcpcd[465]: wlan0: carrier lost
| Oct 6 15:24:14 heizungspi dhcpcd[465]: wlan0: deleting address fe80::8201:8889:a1e6:3791
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Withdrawing address record for fe80::8201:8889:a1e6:3791 on wlan0.
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::8201:8889:a1e6:3791.
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Interface wlan0.IPv6 no longer relevant for mDNS.
| Oct 6 15:24:14 heizungspi dhcpcd[465]: wlan0: deleting default route via 10.1.0.1
| Oct 6 15:24:14 heizungspi dhcpcd[465]: wlan0: deleting route to 10.1.0.0/16
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Withdrawing address record for 10.1.11.3 on wlan0.
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.1.11.3.
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Interface wlan0.IPv4 no longer relevant for mDNS.
| [...]
Bei einem Neustart sieht das ganze in /var/log/syslog so aus:
| [...]
| Oct 8 17:56:34 heizungspi systemd[1]: Started WPA supplicant.
| Oct 8 17:56:34 heizungspi wpa_supplicant[340]: Successfully initialized wpa_supplicant
| Oct 8 17:56:34 heizungspi systemd[1]: Started Raise network interfaces.
| Oct 8 17:56:34 heizungspi kernel: [ 5.439500] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
| Oct 8 17:56:34 heizungspi kernel: [ 5.439521] brcmfmac: power management disabled
| [...]
| Oct 8 17:56:35 heizungspi dhcpcd[308]: eth0: waiting for carrier
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: waiting for carrier
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: carrier acquired
| Oct 8 17:56:35 heizungspi kernel: [ 5.767391] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
| Oct 8 17:56:35 heizungspi dhcpcd[308]: DUID 00:01:00:01:22:69:57:00:b8:27:eb:94:fa:49
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: IAID eb:31:61:97
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: adding address fe80::fb78:1bda:3d6:e064
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: carrier lost
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::fb78:1bda:3d6:e064.
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: New relevant interface wlan0.IPv6 for mDNS.
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: Registering new address record for fe80::fb78:1bda:3d6:e064 on wlan0.*.
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: deleting address fe80::fb78:1bda:3d6:e064
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: Withdrawing address record for fe80::fb78:1bda:3d6:e064 on wlan0.
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::fb78:1bda:3d6:e064.
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: Interface wlan0.IPv6 no longer relevant for mDNS.
| Oct 8 17:56:35 heizungspi kernel: [ 6.168024] uart-pl011 3f201000.serial: no DMA platform data
| Oct 8 17:56:36 heizungspi dhcpcd[308]: eth0: carrier acquired
| Oct 8 17:56:36 heizungspi kernel: [ 6.794917] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
| Oct 8 17:56:36 heizungspi dhcpcd[308]: eth0: IAID eb:64:34:c2
| Oct 8 17:56:36 heizungspi dhcpcd[308]: eth0: adding address fe80::d5e0:d6ca:888:4c1a
| Oct 8 17:56:36 heizungspi avahi-daemon[316]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::d5e0:d6ca:888:4c1a.
| Oct 8 17:56:36 heizungspi avahi-daemon[316]: New relevant interface eth0.IPv6 for mDNS.
| Oct 8 17:56:36 heizungspi avahi-daemon[316]: Registering new address record for fe80::d5e0:d6ca:888:4c1a on eth0.*.
| Oct 8 17:56:36 heizungspi dhcpcd[308]: eth0: rebinding lease of 10.1.2.11
| Oct 8 17:56:36 heizungspi dhcpcd[308]: eth0: soliciting an IPv6 router
(Die LAN-Verbindung über eth0 habe ich provisorisch zu
Debug-Zwecken angeschlossen. Eine dauerhafte Anbindung
mittels LAN ist mit vertretbarem Aufwand nicht möglich.)
Nach ein wenig Herumstochern im Nebel habe ich gemerkt, dass
es möglicherweise mit wpa_supplicant zusammenhängt. Starte
ich wpa_supplicant direkt von der Konsole (nicht als
Service), erhalte ich folgendes:
| # wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf
| Successfully initialized wpa_supplicant
| wlan0: Trying to associate with SSID 'orbit'
| wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
| wlan0: Trying to associate with SSID 'orbit'
| wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
| wlan0: Trying to associate with SSID 'orbit'
| wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Und immer so weiter, bis ich wpa_supplicant mit Crtl+C
abwürge. Verwende ich allerdings den wext-Treiber, sieht die
Sache anders aus:
| # wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf
| Successfully initialized wpa_supplicant
| ioctl[SIOCSIWENCODEEXT]: Invalid argument
| ioctl[SIOCSIWENCODEEXT]: Invalid argument
| wlan0: Trying to associate with 68:d7:9a:5f:0b:57 (SSID='orbit' freq=2437 MHz)
| wlan0: Authentication with 68:d7:9a:5f:0b:57 timed out.
| wlan0: CTRL-EVENT-DISCONNECTED bssid=68:d7:9a:5f:0b:57 reason=3 locally_generated=1
| ioctl[SIOCSIWSCAN]: Resource temporarily unavailable
| wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
| ioctl[SIOCSIWSCAN]: Resource temporarily unavailable
| wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
| ioctl[SIOCSIWSCAN]: Resource temporarily unavailable
| wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
| wlan0: Trying to associate with f0:9f:c2:a7:cb:aa (SSID='orbit' freq=2412 MHz)
| wlan0: Associated with f0:9f:c2:a7:cb:aa
| wlan0: WPA: Key negotiation completed with f0:9f:c2:a7:cb:aa [PTK=CCMP GTK=CCMP]
| wlan0: CTRL-EVENT-CONNECTED - Connection to f0:9f:c2:a7:cb:aa completed [id=0 id_str=]
Auch hier will sich wpa_supplicant zuerst mit AP "B"
verbinden, merkt aber, dass das nicht geht, und wechselt zu
AP "A", wo er wie gewohnt eine Verbindung bekommt.
| # iwconfig wlan0
| wlan0 IEEE 802.11 ESSID:"orbit"
| Mode:Managed Frequency:2.412 GHz Access Point: F0:9F:C2:A7:CB:AA
| Bit Rate=65 Mb/s Tx-Power=31 dBm
| Retry short limit:7 RTS thr:off Fragment thr:off
| Encryption key:off
| Power Management:on
| Link Quality=48/70 Signal level=-62 dBm
| Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
| Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Daraufhin habe ich sowohl versucht, die Frequenz (und damit
indirekt den AP) in wpa_supplicant.conf festzunageln...
| ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
| update_config=1
| country=DE
|
| network={
| ssid="orbit"
| freq_list=2412
| psk="HierStehtNatürlichDasRichtigeWLANPAsswort"
| }
...als auch testweise in /lib/systemd/system/wpa_supplicant@.service
die Zeile...
| ExecStart=/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -Dnl80211,wext -i%I
...zu...
| ExecStart=/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf -Dwext -i%I
...abgeändert in der Hoffnung, dass wpa_supplicant
"dauerhaft" den wext-Treiber verwendet. Das alles aber
bislang ohne Effekt - wenn ich wpa_supplicant als Service
starte, tut das zwar ohne Fehlermeldung und der
Service-Status sagt "running", eine WLAN-Verbindung kommt
aber trotzdem nicht zustande.
Verwunderlich ist aber ohnehin, dass die Verbindung bei AP
"B" nicht klappen mag. Beide APs sind Ubiquity Unifis ("A"
ist ein "Lite" auf Kanal 1, "B" ist ein "nano HD" auf Kanal
6), beide werden von einem Controller gemanagt und beide
haben, abgesehen von der Kanalwahl im 2,4-GHz-Band, keine
individuellen Konfigurationen, sondern übernehmen alles von
der "Site".
Dieses ganze Problem wirft nun natürlich sozusagen zweigleisig Fragen auf:
1. Woran könnte es liegen, dass keine Verbindung mit AP "B"
zustande kommen will? Die o.g. Fehlermeldung
"CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00
status_code=16" habe ich natürlich schon in Google
eingeworfen, aber die Fundstücke bringen mich nicht wirklich
weiter. (U.a. deshalb, weil der fragliche Pi headless läuft
und gar nichts HDMI-mäßiges angeschlossen ist.)
2. Wie kann ich wpa_supplicant dazu bringen, sich
ausschließlich mit AP "A" zu verbinden?
TIA,
Sebastian
PS: XP dcounm & dchnw, f'up erstmal nach dcounm
--
X-Post, FollowUp-To de.comp.os.unix.networking.misc
Vorweg: das folgende Problem ist etwas verworren und
langwierig zu beschreiben - ich hoffe, ich bekomme es
trotzdem nachvollziehbar erklärt.
Ausgangspunkt ist ein Raspberry Pi 3B+, den ich hier schon
seit einiger Zeit im WLAN betreibe. Als ich den Damals[tm]
eingerichtet habe, war er nur in Reichweite eines einzelnen
Accesspoints (nennen wir in "A"). Ich habe über raspi-config
die SSID und das Passwort (WPA2) eingetragen und das Ding
lief. Irgendwann später habe ich noch einen zweiten
Accesspoint ("B") in Betrieb genommen, der ebenfalls in
Reichweite des fraglichen RasPis ist. Das hat den RasPi
erstmal nicht weiter beeindruckt, er war weiterhin mit AP "A"
verbunden und hat sich auch nach Neustarts wieder mit "A" neu
verbunden.
Seit ein paar Tagen ist der RasPi jedoch bei 100%ig
unveränderter Konfiguration der Meinung, dass ihm AP "B"
besser gefiele und er will sich damit verbinden, allerdings
bekommt er dort keine Verbindung.
Als der RasPi im laufenden Betrieb beschlossen hat, auf AP
"B" zu wechseln, steht in /var/log/syslog nur lapidar:
| [...]
| Oct 6 15:24:14 heizungspi dhcpcd[465]: wlan0: carrier lost
| Oct 6 15:24:14 heizungspi dhcpcd[465]: wlan0: deleting address fe80::8201:8889:a1e6:3791
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Withdrawing address record for fe80::8201:8889:a1e6:3791 on wlan0.
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::8201:8889:a1e6:3791.
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Interface wlan0.IPv6 no longer relevant for mDNS.
| Oct 6 15:24:14 heizungspi dhcpcd[465]: wlan0: deleting default route via 10.1.0.1
| Oct 6 15:24:14 heizungspi dhcpcd[465]: wlan0: deleting route to 10.1.0.0/16
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Withdrawing address record for 10.1.11.3 on wlan0.
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.1.11.3.
| Oct 6 15:24:14 heizungspi avahi-daemon[328]: Interface wlan0.IPv4 no longer relevant for mDNS.
| [...]
Bei einem Neustart sieht das ganze in /var/log/syslog so aus:
| [...]
| Oct 8 17:56:34 heizungspi systemd[1]: Started WPA supplicant.
| Oct 8 17:56:34 heizungspi wpa_supplicant[340]: Successfully initialized wpa_supplicant
| Oct 8 17:56:34 heizungspi systemd[1]: Started Raise network interfaces.
| Oct 8 17:56:34 heizungspi kernel: [ 5.439500] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
| Oct 8 17:56:34 heizungspi kernel: [ 5.439521] brcmfmac: power management disabled
| [...]
| Oct 8 17:56:35 heizungspi dhcpcd[308]: eth0: waiting for carrier
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: waiting for carrier
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: carrier acquired
| Oct 8 17:56:35 heizungspi kernel: [ 5.767391] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
| Oct 8 17:56:35 heizungspi dhcpcd[308]: DUID 00:01:00:01:22:69:57:00:b8:27:eb:94:fa:49
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: IAID eb:31:61:97
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: adding address fe80::fb78:1bda:3d6:e064
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: carrier lost
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::fb78:1bda:3d6:e064.
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: New relevant interface wlan0.IPv6 for mDNS.
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: Registering new address record for fe80::fb78:1bda:3d6:e064 on wlan0.*.
| Oct 8 17:56:35 heizungspi dhcpcd[308]: wlan0: deleting address fe80::fb78:1bda:3d6:e064
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: Withdrawing address record for fe80::fb78:1bda:3d6:e064 on wlan0.
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::fb78:1bda:3d6:e064.
| Oct 8 17:56:35 heizungspi avahi-daemon[316]: Interface wlan0.IPv6 no longer relevant for mDNS.
| Oct 8 17:56:35 heizungspi kernel: [ 6.168024] uart-pl011 3f201000.serial: no DMA platform data
| Oct 8 17:56:36 heizungspi dhcpcd[308]: eth0: carrier acquired
| Oct 8 17:56:36 heizungspi kernel: [ 6.794917] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
| Oct 8 17:56:36 heizungspi dhcpcd[308]: eth0: IAID eb:64:34:c2
| Oct 8 17:56:36 heizungspi dhcpcd[308]: eth0: adding address fe80::d5e0:d6ca:888:4c1a
| Oct 8 17:56:36 heizungspi avahi-daemon[316]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::d5e0:d6ca:888:4c1a.
| Oct 8 17:56:36 heizungspi avahi-daemon[316]: New relevant interface eth0.IPv6 for mDNS.
| Oct 8 17:56:36 heizungspi avahi-daemon[316]: Registering new address record for fe80::d5e0:d6ca:888:4c1a on eth0.*.
| Oct 8 17:56:36 heizungspi dhcpcd[308]: eth0: rebinding lease of 10.1.2.11
| Oct 8 17:56:36 heizungspi dhcpcd[308]: eth0: soliciting an IPv6 router
(Die LAN-Verbindung über eth0 habe ich provisorisch zu
Debug-Zwecken angeschlossen. Eine dauerhafte Anbindung
mittels LAN ist mit vertretbarem Aufwand nicht möglich.)
Nach ein wenig Herumstochern im Nebel habe ich gemerkt, dass
es möglicherweise mit wpa_supplicant zusammenhängt. Starte
ich wpa_supplicant direkt von der Konsole (nicht als
Service), erhalte ich folgendes:
| # wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf
| Successfully initialized wpa_supplicant
| wlan0: Trying to associate with SSID 'orbit'
| wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
| wlan0: Trying to associate with SSID 'orbit'
| wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
| wlan0: Trying to associate with SSID 'orbit'
| wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Und immer so weiter, bis ich wpa_supplicant mit Crtl+C
abwürge. Verwende ich allerdings den wext-Treiber, sieht die
Sache anders aus:
| # wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf
| Successfully initialized wpa_supplicant
| ioctl[SIOCSIWENCODEEXT]: Invalid argument
| ioctl[SIOCSIWENCODEEXT]: Invalid argument
| wlan0: Trying to associate with 68:d7:9a:5f:0b:57 (SSID='orbit' freq=2437 MHz)
| wlan0: Authentication with 68:d7:9a:5f:0b:57 timed out.
| wlan0: CTRL-EVENT-DISCONNECTED bssid=68:d7:9a:5f:0b:57 reason=3 locally_generated=1
| ioctl[SIOCSIWSCAN]: Resource temporarily unavailable
| wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
| ioctl[SIOCSIWSCAN]: Resource temporarily unavailable
| wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
| ioctl[SIOCSIWSCAN]: Resource temporarily unavailable
| wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
| wlan0: Trying to associate with f0:9f:c2:a7:cb:aa (SSID='orbit' freq=2412 MHz)
| wlan0: Associated with f0:9f:c2:a7:cb:aa
| wlan0: WPA: Key negotiation completed with f0:9f:c2:a7:cb:aa [PTK=CCMP GTK=CCMP]
| wlan0: CTRL-EVENT-CONNECTED - Connection to f0:9f:c2:a7:cb:aa completed [id=0 id_str=]
Auch hier will sich wpa_supplicant zuerst mit AP "B"
verbinden, merkt aber, dass das nicht geht, und wechselt zu
AP "A", wo er wie gewohnt eine Verbindung bekommt.
| # iwconfig wlan0
| wlan0 IEEE 802.11 ESSID:"orbit"
| Mode:Managed Frequency:2.412 GHz Access Point: F0:9F:C2:A7:CB:AA
| Bit Rate=65 Mb/s Tx-Power=31 dBm
| Retry short limit:7 RTS thr:off Fragment thr:off
| Encryption key:off
| Power Management:on
| Link Quality=48/70 Signal level=-62 dBm
| Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
| Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Daraufhin habe ich sowohl versucht, die Frequenz (und damit
indirekt den AP) in wpa_supplicant.conf festzunageln...
| ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
| update_config=1
| country=DE
|
| network={
| ssid="orbit"
| freq_list=2412
| psk="HierStehtNatürlichDasRichtigeWLANPAsswort"
| }
...als auch testweise in /lib/systemd/system/wpa_supplicant@.service
die Zeile...
| ExecStart=/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -Dnl80211,wext -i%I
...zu...
| ExecStart=/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf -Dwext -i%I
...abgeändert in der Hoffnung, dass wpa_supplicant
"dauerhaft" den wext-Treiber verwendet. Das alles aber
bislang ohne Effekt - wenn ich wpa_supplicant als Service
starte, tut das zwar ohne Fehlermeldung und der
Service-Status sagt "running", eine WLAN-Verbindung kommt
aber trotzdem nicht zustande.
Verwunderlich ist aber ohnehin, dass die Verbindung bei AP
"B" nicht klappen mag. Beide APs sind Ubiquity Unifis ("A"
ist ein "Lite" auf Kanal 1, "B" ist ein "nano HD" auf Kanal
6), beide werden von einem Controller gemanagt und beide
haben, abgesehen von der Kanalwahl im 2,4-GHz-Band, keine
individuellen Konfigurationen, sondern übernehmen alles von
der "Site".
Dieses ganze Problem wirft nun natürlich sozusagen zweigleisig Fragen auf:
1. Woran könnte es liegen, dass keine Verbindung mit AP "B"
zustande kommen will? Die o.g. Fehlermeldung
"CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00
status_code=16" habe ich natürlich schon in Google
eingeworfen, aber die Fundstücke bringen mich nicht wirklich
weiter. (U.a. deshalb, weil der fragliche Pi headless läuft
und gar nichts HDMI-mäßiges angeschlossen ist.)
2. Wie kann ich wpa_supplicant dazu bringen, sich
ausschließlich mit AP "A" zu verbinden?
TIA,
Sebastian
PS: XP dcounm & dchnw, f'up erstmal nach dcounm
--
X-Post, FollowUp-To de.comp.os.unix.networking.misc
Friedemann Stoyan
Oct 8, 2021, 11:45:25 PM10/8/21
to
Sebastian Suchanek wrote:
> 2. Wie kann ich wpa_supplicant dazu bringen, sich
> ausschließlich mit AP "A" zu verbinden?
Die BSSID explizit mitgeben:
> 2. Wie kann ich wpa_supplicant dazu bringen, sich
> ausschließlich mit AP "A" zu verbinden?
>| network={
>| ssid="orbit"
>| freq_list=2412
>| bssid=f0:9f:c2:a7:cb:aa
>| psk="HierStehtNatürlichDasRichtigeWLANPAsswort"
>| }
mfg Friedemann
Sebastian Suchanek
Oct 9, 2021, 12:14:26 PM10/9/21
to
Thus spoke Friedemann Stoyan:
Danke. Allerdings wird's jetzt noch wirrer: Wenn ich wie oben
beschrieben die bssid in der Konfiguration mit angebe, verbindet
sich wpa_supplicant erwartungsgemäß und einwandfrei mit AP "A" -
wenn ich wpa_supplicant von der Konsole aus starte. Starte ich
wpa_supplicant dagegen als Service, kommt nach wie vor *keine*
Verbindung zustande. (Auch in /var/log/syslog herrscht abgesehen
von den Start- und Stop-Meldungen des Service nach wie vor
Schweigen im Walde.)
Außerdem habe ich das Thema mit den möglichen HF-Störungen noch
'mal aufgegriffen und den AP "B" testweise von Kanal 6 auf Kanal
11 umgestellt. Damit verbindet sich der Raspi auch mit AP "B",
aber auch wieder nur beim Start von wpa_supplicant über die
Konsole, nicht beim Start als Service.
Kann sich irgendjemand erklären, warum in Abhängigkeit der
"Start-Art" von wpa_supplicant eine Verbindung (nicht) zustande
kommt?
Tschüs,
Sebastian
beschrieben die bssid in der Konfiguration mit angebe, verbindet
sich wpa_supplicant erwartungsgemäß und einwandfrei mit AP "A" -
wenn ich wpa_supplicant von der Konsole aus starte. Starte ich
wpa_supplicant dagegen als Service, kommt nach wie vor *keine*
Verbindung zustande. (Auch in /var/log/syslog herrscht abgesehen
von den Start- und Stop-Meldungen des Service nach wie vor
Schweigen im Walde.)
Außerdem habe ich das Thema mit den möglichen HF-Störungen noch
'mal aufgegriffen und den AP "B" testweise von Kanal 6 auf Kanal
11 umgestellt. Damit verbindet sich der Raspi auch mit AP "B",
aber auch wieder nur beim Start von wpa_supplicant über die
Konsole, nicht beim Start als Service.
Kann sich irgendjemand erklären, warum in Abhängigkeit der
"Start-Art" von wpa_supplicant eine Verbindung (nicht) zustande
kommt?
Tschüs,
Sebastian
Tim Ritberg
Oct 9, 2021, 1:05:15 PM10/9/21
to
Am 09.10.21 um 18:13 schrieb Sebastian Suchanek:
>
> Danke. Allerdings wird's jetzt noch wirrer: Wenn ich wie oben
> beschrieben die bssid in der Konfiguration mit angebe, verbindet
> sich wpa_supplicant erwartungsgemäß und einwandfrei mit AP "A" -
> wenn ich wpa_supplicant von der Konsole aus starte. Starte ich
> wpa_supplicant dagegen als Service, kommt nach wie vor *keine*
> Verbindung zustande.
Läuft als root?
Tim
--
Xubuntu 21.04 64 bit, Kernel 5.11 (native)
ASRock x470 Taichi, 32 GB RAM, Ryzen 7 3700X
Eine Firewall ist kein Konzept! RTFM: RFC 2979
>
> Danke. Allerdings wird's jetzt noch wirrer: Wenn ich wie oben
> beschrieben die bssid in der Konfiguration mit angebe, verbindet
> sich wpa_supplicant erwartungsgemäß und einwandfrei mit AP "A" -
> wenn ich wpa_supplicant von der Konsole aus starte. Starte ich
> wpa_supplicant dagegen als Service, kommt nach wie vor *keine*
> Verbindung zustande.
Tim
--
Xubuntu 21.04 64 bit, Kernel 5.11 (native)
ASRock x470 Taichi, 32 GB RAM, Ryzen 7 3700X
Eine Firewall ist kein Konzept! RTFM: RFC 2979
Friedemann Stoyan
Oct 9, 2021, 11:44:55 PM10/9/21
to
Sebastian Suchanek wrote:
> Kann sich irgendjemand erklären, warum in Abhängigkeit der
> "Start-Art" von wpa_supplicant eine Verbindung (nicht) zustande
> kommt?
Ich habe das Problem (den Effekt), dass (in meinem Fall) der iwd (manchmal,
> Kann sich irgendjemand erklären, warum in Abhängigkeit der
> "Start-Art" von wpa_supplicant eine Verbindung (nicht) zustande
> kommt?
nicht immer) zu früh startet. Also bevor der WLAN NIC vollständig initialisiert
wurde. Dann gibts auch kein WLAN. Ich habe bei mir deswegen folgende Override
Datei:
# /etc/systemd/system/iwd.service.d/override.conf
[Service]
ExecStartPre=-/usr/bin/sleep 2s
mfg Friedemann
Sebastian Suchanek
Oct 16, 2021, 4:46:59 PM10/16/21
to
Sebastian Suchanek macht die Ingrid:
> Vorweg: das folgende Problem ist etwas verworren und
> langwierig zu beschreiben - ich hoffe, ich bekomme es
> trotzdem nachvollziehbar erklärt.
> [...]
Fürs Protokoll: es funktioniert wieder.
In Kurzfassung: der Accesspoint war schuld.
In Langfassung: ich habe mir einen neuen Raspberry Pi
(allerdings einen 3B statt einen 3B+) bestellt - die Dinger kann
man ja bekanntlich eh immer 'mal brauchen ;-) - und mit einem
nagelneuen Raspberry Pi OS frisch eingerichtet. Den habe ich
dann nacheinander in unmittelbarer Nähe mehrer APs im Haus
platziert und so relativ schnell festgestellt, dass sich der
RasPi mit allen APs einwandfrei verbunden hat, auch auf Kanal 6
an einem anderen AP - nur eben nicht mit nanoHD, den ich im OP
als "B" bezeichnet hatte.
Daraufhin habe ich dem nanoHD dann kurzerhand einen Cold Reset
verpasst und seither scheint wieder alles einwandfrei zu
funktionieren. Der Test-Raspi verbindet sich problemlos auch mit
dem nanoHD und der "Produktiv"-Raspi wählt - warum auch immer -
nun wieder den AP "A", auch wenn er nun wahrscheinlich auch mit
AP "B" eine Verbindung aufbauen könnte.
Auch wenn ich jetzt weiß, wo das Problem lag, hoffe ich
trotzdem, dass das nur ein einmaliger "Schluckauf" des APs
war...
Tschüs,
Sebastian
PS: XP & f'up zurück nach de.comp.hardware.netzwerke.wireless,
weil es ja letztendlich doch ein Hardware-Problem war.
--
X-Post, FollowUp-To de.comp.hardware.netzwerke.wireless
> Vorweg: das folgende Problem ist etwas verworren und
> langwierig zu beschreiben - ich hoffe, ich bekomme es
> trotzdem nachvollziehbar erklärt.
Fürs Protokoll: es funktioniert wieder.
In Kurzfassung: der Accesspoint war schuld.
In Langfassung: ich habe mir einen neuen Raspberry Pi
(allerdings einen 3B statt einen 3B+) bestellt - die Dinger kann
man ja bekanntlich eh immer 'mal brauchen ;-) - und mit einem
nagelneuen Raspberry Pi OS frisch eingerichtet. Den habe ich
dann nacheinander in unmittelbarer Nähe mehrer APs im Haus
platziert und so relativ schnell festgestellt, dass sich der
RasPi mit allen APs einwandfrei verbunden hat, auch auf Kanal 6
an einem anderen AP - nur eben nicht mit nanoHD, den ich im OP
als "B" bezeichnet hatte.
Daraufhin habe ich dem nanoHD dann kurzerhand einen Cold Reset
verpasst und seither scheint wieder alles einwandfrei zu
funktionieren. Der Test-Raspi verbindet sich problemlos auch mit
dem nanoHD und der "Produktiv"-Raspi wählt - warum auch immer -
nun wieder den AP "A", auch wenn er nun wahrscheinlich auch mit
AP "B" eine Verbindung aufbauen könnte.
Auch wenn ich jetzt weiß, wo das Problem lag, hoffe ich
trotzdem, dass das nur ein einmaliger "Schluckauf" des APs
war...
Tschüs,
Sebastian
PS: XP & f'up zurück nach de.comp.hardware.netzwerke.wireless,
weil es ja letztendlich doch ein Hardware-Problem war.
--
X-Post, FollowUp-To de.comp.hardware.netzwerke.wireless
0 new messages