2 Wlankarten - welche wird wann genutzt?

[pcace]

Hi,

ich hab da mal ne frage zur network/interfaces: an einem Rechner mit 2 Wlankarten möchte ich wlan0 zum meshen benutzen. wlan1 soll mit einem AP verbunden sein. Ich habe nun in der interfaces wlan1 angewiesen sich mit dem AP zu verbinden, das funktioniert. Sobald ich aber wlan0 in der interfaces erwähne, und es in ein vermaschtes netz hänge, bekommt wlan1 keine IP mehr vom AP... komisch. Was kann das sein? gibt es in der interfaces eine art reihenfolge? Oder sonst irgendeinen trick, wie man wlan1 und wlan0 komplett getrennt konfiguriert?

Gruß und Dank!

[unitra]

Hi,

deine Frage lässt sich so ohne Weiteres nicht beantworten. Dafür wäre eventuell erst einmal folgenden Ausgabe hilfreich um Deine Frage zu beantworten:

Code: Alles auswählen

ip link

Code: Alles auswählen

ip add

Code: Alles auswählen

ip route

Hi,

ich hab da mal ne frage zur network/interfaces: an einem Rechner mit 2 Wlankarten möchte ich wlan0 zum meshen benutzen. wlan1 soll mit einem AP verbunden sein. Ich habe nun in der interfaces wlan1 angewiesen sich mit dem AP zu verbinden, das funktioniert. Sobald ich aber wlan0 in der interfaces erwähne, und es in ein vermaschtes netz hänge, bekommt wlan1 keine IP mehr vom AP... komisch. Was kann das sein? gibt es in der interfaces eine art reihenfolge? Oder sonst irgendeinen trick, wie man wlan1 und wlan0 komplett getrennt konfiguriert?

Gruß und Dank!

[guennid]

Ich kann weder mit dem Verb „meshen“ noch mit dem Adjektiv „vermascht“ etwas anfangen.

Was sagt

Code: Alles auswählen

apt-get -s install iproute2

? Was sagt

Code: Alles auswählen

apt-get -s install net-tools

?

Standardmäßig solltest du weder ein wlan0 noch ein wlan1 zu sehen bekommen.

Grüße, Günther

[TomL]

Was kann das sein?

Das ist ein altes Problem, was dadurch passiert, dass es seitens des Kernels keine definitive Reihenfolge gibt, wie bzw. wann die NICs erkannt und den symbolischen Namen wlan0, wlan1 (...oder eth0, eth1 bei Kabelgebundenen) etc. zugeordnet werden. Das ist also leider immer auch ein wenig zufällig, mal passts, mal passts nicht.

gibt es in der interfaces eine art reihenfolge? Oder sonst irgendeinen trick, wie man wlan1 und wlan0 komplett getrennt konfiguriert?

Ja, gibt es. Genau dieses Problem löst systemd in absolut eindeutiger Weise mit Predictable Network Interface Names. Das wird seit Debian Jessie unterstützt. Du musst also nur schauen, warum das bei Dir ausgeschaltet ist. Die Wlan-NICs heissen dann allerdings nicht mehr wlan0 und wlan1 nach zufälliger Vergabe, sondern bekommen eine konstante Bezeichnung, auf die man sich dann auch verlassen kann. Die Bezeichnung eines NICs bleibt sogar dann gleich, auch wenn weitere Interfaces eingebaut oder bestehende ausgebaut werden würden. Und alle Einstellungen oder von Dir gemachte Vorgaben sind dann auch wirklich an das bezeichnete NIC gebunden und finden da Anwendung. Solche Verwechselungen wie bisher passieren dann nicht mehr.

[guennid]

Ich habe nun in der interfaces wlan1 angewiesen sich mit dem AP zu verbinden, das funktioniert.

Wenn das stimmt, nutzt es wenig, die Umbenennungen via udev (nicht systemd) ins Spiel zu bringen.

[mat6937]

Sobald ich aber wlan0 in der interfaces erwähne, und es in ein vermaschtes netz hänge, bekommt wlan1 keine IP mehr vom AP... komisch.

