Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

WLAN as einfache NIC geht, mit bonding hingegen nicht

37 views
Skip to first unread message

Roland Sommer

unread,
Jan 16, 2021, 8:40:10 AM1/16/21
to
Hi,

ich versuche Bonding mit LAN und WLAN einzurichten, was mit Debian
Stretch ging und mit Buster aber fehl schlägt. Status:


networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled;
vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2021-01-16 13:51:32 CET;
31s ago
Docs: man:interfaces(5)
Process: 513 ExecStart=/sbin/ifup -a --read-environment (code=exited,
status=1/FAILURE)
Main PID: 513 (code=exited, status=1/FAILURE)

Jan 16 13:51:32 mc wpa_supplicant[569]: wlp0s12f0: Failed to open
l2_packet connection for the bridge interface 'bond0'
Jan 16 13:51:32 mc wpa_supplicant[569]: nl80211: deinit ifname=wlp0s12f0
disabled_11b_rates=0
Jan 16 13:51:32 mc ifup[513]: /etc/network/if-pre-up.d/wpasupplicant:
120: /etc/network/if-pre-up.d/wpasupplicant: cannot create /dev/stderr:
No such device or address
Jan 16 13:51:32 mc ifup[513]: run-parts:
/etc/network/if-pre-up.d/wpasupplicant exited with return code 1
Jan 16 13:51:32 mc ifup[513]: ifup: failed to bring up wlp0s12f0
Jan 16 13:51:32 mc ifup[513]: Cannot find device "bond0"
Jan 16 13:51:32 mc ifup[513]: ifup: failed to bring up bond0
Jan 16 13:51:32 mc systemd[1]: networking.service: Main process exited,
code=exited, status=1/FAILURE
Jan 16 13:51:32 mc systemd[1]: networking.service: Failed with result
'exit-code'.
Jan 16 13:51:32 mc systemd[1]: Failed to start Raise network interfaces.


Einen ähnlichen Fehler finde ich hier
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838291

Die beiden NICs jeweils als eigenständiges Interface funktionieren
hingegen fehlerfrei. Sieht für mich nach BUG aus, an welches Paket
sollte ich den Report schicken?

TIA
Roland

Tim Ritberg

unread,
Jan 16, 2021, 9:28:02 AM1/16/21
to
Am 16.01.21 um 14:40 schrieb Roland Sommer:

>
> Einen ähnlichen Fehler finde ich hier
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838291
>
> Die beiden NICs jeweils als eigenständiges Interface funktionieren
> hingegen fehlerfrei. Sieht für mich nach BUG aus, an welches Paket
> sollte ich den Report schicken?
>
> TIA
> Roland
>

Schon einen neuen Vanilla-Kernel getestet?

Tim

Marc Haber

unread,
Jan 17, 2021, 5:23:20 AM1/17/21
to
Roland Sommer <r.so...@gmx.de> wrote:
>ich versuche Bonding mit LAN und WLAN einzurichten, was mit Debian
>Stretch ging und mit Buster aber fehl schlägt.

Ging es mit Stretch wirklich oder konntest Du einen funktionslosen
Bond einrichten?

WLAN und Ethernet kommt zwar beides aus IEEE 802, aber schon die
Untergruppe ist anders: Ethernet ist 802.3; WLAN ist 802.11. Beide
setzen auf 802.1 auf, sind aber trotzdem hinreichend unterschiedlich,
dass ich nicht davon ausgehen würde, dass ein Bonding möglich und
funktional wäre.

Sinnvoll scheint es mir jedenfalls nicht, weil die meisten
Bonding-Algorithmen darauf basieren, dass die gebündelten Links
ähnliche Eigenschaften haben.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Tim Ritberg

unread,
Jan 17, 2021, 10:14:54 AM1/17/21
to
Am 17.01.21 um 16:03 schrieb Marcus Jodorf:
> Marc Haber <mh+usene...@zugschl.us> schrieb:
>
>> Sinnvoll scheint es mir jedenfalls nicht, weil die meisten
>> Bonding-Algorithmen darauf basieren, dass die gebündelten Links
>> ähnliche Eigenschaften haben.
>
> Typisches Szenario: „Laptop-Mode“.
> Was letztlich bonding mit auto-failover ist.
Das kenne ich aber eher mit Metrik.