BTW: Mit einem aktuellen wpa_supplicant kann man auch die Option "-M" für das Interface benutzen (auch mit der interfaces-Datei):

Code: Alles auswählen

... -M -iwlan* ...

[TomL]

Wenn das stimmt, nutzt es wenig, die Umbenennungen via udev (nicht systemd) ins Spiel zu bringen.

udev ist imho systemd.... so wird udev auf einem Standard-Debian gestartet: ExecStart=/lib/systemd/systemd-udevd. Und ich gehe mal davon aus, dass seine Aussage nur zufällig stimmt... beim nächsten Boot kanns passen oder eben nicht.

@mat6937
Das setzt aber auch voraus, dass wlan0 nicht nach dem nächsten Boot auf einmal wlan1 heisst. BTW, welche wpa_supplicant-Version kennt den Parameter '-M'? In Buster ist der Parameter noch unbekannt.

[guennid]

Bevor wir weiter spekulieren, sollten wir warten, ob er bereit ist, ein paar Voraussetzungen zu klären. Stoff genug hat er mittlerweile, denke ich.

udev ist imho systemd

Auch wenn mittlerweile beides aus dem Hause Red Hat kommt: Es sind zwei unabhängige Pakete.

Grüße, Günther

[TomL]

Auch wenn mittlerweile beides aus dem Hause Red Hat kommt: Es sind zwei unabhängige Pakete.

systemd ist nicht ein Programm, systemd besteht aus sehr vielen Programmen. Bei mir haben udev und systemd allerdings sogar die gleiche Versionsnummer:

Code: Alles auswählen

# dpkg -l | grep 241-3
ii  systemd          241-3           amd64        system and service manager
ii  udev             241-3           amd64        /dev/ and hotplug management daemon

Code: Alles auswählen

# apt show systemd
Package: systemd
Version: 241-3
Priority: important
Section: admin
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>

# apt show udev
Package: udev
Version: 241-3
Priority: important
Section: admin
Source: systemd
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>

Ich bin halt nur nicht sicher, ob dieses systemd-udev überhaupt ohne systemd funktionieren kann. Wenn ich mir anschaue, was da alles beim Start passiert, empfinde ich das alles als *sehr* systemd. Aber Du hast Recht, erstens tut das wohl nix zur Sache und zweitens hast Du an diesem speziellen Punkt vermutlich mehr Wissen als ich.... ich kann da nur lesen und versuchen, das gelesene zu interpretieren. Außerdem mach ich mir da sowieso eher weniger Gedanken, weils so, wie es ist, einfach perfekt läuft.

Code: Alles auswählen

# systemctl cat udev

# /lib/systemd/system/systemd-udevd.service
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=udev Kernel Device Manager
Documentation=man:systemd-udevd.service(8) man:udev(7)
DefaultDependencies=no
After=systemd-sysusers.service systemd-hwdb-update.service
Before=sysinit.target
ConditionPathIsReadWrite=/sys

[Service]
Type=notify
OOMScoreAdjust=-1000
Sockets=systemd-udevd-control.socket systemd-udevd-kernel.socket
Restart=always
RestartSec=0
ExecStart=/lib/systemd/systemd-udevd
KillMode=mixed
WatchdogSec=3min
TasksMax=infinity
PrivateMounts=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
SystemCallArchitectures=native
LockPersonality=yes
IPAddressDeny=any

[unitra]

Keine Spekulationen notwendig, udev und systemd wurden im Jahre 2012 gemergt. Quelle https://lwn.net/Articles/490413/.
Was die Distribution daraus macht spielt keine Rolle, der gleiche source-tree, egal ob 2 unabhängige Pakete oder eines

Bevor wir weiter spekulieren, sollten wir warten, ob er bereit ist, ein paar Voraussetzungen zu klären. Stoff genug hat er mittlerweile, denke ich.

udev ist imho systemd

Auch wenn mittlerweile beides aus dem Hause Red Hat kommt: Es sind zwei unabhängige Pakete.

Grüße, Günther

[guennid]

In diese Richtung zielte meine Warnung vorm Spekulieren eigentlich nicht.

[mat6937]

Das setzt aber auch voraus, dass wlan0 nicht nach dem nächsten Boot auf einmal wlan1 heisst.

Doch, das ist möglich bzw. dafür gibt es ja die Option "-M".

BTW, welche wpa_supplicant-Version kennt den Parameter '-M'? In Buster ist der Parameter noch unbekannt.

Unbekannt oder nicht dokumentiert?
Mit den Versionen 2.7 und 2.8 kann man "-M" benutzen:

Quellen:
https://w1.fi/cgit/hostap/diff/wpa_supp ... 539f9f8eb2

http://lists.infradead.org/pipermail/ho ... 39689.html

[pcace]

Also,

ich habe mich mal hier durchgelsen. Ersmal die Antwort hier drauf:

Hi,

deine Frage lässt sich so ohne Weiteres nicht beantworten. Dafür wäre eventuell erst einmal folgenden Ausgabe hilfreich um Deine Frage zu beantworten:

Code: Alles auswählen

ip link

Code: Alles auswählen

ip add

Code: Alles auswählen

ip route

Code: Alles auswählen

pi@mesh_pi_2:~ $ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:41:f8:cd brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DORMANT group default qlen 1000
    link/ether 00:c0:ca:72:19:8d brd ff:ff:ff:ff:ff:ff
4: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 74:da:38:3e:c6:0a brd ff:ff:ff:ff:ff:ff
pi@mesh_pi_2:~ $ ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:41:f8:cd brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:c0:ca:72:19:8d brd ff:ff:ff:ff:ff:ff
4: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 74:da:38:3e:c6:0a brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.226/24 brd 192.168.2.255 scope global wlan1
       valid_lft forever preferred_lft forever
    inet6 fd99:c3c1:4a7e::1c6/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fd99:c3c1:4a7e:0:7073:cbf0:de8c:b922/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::4c8:c13c:b356:8f3c/64 scope link 
       valid_lft forever preferred_lft forever
pi@mesh_pi_2:~ $ ip route
default via 192.168.2.1 dev wlan1 src 192.168.2.226 metric 304 
192.168.2.0/24 dev wlan1 proto kernel scope link src 192.168.2.226 metric 304 

root@mesh_pi_2:/home/pi# apt-get -s install iproute2
Reading package lists... 0%
Reading package lists... Done
Building dependency tree       
Reading state information... Done
iproute2 is already the newest version (4.9.0-1+deb9u1).
root@mesh_pi_2:/home/pi# apt-get -s install net-tools
Reading package lists... Done
Building dependency tree       
Reading state information... Done
net-tools is already the newest version (1.60+git20161116.90da8a0-1).

Dann habe ich in meiner dhcpcd.conf ganz oben "denyinterfaces wlan0" probiert - auch kein Erfolg.

davor habe ich noch ein file angelegt: /etc/udev/rules.d/72-wlan-geo-dependent.rules
darin steht:

Code: Alles auswählen

ACTION=="add", SUBSYSTEM=="net", DRIVERS=="brcmfmac", NAME="wlan1"

Das klappt auf meinen Raspberries wunderbar, auf dem Debian Rechner habe ich zur zeit das Problem nicht - Wlan0 und 1 sind immer gleich, egal wie oft ich neustarte.

iwconfig sieht so aus, wenn ich wlan0 nicht angefasst habe:

Code: Alles auswählen

 iwconfig 
wlan0     IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=18 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          
lo        no wireless extensions.

wlan1     IEEE 802.11  ESSID:"LAND_4_2.4"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: 50:C7:BF:09:B2:C4   
          Bit Rate=19.5 Mb/s   Tx-Power=31 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=45/70  Signal level=-65 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:7  Invalid misc:0   Missed beacon:0

eth0      no wireless extensions.

pi@mesh_pi_3:~ $ 

hier sah die network/interfaces so aus:

Code: Alles auswählen

allow-hotplug wlan1
iface wlan1 inet manual
wpa-ssid "LAND_4_2.4"
wpa-psk "xyz"

also irgendwie genau so wie ich es erwarten würde...


Boote ich den rechner allerdings mit folgendem Inhalt in der network interfaces:

Code: Alles auswählen

allow-hotplug wlan1
iface wlan1 inet manual
wpa-ssid "LAND_4_2.4"
wpa-psk "xyz"

 allow-hotplug wlan0
iface wlan0 inet static
address 10.2.0.3
network 10.2.0.0
netmask 255.255.255.0
wireless-essid olsrd
wireless-mode ad-hoc
wireless-channel 5

habe ich wieder folgendes Problem:
die Kiste hat wieder vergessen, dass sie vorher ja über wlan1 verbunden war. Verbindung ist weg, dafür will er jetzt scheinbar etwas mit wlan0 anfangen... (zusätzlich verwindet auch eth0, auch wenn vorher wunderbar per DHCP adressen bezogen werden konnten...)

Ausgabe ip_add:

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:eb:73:d2:52 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:e0:4c:2c:cd:8b brd ff:ff:ff:ff:ff:ff
    inet 10.2.0.3/24 brd 10.2.0.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:4cff:fe2c:cd8b/64 scope link 
       valid_lft forever preferred_lft forever
4: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:26:87:07 brd ff:ff:ff:ff:ff:ff
    inet6 fd99:c3c1:4a7e:0:ba27:ebff:fe26:8707/64 scope global mngtmpaddr dynamic 
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe26:8707/64 scope link 
       valid_lft forever preferred_lft forever

ip route:

Code: Alles auswählen

10.2.0.0/24 dev wlan0 proto kernel scope link src 10.2.0.3 

ip link

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:73:d2:52 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:e0:4c:2c:cd:8b brd ff:ff:ff:ff:ff:ff
4: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
    link/ether b8:27:eb:26:87:07 brd ff:ff:ff:ff:ff:ff

ifconfig:

Code: Alles auswählen

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Lokale Schleife)
        RX packets 2  bytes 78 (78.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 78 (78.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.2.0.3  netmask 255.255.255.0  broadcast 10.2.0.255
        inet6 fe80::2e0:4cff:fe5d:79e  prefixlen 64  scopeid 0x20<link>
        ether 00:e0:4c:5d:07:9e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 28 overruns 0  carrier 0  collisions 0

wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::ba27:ebff:fe26:8707  prefixlen 64  scopeid 0x20<link>
        inet6 fd99:c3c1:4a7e:0:ba27:ebff:fe26:8707  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:26:87:07  txqueuelen 1000  (Ethernet)
        RX packets 73  bytes 11212 (10.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 55  bytes 7858 (7.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

iwconfig

Code: Alles auswählen

wlan0     IEEE 802.11  ESSID:"olsrd"  
          Mode:Ad-Hoc  Frequency:2.432 GHz  Cell: Not-Associated   
          Tx-Power=18 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          
wlan1     IEEE 802.11  ESSID:"LAND_4_2.4"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: 50:C7:BF:09:B2:C4   
          Bit Rate=52 Mb/s   Tx-Power=31 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=43/70  Signal level=-67 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

ganzschön viele zitate... sorry.
Aber vllt weis jemand woran das liegen kann?!

Gruß und vielen vielen Dank!!!

[TomL]

Das setzt aber auch voraus, dass wlan0 nicht nach dem nächsten Boot auf einmal wlan1 heisst.

Doch, das ist möglich bzw. dafür gibt es ja die Option "-M".

Wenn ich den Text aus Deinem Link richtig verstanden habe, ist das ein Textmatching... aber vielleicht verstehe ich die Wirkung von -M auch nicht im wahren Sinne. Deswegen frag ich mal: wenn es zwei WLAN-Interfaces gibt, bei denen von Start zu Start des Rechners nicht klar ist, welches von den beiden wlan0 wird und welches wlan1, worauf will man denn da matchen? Bleibt das nicht trotzdem zufällig? Wie funktioniert das.... ?... welche Angabe muss man übergeben, um beispielsweise sicherzustellen, das das NIC mit der MAC so:wi:so:47:11:08:15 eine bestimmte IP bekommt und eine bestimmte Verbindung herstellen soll, wenn das NIC einmal wlan0 und einmal wlan1 heisst?

Eigentlich ist doch genau dieses Problem mit Predictable NIC-Names gelöst.

[guennid]

Bei diesem Szenario würde ich die udev-Umbenennungen nutzen. Und wenn's denn unbedingt eigene Namens-Kreationen via eigener udev-Regel sein sollen, würde ich jedenfalls nicht wlan0 und wlan1 nehmen.

Grüße, Günther

[mat6937]

...welche Angabe muss man übergeben, um beispielsweise sicherzustellen, das das NIC mit der MAC so:wi:so:47:11:08:15 eine bestimmte IP bekommt und eine bestimmte Verbindung herstellen soll, wenn das NIC einmal wlan0 und einmal wlan1 heisst?

Z. B. mit systemd-networkd und einer *.network-Datei:

Code: Alles auswählen

/etc/systemd/network/99_wlan_dhcp.network

mit dem Inhalt:

Code: Alles auswählen

[Match]
MACAddress=<so:wi:so:47:11:08:15>
Name=wlan*

[Network]
DHCP=yes

[TomL]

Nee, das meinte ich nicht.... das das so geht, weiß ich. Die Frage war:

...welche Angabe muss man übergeben, um beispielsweise sicherzustellen,

Das heißt, was wird unter solchen Voraussetzungen hinter -M als Parameter übergeben?

[mat6937]

Das heißt, was wird unter solchen Voraussetzungen hinter -M als Parameter übergeben?

Das wlan-Interface. Z. B.:

Code: Alles auswählen

/sbin/wpa_supplicant -B -qq -M -iwlan* -Dnl80211 -c/etc/wpa_supplicant/wpa_supplicant.conf

[TomL]

Das wlan-Interface. Z. B.:

Code: Alles auswählen

/sbin/wpa_supplicant -B -qq -M -iwlan* -Dnl80211 -c/etc/wpa_supplicant/wpa_supplicant.conf

Irgendwie reden wir aneinander vorbei.... welches WLAN-Interface wird mit dem Parameter -M -iwlan* genommen, wenn es wlan0 und wlan1 gibt?

[pcace]

...irgendwie verstehe ich die diskussion auch nicht so recht... Das Problem hier ist doch nicht, dass die interface namen tauschen, das problem ist, dass ich sobald ich wlan0 aktiviere nichts anderes mehr geht. nicht einmal eth0!

Gruß

[mat6937]

.... welches WLAN-Interface wird mit dem Parameter -M -iwlan* genommen, wenn es wlan0 und wlan1 gibt?

Es werden beide Interfaces genommen bzw. mit beiden wird versucht eine WLAN-Verbindung herzustellen. Aber nur eine WLAN-Verbindung wird zustande kommen.

[TomL]

Es werden beide Interfaces genommen bzw. mit beiden wird versucht eine WLAN-Verbindung herzustellen. Aber nur eine WLAN-Verbindung wird zustande kommen.

Genau so ist ist... und an dem Punkt komme ich -wie schon am Anfang beschrieben- zu dem Schluss, dass eben genau das nicht funktionieren kann.... deshalb nicht, weil man nicht vorhersagen kann, welches NIC mit welcher MAC/IP der zwei WLANs als Client oder als AP fungiert... weil nicht vorhersagbar ist, welches der zwei NICs beim Booten wlan0 und welches wlan1 wird. Wie will man denn da eine weitergehende Prozesslogik entwickeln, wenn man gar nicht weiss, welches der zwei NICs jetzt als Client eine Internetverbindung hergestellt hat, ohne dass man das riesig-aufwendig via Code bei jedem Joblauf ermitteln müsste.... weils ja jetzt anders sein könnte als zuvor, weil vielleicht der Rechner gerade rebootet wurde?

[TomL]

...irgendwie verstehe ich die diskussion auch nicht so recht... Das Problem hier ist doch nicht, dass die interface namen tauschen, das problem ist, dass ich sobald ich wlan0 aktiviere nichts anderes mehr geht. nicht einmal eth0!

Das hängt alles zusammen... läuft zusätzlich auch noch der Networkmanager, kanns schlichtweg sein, dass der die eine Verbindung schließt, wenn eine neue Verbindung geöffnet wird. Und hinsichtlich AP-WLAN und Client-Wlan plus eth0 gibts anscheinend sogar gleichzeitig 3 aktive NICs mit ggf. aktiven Netzverbindungen. Da sollte man schon mit allen Mitteln Eindeutigkeit schaffen und konkurrierende Prozesse ausschließen oder so einstellen, dass sie sich eben nicht gegenseitig beharken oder gegenseitig ausschließen.

Und das Problem mit den Namen ist sehr wohl ein Problem, weil Du bezogen auf den Devicenamen (wlan0 oder wlan1) nicht vorhersagen kannst, welches NIC/MAC/IP Client ist und welches Accesspoint. Und auf welches NIC will man z.B. Hostapd konfigurieren, wenn man nicht weiss, weches NIC wpa_supplicant wegen des Parameters -M verwendet hat? Auch das geht nur wieder mit absolut unnötigen Zusatz-Programmieraufwand.

[tijuca]

Ohne selbst etwas Hand anzulegen und eine eigene Udev Regel zuschreiben wird sich dieses Problem so nicht lösen lassen, auch die predictable Interfacenamen helfen nur bedingt. Aber das Problem ist ja nicht neu und auch schon mehrfach mit verschieden Wegen gelöst worden. Z.B.

https://fryboyter.de/wlan-stick-und-pre ... ace-names/

[mat6937]

Und das Problem mit den Namen ist sehr wohl ein Problem, weil Du bezogen auf den Devicenamen (wlan0 oder wlan1) nicht vorhersagen kannst, welches NIC/MAC/IP Client ist und welches Accesspoint. Und auf welches NIC will man z.B. Hostapd konfigurieren, wenn man nicht weiss, weches NIC wpa_supplicant wegen des Parameters -M verwendet hat? Auch das geht nur wieder mit absolut unnötigen Zusatz-Programmieraufwand.

Der TE will ja zusätzlich kein Hostapd konfigurieren, sondern ein Meshnetzwerk. Wenn er dafür einen festen/eindeutigen Namen für eines der wifi-Interfaces (ad-hoc Modus) braucht, muss er die Option "-M" mit dem wpa_supplicant nicht nutzen.

Für den Fall, dass der TE _keinen_ festen/eindeutigen Namen beim wifi-Interface für das Meshnetzwerk braucht, ist ja nur ein wifi-Interface für den managed mode konfiguriert und das andere für den ad-hoc Modus. Der wpa_supplicant wird (lt. default Konfiguration) auch mit der Option "-M", nur das Interface das für den managed mode konfiguriert ist, zum herstellen der WLAN-Verbindung zum AP benutzen können. Das andere wifi-Interface wird ignoriert. Den aktuellen Namens vom wifi-Interface kann man nach dem Aufbau der WLAN-Verbindung, aus dem Verzeichnis "/run/wpa_supplicant" entnehmen. Z. B.:

Code: Alles auswählen

:~$ ls -la /run/wpa_supplicant | grep -i wlan
srwxrwx---  1 root netdev    0 Mai 15 08:44 wlan1

Aber auch wenn man zwei wifi-Interfaces hätte, die beide für den managed mode geeignet wären bzw. gleichzeitig zur Verfügung stehen würden, könnte man die MAC-Adresse des wifi-Interfaces das nicht verwendet werden soll, in den MAC-Filter des AP eintragen. So kommt dann immer nur die WLAN-Verbindung zum AP via das eine wifi-Interface zustande und das unabhängig vom Namen.

EDIT:

Die Entwickler von wpa_supplicant/hostapd sind noch nicht so weit, dass man in der wpa_supplicant.conf-Datei (oder gleichwertig) ein NIC (auch im "Mode:Managed") anhand seiner MAC-Adresse _blacklisten_ kann, so dass dieses NIC bei Benutzung der Option "-M", vom wpa_supplicant _ignoriert_ bzw. nicht berücksichtigt wird. Aber ich denke, früher oder später wird es diese Möglichkeit der Konfiguration geben.