Tim

Roland Sommer

unread,
Jan 17, 2021, 11:17:23 AM1/17/21
to
* Tim Ritberg wrote:

> Schon einen neuen Vanilla-Kernel getestet?

Nein, noch nie. Siehst du hier Erfolgschancen?

Roland Sommer

unread,
Jan 17, 2021, 11:17:27 AM1/17/21
to
* Marc Haber wrote:

> Ging es mit Stretch wirklich oder konntest Du einen funktionslosen
> Bond einrichten?

Ist schon ewig her, aber ich bin mir schon sehr sicher. Leider habe ich
das System nicht mehr.

> WLAN und Ethernet kommt zwar beides aus IEEE 802, aber schon die
> Untergruppe ist anders: Ethernet ist 802.3; WLAN ist 802.11. Beide
> setzen auf 802.1 auf, sind aber trotzdem hinreichend unterschiedlich,
> dass ich nicht davon ausgehen würde, dass ein Bonding möglich und
> funktional wäre.

Es war active-backup wobei active eth0 war. Die Idee ist standardmäßig
per WLAN verbunden zu sein und bei Bedarf ein LAN Kabel zu stecken. Gibt
es irgendwelche andere Methoden das zu erreichen (insbesondere unter
Beibehaltung der IP Adresse)?

Grüße
Roland

Marc Haber

unread,
Jan 17, 2021, 12:06:44 PM1/17/21
to
Marcus Jodorf <tr...@killfile.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> schrieb:
>> Sinnvoll scheint es mir jedenfalls nicht, weil die meisten
>> Bonding-Algorithmen darauf basieren, dass die gebündelten Links
>> ähnliche Eigenschaften haben.
>
>Typisches Szenario: „Laptop-Mode“.
>Was letztlich bonding mit auto-failover ist.
>
>Du machst da einfach bonding für wlan und eth und je nachdem, ob Kabel
>eingestöpselt oder nicht macht das dann passend failover und nimmst immer
>die schnellere Kabelverbindung wenn verfügbar.

Und, hat das jemals funktioniert? Bietet Network-Manager das aus der
Büchse an?

Marc Haber

unread,
Jan 17, 2021, 12:07:52 PM1/17/21
to
Roland Sommer <r.so...@gmx.de> wrote:
>Es war active-backup wobei active eth0 war. Die Idee ist standardmäßig
>per WLAN verbunden zu sein und bei Bedarf ein LAN Kabel zu stecken. Gibt
>es irgendwelche andere Methoden das zu erreichen (insbesondere unter
>Beibehaltung der IP Adresse)?

Ich habe im DHCP-Server eine Reservierung für die IP-Adresse für beide
MAC-Adressen. Aber das failt natürlich schmerzhaft wenn mal beides
gleichzeitig aktiv ist. Und ich habe oft genug am Ethernet irgend ein
Labornetz stecken während das WLAN mein Internet ist, ich also so
einen Failover keinesfalls haben will.

Tim Ritberg

unread,
Jan 17, 2021, 12:13:30 PM1/17/21
to
Am 17.01.21 um 17:17 schrieb Roland Sommer:
> * Tim Ritberg wrote:
>
>> Schon einen neuen Vanilla-Kernel getestet?
>
> Nein, noch nie. Siehst du hier Erfolgschancen?
Ja.

Tim

Florian Weimer

unread,
Jan 17, 2021, 12:25:46 PM1/17/21
to
* Marc Haber:

> Roland Sommer <r.so...@gmx.de> wrote:
>>ich versuche Bonding mit LAN und WLAN einzurichten, was mit Debian
>>Stretch ging und mit Buster aber fehl schlägt.
>
> Ging es mit Stretch wirklich oder konntest Du einen funktionslosen
> Bond einrichten?
>
> WLAN und Ethernet kommt zwar beides aus IEEE 802, aber schon die
> Untergruppe ist anders: Ethernet ist 802.3; WLAN ist 802.11. Beide
> setzen auf 802.1 auf, sind aber trotzdem hinreichend unterschiedlich,
> dass ich nicht davon ausgehen würde, dass ein Bonding möglich und
> funktional wäre.

Linux hat eine reine Software-basierte Implementierung, die auf Wunsch
nicht 802.3ad verwendet. Probleme gibt es vielleicht, wenn die
Ethernet-MAC-Adresse auf dem WLAN verwendet wird und umgekehrt.

Christoph Brinkhaus

unread,
Jan 17, 2021, 1:47:25 PM1/17/21
to
Marc Haber <mh+usene...@zugschl.us> schrieb:
> Roland Sommer <r.so...@gmx.de> wrote:

Hallo Marc, hallo Roland,

>>Es war active-backup wobei active eth0 war. Die Idee ist standardmäßig
>>per WLAN verbunden zu sein und bei Bedarf ein LAN Kabel zu stecken. Gibt
>>es irgendwelche andere Methoden das zu erreichen (insbesondere unter
>>Beibehaltung der IP Adresse)?

Unter FreeBSD gibt es das lagg interface, mit dem man das erreichen
kann. Bei der Konfiguration wird die MAC Adresse vom kabelgebudenen
Interface auf die vom WLAN geändert. Insgesamt erreicht man damit ein
Fail Over zwischen Kabel und WLAN.

Roland, schau mal auf https://en.wikipedia.org/wiki/Link_aggregation.
Bei Linux kann man das gleiche scheinbar mit "bonding" erreichen.
>
> Ich habe im DHCP-Server eine Reservierung für die IP-Adresse für beide
> MAC-Adressen. Aber das failt natürlich schmerzhaft wenn mal beides
> gleichzeitig aktiv ist.

> Und ich habe oft genug am Ethernet irgend ein
> Labornetz stecken während das WLAN mein Internet ist, ich also so
> einen Failover keinesfalls haben will.
>
Die Flexibilität hat man mit dem Lagg Interface dann nicht.
Dazu müsste man die Netzwerkschnittstellen und das Routing
umkonfigurieren.

> Grüße
> Marc

Viele Grüße,
Christoph

Marc Haber

unread,
Jan 17, 2021, 2:55:54 PM1/17/21
to
Christoph Brinkhaus <C.Bri...@t-online.de> wrote:
>Roland, schau mal auf https://en.wikipedia.org/wiki/Link_aggregation.
>Bei Linux kann man das gleiche scheinbar mit "bonding" erreichen.

Dass das bei Roland neuerdings nicht mehr zu funktionieren scheint war
der Beginn dieses Threads.

Marc Haber

unread,
Jan 17, 2021, 2:56:58 PM1/17/21
to
d.h. es würde reichen .3ad auszuschalten?

Florian Weimer

unread,
Jan 17, 2021, 4:53:44 PM1/17/21
to
* Marc Haber:

> Florian Weimer <f...@deneb.enyo.de> wrote:
>>* Marc Haber:
>>
>>> Roland Sommer <r.so...@gmx.de> wrote:
>>>>ich versuche Bonding mit LAN und WLAN einzurichten, was mit Debian
>>>>Stretch ging und mit Buster aber fehl schlägt.
>>>
>>> Ging es mit Stretch wirklich oder konntest Du einen funktionslosen
>>> Bond einrichten?
>>>
>>> WLAN und Ethernet kommt zwar beides aus IEEE 802, aber schon die
>>> Untergruppe ist anders: Ethernet ist 802.3; WLAN ist 802.11. Beide
>>> setzen auf 802.1 auf, sind aber trotzdem hinreichend unterschiedlich,
>>> dass ich nicht davon ausgehen würde, dass ein Bonding möglich und
>>> funktional wäre.
>>
>>Linux hat eine reine Software-basierte Implementierung, die auf Wunsch
>>nicht 802.3ad verwendet. Probleme gibt es vielleicht, wenn die
>>Ethernet-MAC-Adresse auf dem WLAN verwendet wird und umgekehrt.
>
> d.h. es würde reichen .3ad auszuschalten?

Würde ich vermuten. Dann braucht es kein LACP. Den Link-Zustand muß
man freilich auf andere Weise ermitteln. Soweit ich weiß,
berücksichtigt die Implementierung aber die Daten, die der Kernel hat.

Wenn der AP oder der Switch die MAC-Adressen beschränkt, wird das
vermutlich deswegen nicht funktionieren.

Sven Hartge

unread,
Jan 17, 2021, 5:06:44 PM1/17/21
to
Ich bin mir auch gerade nicht sicher, ob es auch sonst funktionieren
würden, denn die Anmeldung am AP und der 802.11-Frame muss ja die
Adresse des Wifi-Interfaces haben, der Bond prügelt aber seine eigene
Adresse auf die ausgehenden Daten.

Ich könnte mir gut vorstellen, das es da schon knallt und der AP die
Rahem verwirft, weil die Info darin nicht zum angemeldeten Client passt.

802.11 sieht ja nur so aus wie Ethernet, mit seinen 4 Adressierungsmodi
funktioniert es aber dann doch anders, wie 802.3.

S!

--
Sigmentation fault. Core dumped.

Christoph Brinkhaus

unread,
Jan 18, 2021, 10:01:08 AM1/18/21
to
Hallo Marc,

Marc Haber <mh+usene...@zugschl.us> schrieb:
> Christoph Brinkhaus <C.Bri...@t-online.de> wrote:
>>Roland, schau mal auf https://en.wikipedia.org/wiki/Link_aggregation.
>>Bei Linux kann man das gleiche scheinbar mit "bonding" erreichen.
>
> Dass das bei Roland neuerdings nicht mehr zu funktionieren scheint war
> der Beginn dieses Threads.

Meine Güte, es steht ja sogar im Subject. Damit bin ich wohl
das grauhaarige kleine Lasttier der Woche;-).

Wie heisst es so schön - sorry for the noise,
Christoph

Florian Weimer

unread,
Jan 18, 2021, 12:12:23 PM1/18/21
to
* Sven Hartge:

> Ich bin mir auch gerade nicht sicher, ob es auch sonst funktionieren
> würden, denn die Anmeldung am AP und der 802.11-Frame muss ja die
> Adresse des Wifi-Interfaces haben, der Bond prügelt aber seine eigene
> Adresse auf die ausgehenden Daten.
>
> Ich könnte mir gut vorstellen, das es da schon knallt und der AP die
> Rahem verwirft, weil die Info darin nicht zum angemeldeten Client passt.

Das sollte sich dadurch richten lassen, daß man auf dem
Ethernet-Interface die WLAN-MAC-Adresse verwendet. Aber es erfordert
ein bißchen basteln.

Tim Ritberg

unread,
Jan 18, 2021, 12:50:11 PM1/18/21
to
Am 18.01.21 um 18:12 schrieb Florian Weimer:

> Das sollte sich dadurch richten lassen, daß man auf dem
> Ethernet-Interface die WLAN-MAC-Adresse verwendet. Aber es erfordert
> ein bißchen basteln.
>

Nein, auf dem bond0.

Tim

Paul Muster

unread,
Jan 19, 2021, 12:02:03 AM1/19/21
to
On 18.01.21 23:25, Marcus Jodorf wrote:
> Marc Haber <mh+usene...@zugschl.us> schrieb:

>> Und, hat das jemals funktioniert? Bietet Network-Manager das aus der
>> Büchse an?
>
> siehe Debian Doku ;-)
>
> <https://wiki.debian.org/Bonding>

Wie alt ist das und mit welcher Debian-Version wurde das zuletzt
getestet? Seit wann gibt es bei Debian - außer in Sonderfällen - eth0
und wlan0 nicht mehr, sondern diese enoX/enpYsZ/wlpAsB-Interfacenamen?


mfG Paul

Paul Muster

unread,
Jan 19, 2021, 1:22:03 AM1/19/21
to
On 19.01.21 00:00, Marcus Jodorf wrote:

> Da das das typische Problem bei meinen Windowsnutzern ist, daß die gerne
> mit WLAN and Kabel versehentlich gleichzeitig im Netz hängen, knipse ich
> normal schon im UEFI der Laptops an, daß WLAN ausgeschaltet wird, sobald
> ein Kabel angesteckt wird. Sonst hätte ich jede Menge Nutzer, die immer
> zwei IPs ziehen.

Bei einem unverbastelten aktuellen Windows ist das genau gar kein
Problem, weil das Betriebssystem die zwei Wege ins selbe Netz über die
Metrik sauber priorisiert.
Ein Administator übrigens, dessen Netzkonzept nicht damit klarkommt,
wenn jeder Laptop zwei IPv4 zieht, nun, der sollte vielleicht mal das
Netz neu designen.

Mein Debian-Laptop macht das übrigens genauso:

> # ip addr sh

> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
> link/ether d4:be:e9:53:25:f5 brd ff:ff:ff:ff:ff:ff
> inet 192.168.3.21/24 brd 192.168.3.255 scope global dynamic noprefixroute eth0
> valid_lft 861734sec preferred_lft 861734sec

> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
> link/ether 24:77:03:b0:49:64 brd ff:ff:ff:ff:ff:ff
> inet 192.168.3.29/24 brd 192.168.3.255 scope global dynamic noprefixroute wlan0
> valid_lft 861740sec preferred_lft 861740sec

> # ip route sh
> default via 192.168.3.254 dev eth0 proto dhcp metric 100
> default via 192.168.3.254 dev wlan0 proto dhcp metric 600
> 192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.3.21 metric 100
> 192.168.3.0/24 dev wlan0 proto kernel scope link src 192.168.3.29 metric 600

[Pseudo-Zitat, damit Thunderbird die Zeilen nicht umbricht]


mfG Paul

Roland Sommer

unread,
Feb 24, 2021, 10:35:24 AM2/24/21
to
* Roland Sommer wrote:

> * Marc Haber wrote:
>
>> Ging es mit Stretch wirklich oder konntest Du einen funktionslosen
>> Bond einrichten?

Ich hab das alte System aus dem Backup wiederhergestellt und ja, meine
Erinnerung war richtig:

### eth0 gesteckt ###

ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast master bond0 state UP mode DEFAULT group default qlen 1000
link/ether 74:2f:68:2f:21:4a brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq
master bond0 state UP mode DORMANT group default qlen 1000
link/ether 74:2f:68:2f:21:4a brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP mode DEFAULT group default qlen 1000
link/ether 74:2f:68:2f:21:4a brd ff:ff:ff:ff:ff:ff

iperf3:
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 11.8 MBytes 99.1 Mbits/sec 0 105 KBytes
### eth0 gezogen ###

ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc
pfifo_fast master bond0 state DOWN mode DEFAULT group default qlen 1000
link/ether 74:2f:68:2f:21:4a brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq
master bond0 state UP mode DORMANT group default qlen 1000
link/ether 74:2f:68:2f:21:4a brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP mode DEFAULT group default qlen 1000
link/ether 74:2f:68:2f:21:4a brd ff:ff:ff:ff:ff:ff

iperf3:
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 2.92 MBytes 24.5 Mbits/sec 0 143 KBytes
/etc/network/interfaces:
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
address 192.168.1.3
netmask 255.255.255.0
gateway 192.168.1.1
bond-mode active-backup
bond-miimon 100
bond-primary eth0
bond-primary-reselect always
#wlan0 muss als erstes stehen, sonst funktioniert WPA nicht
bond-slaves wlan0 eth0
post-up ifconfig eth0 up

auto eth0
iface eth0 inet manual

auto wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Paralleler ping lief permanent durch.

Irgendwelche Ideen das mit Buster analog hinzubekommen?

Im syslog noch diese Hinweise bekommen:
Feb 24 16:01:20 mc wpa_supplicant[552]: Successfully initialized
wpa_supplicant
Feb 24 16:01:20 mc kernel: [ 7.419333] iwlwifi 0000:00:0c.0: Conflict
between TLV & NVM regarding enabling LAR (TLV = enabled NVM =disabled)
Feb 24 16:01:20 mc kernel: [ 7.425007] iwlwifi 0000:00:0c.0: BIOS
contains WGDS but no WRDS
Feb 24 16:01:20 mc kernel: [ 7.425689] IPv6: ADDRCONF(NETDEV_UP):
wlp0s12f0: link is not ready
Feb 24 16:01:20 mc wpa_supplicant[552]: nl80211: kernel reports:
Attribute failed policy validation
Feb 24 16:01:20 mc wpa_supplicant[552]: Failed to create interface
p2p-dev-wlp0s12f0: -22 (Invalid argument)
Feb 24 16:01:20 mc wpa_supplicant[552]: nl80211: Failed to create a P2P
Device interface p2p-dev-wlp0s12f0
Feb 24 16:01:20 mc wpa_supplicant[552]: P2P: Failed to enable P2P Device
interface

Leider hilft "options iwlwifi lar_disable=1" auch nicht.

TIA
Roland
0 new messages