IP behalten bei Wechsel LAN/WLAN

[Andreas Barth]

Hallo zusammen,

ich würde gerne die IP-Adresse behalten beim Wechsel zwischen den
beiden Netztechnologien - das das die Voraussetzung hat, das auf
Netzseite das ein Netz ist ist klar.

Meine Frage ist aber wie das geschickterweise auf Linux (Debian)
konfiguriert wird. Bei Statusänderung des Ethernets sollte
geschickterweise eine dhcp-Abfrage gemacht werden um rauszukriegen ob
die ip noch gültig ist (bei Wegfall) bzw die IP übertragen werden kann
oder WLAN anbleiben muss (bei hinzukommen).

Soweit richtig, oder mache ich mir das zu kompliziert? Im Netz habe
ich nix hilfreiches gefunden, war aber vielleicht mit den falschen
Suchbegriffen unterwegs.


Viele Grüße,
Andi

[kay]

Post by Andreas Barth
Hallo zusammen,
ich würde gerne die IP-Adresse behalten beim Wechsel zwischen den
beiden Netztechnologien

Warum? Was hängt so wichtiges an der IP das diesen Aufwand erfordert?

Post by Andreas Barth
- das das die Voraussetzung hat, das auf
Netzseite das ein Netz ist ist klar.

??? Du meinst du weißt das du im gleichen Netzwerk-Segment
(IP-Adress-technisch) bleiben hmmm Solltest!?

Post by Andreas Barth
Meine Frage ist aber wie das geschickterweise auf Linux (Debian)
konfiguriert wird. Bei Statusänderung des Ethernets sollte
geschickterweise eine dhcp-Abfrage gemacht werden um rauszukriegen ob
die ip noch gültig ist (bei Wegfall) bzw die IP übertragen werden kann
oder WLAN anbleiben muss (bei hinzukommen).

Erster Knackpunkt: Die IP vergibt der DHCP üblicherweise nicht an das
Gerät, sondern an dessen MAC-Adresse. Anderes Interface = Andere MAC.
Andere MAC = Andere IP.

Nun kannst du natürlich fester IP vergeben und beide MAC-Adressen auf
eine IP abbilden lassen, hast dann aber immer noch zwei Leases im DHCP
server. Bei jedem Wechsel also: Ein altes, und ein neues.

Post by Andreas Barth
Soweit richtig, oder mache ich mir das zu kompliziert? Im Netz habe
ich nix hilfreiches gefunden, war aber vielleicht mit den falschen
Suchbegriffen unterwegs.

Wohl weil es meistens keinen rechten Sinn ergibt. Einen Server mit
Fester IP über WLAN oder LAN wechselnd zu betreiben ist grober Unfug.
Und einem Client kann es völlig Wurst sein ob er nun IP 1 oder IP 2 hat
- solange er nur eine Gültige hat.

Wenn es um Zugriffsbeschränkungen anhand der IP geht, die kann man auch
mit 2 IPs machen - oder besser über beide MAC-Adressen, oder beides
zusammen (wenn die karte stirbt(getauscht wird und man das vergaß zu ändern)

Wenn es um die schnöde namens-abbildung im internen netz geht, auch da
kann man einfach einen zweiten namen nehmen oder einem namen zwei IPs
zuordnen.

Kurz: Ich halte dein Vorhaben für Sinnlose Zeitverschwendung. Außer du
kannst einen Anwendungsfall nennen wo es nur so und nicht anders ginge.

Da das Thema Networking ist leite ich mal in die entsprechende Gruppe
um. Mit F'up2.

Kay

[Sven Hartge]

Post by Andreas Barth
ich würde gerne die IP-Adresse behalten beim Wechsel zwischen den
beiden Netztechnologien - das das die Voraussetzung hat, das auf
Netzseite das ein Netz ist ist klar.
Meine Frage ist aber wie das geschickterweise auf Linux (Debian)
konfiguriert wird. Bei Statusänderung des Ethernets sollte
geschickterweise eine dhcp-Abfrage gemacht werden um rauszukriegen ob
die ip noch gültig ist (bei Wegfall) bzw die IP übertragen werden kann
oder WLAN anbleiben muss (bei hinzukommen).

In meinem privaten LAN/WLAN gebe ich via DHCP einfach für beide
MAC-Adressen die gleiche IP heraus. Funktioniert. Solange die Metric der
Verbindungen auf dem Laptop unterschiedlich ist, sogar wenn beide
gleichzeitig aktiv sind.

S°

[Andreas Barth]

Post by Sven Hartge

Post by Andreas Barth
ich würde gerne die IP-Adresse behalten beim Wechsel zwischen den
beiden Netztechnologien - das das die Voraussetzung hat, das auf
Netzseite das ein Netz ist ist klar.
Meine Frage ist aber wie das geschickterweise auf Linux (Debian)
konfiguriert wird. Bei Statusänderung des Ethernets sollte
geschickterweise eine dhcp-Abfrage gemacht werden um rauszukriegen ob
die ip noch gültig ist (bei Wegfall) bzw die IP übertragen werden kann
oder WLAN anbleiben muss (bei hinzukommen).

In meinem privaten LAN/WLAN gebe ich via DHCP einfach für beide
MAC-Adressen die gleiche IP heraus. Funktioniert. Solange die Metric der
Verbindungen auf dem Laptop unterschiedlich ist, sogar wenn beide
gleichzeitig aktiv sind.

Hm, ja. Den dhcp-Server entsprechend bearbeiten ist auch eine
Möglichkeit. Zwar in der Theorie häßlich aber in Praxis wahrscheinlich
die einfachste.


Viele Grüße,
Andi

[Friedemann Stoyan]

Post by Andreas Barth
Hallo zusammen,
ich würde gerne die IP-Adresse behalten beim Wechsel zwischen den
beiden Netztechnologien - das das die Voraussetzung hat, das auf
Netzseite das ein Netz ist ist klar.

…

Post by Andreas Barth
Soweit richtig, oder mache ich mir das zu kompliziert? Im Netz habe
ich nix hilfreiches gefunden, war aber vielleicht mit den falschen
Suchbegriffen unterwegs.

Du suchst Mobile IP: https://en.wikipedia.org/wiki/Mobile_IP

mfg Friedemann

[Andreas Barth]

Post by Friedemann Stoyan
Du suchst Mobile IP: https://en.wikipedia.org/wiki/Mobile_IP

Nur teilweise, es ist schon ok wenn ich woanders bin dass dann die IP
anders ist. Trotzdem danke, aber da steht auch viel "TBD" in den
Seiten die ich damit gefunden habe.


Viele Grüße,
Andi

[Richard Lechner]

Post by Andreas Barth
Hallo zusammen,
ich würde gerne die IP-Adresse behalten beim Wechsel zwischen den beiden
Netztechnologien - das das die Voraussetzung hat, das auf Netzseite das
ein Netz ist ist klar.
Meine Frage ist aber wie das geschickterweise auf Linux (Debian)
konfiguriert wird. Bei Statusänderung des Ethernets sollte
geschickterweise eine dhcp-Abfrage gemacht werden um rauszukriegen ob
die ip noch gültig ist (bei Wegfall) bzw die IP übertragen werden kann
oder WLAN anbleiben muss (bei hinzukommen).

bonding?

[Juergen P. Meier]

Post by Andreas Barth
ich würde gerne die IP-Adresse behalten beim Wechsel zwischen den
beiden Netztechnologien - das das die Voraussetzung hat, das auf
Netzseite das ein Netz ist ist klar.

Der Wifi-AP muss Bridgen und im selben Segment sein wie der LAN-Port.

Post by Andreas Barth
Meine Frage ist aber wie das geschickterweise auf Linux (Debian)
konfiguriert wird. Bei Statusänderung des Ethernets sollte

NA, du musst der LAN-Schnittstelle die selbe IP geben wie dem
WLAN-Adapter. Je nach Distribution und netzwerkmanagement-Tool
reicht es die schnittstellen alternativ ab/anzuschalten.

Post by Andreas Barth
die ip noch gültig ist (bei Wegfall) bzw die IP übertragen werden kann

Der Lease haengt bei DHCP idR. an deiner MAC-Adresse. D.h. der LEase
ist natuerlich noch anderweitig vergeben.

Post by Andreas Barth
oder WLAN anbleiben muss (bei hinzukommen).
Soweit richtig, oder mache ich mir das zu kompliziert? Im Netz habe
ich nix hilfreiches gefunden, war aber vielleicht mit den falschen
Suchbegriffen unterwegs.

Mit DHCP wirst du das so nicht hinbekommen.

PS: Wenn du die SChnittstelle wechselst werden auch alle offenen
TCP-sockets geschlossen, eal ob du die IP-Adresse mitnimmst oder
aenderst.

D.h. deine Anwendungen merken das sowieso.

Die eigentliche Loesung fuer dein Problem heisst TCP Multipath (MPTCP)
und ist noch am Anfang des Standardisierungsprozesses.
Linux kann das noch nicht von sich aus, http://multipath-tcp.org/
hilft weiter.

[Andreas Barth]

Post by Juergen P. Meier
PS: Wenn du die SChnittstelle wechselst werden auch alle offenen
TCP-sockets geschlossen, eal ob du die IP-Adresse mitnimmst oder
aenderst.

Bin ich ja froh das das meine Programme nicht wissen.

Und mit bond/team ändert sich nichtmal das benutzte Interface, nur die
Automatisierung gefällt mir noch nicht. Werde aber ggf einfach die
Lösung von Sven benutzen.


Viele Grüße,
Andi

[Marcus Jodorf]

Werde aber ggf einfach die Lösung von Sven benutzen.

Ja das funktioniert. Mach ich seit >10 Jahren so. dnsmasq auf meinem
wlan router motzt da z.B. zwar beim Start einmal über „duplicate IP
address“ in der config aber praktisch tut das seit ewig einfach wie es
soll.


Gruß,

Marcus
⚂⚃

[Sven Hartge]

Post by Marcus Jodorf

Werde aber ggf einfach die Lösung von Sven benutzen.

Ja das funktioniert. Mach ich seit >10 Jahren so. dnsmasq auf meinem
wlan router motzt da z.B. zwar beim Start einmal über „duplicate IP
address“ in der config aber praktisch tut das seit ewig einfach wie es
soll.

dhcpd von ISC hat keine Probleme damit, lediglich der Name beim
host-Statement muss eindeutig sein:

host laptop-lan {
hardware ethernet 00:24:de:ad:be:ef;
fixed-address 192.168.100.17;
}

host laptop-wlan {
hardware ethernet 00:21:af:fe:ca:fe;
fixed-address 192.168.100.17;
}

S°

[Juergen P. Meier]

Post by Sven Hartge
dhcpd von ISC hat keine Probleme damit, lediglich der Name beim
host laptop-lan {
hardware ethernet 00:24:de:ad:be:ef;
fixed-address 192.168.100.17;
}
host laptop-wlan {
hardware ethernet 00:21:af:fe:ca:fe;
fixed-address 192.168.100.17;
}

Hast du beide Leases gleichzeitig aktiv? Das duerfte ISC dhcpd
verhindern.

[Karl Davis]

Post by Juergen P. Meier

Post by Sven Hartge
dhcpd von ISC hat keine Probleme damit, lediglich der Name beim
host laptop-lan {
hardware ethernet 00:24:de:ad:be:ef;
fixed-address 192.168.100.17;
}
host laptop-wlan {
hardware ethernet 00:21:af:fe:ca:fe;
fixed-address 192.168.100.17;
}

Hast du beide Leases gleichzeitig aktiv?

Das sieht bei mir leicht anders aus, funktionierte aber jahrelang
(mittlerweile habe ich keinen isc-dhcpd mehr am Laufen):
host eee1 {
option host-name "eee";
hardware ethernet 00:22:a4:2a:2f:2d;
fixed-address 192.168.1.16; }
host eee2 {
option host-name "eee";
hardware ethernet 00:c2:26:55:3d:dc;
fixed-address 192.168.1.16; }

Ob die _immer_ gleichzeitig aktiv waren, kann ich nicht mehr berichten,
weil meine Laptops seit Ewigkeiten automatisch von WLAN auf LAN
umschalten, sobald sie in der Docking-Station stecken. Aber ich meine
mich zu erinnern, daß das damals, als ich noch keine Docking-Station
hatte, auch nicht anders war.

Post by Juergen P. Meier
Das duerfte ISC dhcpd verhindern.

Wie kommt man eigentlich auf sowas? Das funktionierte hier schon vor
über 10 Jahren (so ca. zu Debian 3.0 Zeiten) genau so und vollkommen
problemlos.
Ich kann ja verstehen, daß das der breiten Masse nicht bekannt ist,
aber wieso lese ich gefühlt ständig "kann nicht sein"? Nur weil es
nicht sein darf? Fakt ist mal, daß die Forderung "eine IP für mehrere
MAC" zumindest in meinem privaten Umfeld sowohl mit ISC-dhcpd als auch
mit dnsmasq schon vor einem Jahrzehnt funktioniert hat und immer noch
funktioniert.
Ich finde diese Anforderung (ein Gerät=eine IP=ein Name) für Laptops
auch gar nicht mal so abwegig, es überrascht mich viel mehr, daß hier
Leute rumkrakeelen "sowas braucht man nicht". "Sowas brauche _ich_
nicht" wäre dann wohl die einzig passende Ausdrucksweise.


Karl

[Richard Lechner]

Post by Karl Davis
Wie kommt man eigentlich auf sowas? Das funktionierte hier schon vor
über 10 Jahren (so ca. zu Debian 3.0 Zeiten) genau so und vollkommen
problemlos.
Ich kann ja verstehen, daß das der breiten Masse nicht bekannt ist, aber
wieso lese ich gefühlt ständig "kann nicht sein"? Nur weil es nicht sein
darf? Fakt ist mal, daß die Forderung "eine IP für mehrere MAC"
zumindest in meinem privaten Umfeld sowohl mit ISC-dhcpd als auch mit
dnsmasq schon vor einem Jahrzehnt funktioniert hat und immer noch
funktioniert.
Ich finde diese Anforderung (ein Gerät=eine IP=ein Name) für Laptops
auch gar nicht mal so abwegig, es überrascht mich viel mehr, daß hier
Leute rumkrakeelen "sowas braucht man nicht". "Sowas brauche _ich_
nicht" wäre dann wohl die einzig passende Ausdrucksweise.

Ja aber wie löst ARP das im Netz auf? Müsste Zufall sein wo die Daten
rein kommen...

[Sven Hartge]

Post by Richard Lechner

Post by Karl Davis
Wie kommt man eigentlich auf sowas? Das funktionierte hier schon vor
über 10 Jahren (so ca. zu Debian 3.0 Zeiten) genau so und vollkommen
problemlos.
Ich kann ja verstehen, daß das der breiten Masse nicht bekannt ist, aber
wieso lese ich gefühlt ständig "kann nicht sein"? Nur weil es nicht sein
darf? Fakt ist mal, daß die Forderung "eine IP für mehrere MAC"
zumindest in meinem privaten Umfeld sowohl mit ISC-dhcpd als auch mit
dnsmasq schon vor einem Jahrzehnt funktioniert hat und immer noch
funktioniert.
Ich finde diese Anforderung (ein Gerät=eine IP=ein Name) für Laptops
auch gar nicht mal so abwegig, es überrascht mich viel mehr, daß hier
Leute rumkrakeelen "sowas braucht man nicht". "Sowas brauche _ich_
nicht" wäre dann wohl die einzig passende Ausdrucksweise.

Ja aber wie löst ARP das im Netz auf? Müsste Zufall sein wo die Daten
rein kommen...

Nur wenn die Metrik gleich ist.

Daher sorgt man dafür, dass das WLAN eine höhere Metrik hat, dann wird,
solange das kabelgebundene Netz Link hat, der Kernel eine ARP-Anfrage
immer nur über dieses Interface beantworten.

Erst wenn das Kabelinterface down geht, greift die Verbindung via WLAN.

S°

[Richard Lechner]

Post by Sven Hartge
Nur wenn die Metrik gleich ist.
Daher sorgt man dafür, dass das WLAN eine höhere Metrik hat, dann wird,
solange das kabelgebundene Netz Link hat, der Kernel eine ARP-Anfrage
immer nur über dieses Interface beantworten.
Erst wenn das Kabelinterface down geht, greift die Verbindung via WLAN.

Für den Switch sind beides Kabel, sobald das WLAN als erster startet hat
er den Port im Cache.
Wie macht HP das?

[Sven Hartge]

Post by Richard Lechner

Post by Sven Hartge
Nur wenn die Metrik gleich ist.
Daher sorgt man dafür, dass das WLAN eine höhere Metrik hat, dann
wird, solange das kabelgebundene Netz Link hat, der Kernel eine
ARP-Anfrage immer nur über dieses Interface beantworten.
Erst wenn das Kabelinterface down geht, greift die Verbindung via WLAN.

Für den Switch sind beides Kabel, sobald das WLAN als erster startet
hat er den Port im Cache. Wie macht HP das?

Den Switch interessiert nur die MAC->Port-Zuordnung. Die kann er gerne
haben, den Rest interessiert dies aber nicht.

Was wirklich interessant ist, ist die IP->MAC-Zuordnung, und die liegt
im Layer3 in den Endgeräten. Hier greift ja ARP bzw. ICMPv6-ND.

Und solange das fragliche Endgerät auf ARP/ND-Anfragen nach seiner MAC
nur mit der vom Kabelnetzwerk antwortet, landen auch alle Rückantworten
nur dort.

Und selbst _wenn_ das WLAN zuerst da war und ein paar Geräte sich die
MAC vom WLAN in den ARP/Neighbour-Cache gezogen haben, früher oder
später (entweder weil ein Paket mit der MAC vom Kabelnetzwerk kommt,
oder erzwungen durch Gratuitous ARP oder durch Alterung) wandert der
Traffic vom WLAN auf das Kabelnetzwerk.

S°

[Richard Lechner]

Post by Sven Hartge
Und selbst _wenn_ das WLAN zuerst da war und ein paar Geräte sich die
MAC vom WLAN in den ARP/Neighbour-Cache gezogen haben, früher oder
später (entweder weil ein Paket mit der MAC vom Kabelnetzwerk kommt,
oder erzwungen durch Gratuitous ARP oder durch Alterung) wandert der
Traffic vom WLAN auf das Kabelnetzwerk.

Das meine ich mit Zufall. Die lokale Metric interessiert keinen wenn die
Geräte die MAC schon haben. Genau ab da wird es "seltsam".

[Sven Hartge]

Post by Richard Lechner

Post by Sven Hartge
Und selbst _wenn_ das WLAN zuerst da war und ein paar Geräte sich die
MAC vom WLAN in den ARP/Neighbour-Cache gezogen haben, früher oder
später (entweder weil ein Paket mit der MAC vom Kabelnetzwerk kommt,
oder erzwungen durch Gratuitous ARP oder durch Alterung) wandert der
Traffic vom WLAN auf das Kabelnetzwerk.

Das meine ich mit Zufall. Die lokale Metric interessiert keinen wenn
die Geräte die MAC schon haben. Genau ab da wird es "seltsam".

Nö.

Ich habe gerade mal mit meinem Laptop getestet. Default ist LAN, hat die
Metrik 100, ich ping ihn von meinem Arbeitsplatz an:

64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=1 ttl=64 time=0.154 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=2 ttl=64 time=0.148 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=3 ttl=64 time=0.294 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=4 ttl=64 time=0.308 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=5 ttl=64 time=0.269 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=6 ttl=64 time=0.475 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=7 ttl=64 time=0.231 ms
--> Umstecken auf WLAN
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=12 ttl=64 time=5.25 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=13 ttl=64 time=4.05 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=14 ttl=64 time=3.36 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=15 ttl=64 time=4.25 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=16 ttl=64 time=3.89 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=17 ttl=64 time=4.13 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=18 ttl=64 time=4.07 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=19 ttl=64 time=5.38 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=20 ttl=64 time=3.82 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=21 ttl=64 time=3.76 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=22 ttl=64 time=3.75 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=23 ttl=64 time=3.80 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=24 ttl=64 time=4.25 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=25 ttl=64 time=4.16 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=26 ttl=64 time=3.52 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=27 ttl=64 time=3.97 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=28 ttl=64 time=3.77 ms
--> Kabel wieder rein
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=29 ttl=64 time=0.235 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=30 ttl=64 time=0.162 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=31 ttl=64 time=0.415 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=32 ttl=64 time=0.440 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=33 ttl=64 time=0.289 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=34 ttl=64 time=0.440 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=35 ttl=64 time=0.237 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=36 ttl=64 time=0.220 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=37 ttl=64 time=0.233 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=38 ttl=64 time=0.472 ms

Auf dem Arbeitsplatz habe ich dabei in einem separaten Fenster die Ausgabe von
"ip neigh show" laufen lassen. Wie zu erwarten ändert sich die MAC auf
die vom WLAN-Interface und wieder zurück.

OK, das lief zu glatt, zweiter Test:

64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=1 ttl=64 time=0.265 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=2 ttl=64 time=0.234 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=3 ttl=64 time=0.284 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=4 ttl=64 time=0.424 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=5 ttl=64 time=0.254 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=6 ttl=64 time=0.248 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=7 ttl=64 time=0.272 ms
--> Kabel raus
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=42 ttl=64 time=3.85 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=43 ttl=64 time=3.79 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=44 ttl=64 time=3.51 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=45 ttl=64 time=3.93 ms
64 bytes from hild.feds.ath.cx (192.168.100.17): icmp_seq=46 ttl=64 time=3.87 ms

Aha, lange Zeit passiert nichts. Erst als ich vom Laptop meinen
Arbeitsplatz anpinge, aktualisiert sich dort die MAC und der ping geht
wieder durch.

Deckt sich mit meiner Aussage.

Wenn man das beschleunigen will, dann könnte man z.B. Network-Manager
ein Script beim DHCP-Lease-Erhalten starten lassen, welches via arping
einen Gratuitous ARP schickt, dann updaten sich alle Geräte im LAN
direkt.

S°

[Richard Lechner]

Post by Sven Hartge
Wenn man das beschleunigen will, dann könnte man z.B. Network-Manager
ein Script beim DHCP-Lease-Erhalten starten lassen, welches via arping
einen Gratuitous ARP schickt, dann updaten sich alle Geräte im LAN
direkt.

Womit wir wieder bei der Stochastik wären. :-)

Hint: Es ging ursprünglich um beide gleichzeitig aktiv und nicht um Kabel
ab- und anstecken.

[Sven Hartge]

Post by Richard Lechner

Post by Sven Hartge
Wenn man das beschleunigen will, dann könnte man z.B. Network-Manager
ein Script beim DHCP-Lease-Erhalten starten lassen, welches via
arping einen Gratuitous ARP schickt, dann updaten sich alle Geräte im
LAN direkt.

Womit wir wieder bei der Stochastik wären. :-)
Hint: Es ging ursprünglich um beide gleichzeitig aktiv und nicht um
Kabel ab- und anstecken.

Wenn beide aktiv sind, dann ist das Setup stabil. Es "gewinnt" immer die
Verbindung mit der geringsten Metrik und dies bleibt auch so.

S°

[Sven Hartge]

Post by Juergen P. Meier

Post by Sven Hartge
dhcpd von ISC hat keine Probleme damit, lediglich der Name beim
host laptop-lan {
hardware ethernet 00:24:de:ad:be:ef;
fixed-address 192.168.100.17;
}
host laptop-wlan {
hardware ethernet 00:21:af:fe:ca:fe;
fixed-address 192.168.100.17;
}

Hast du beide Leases gleichzeitig aktiv? Das duerfte ISC dhcpd
verhindern.

Was für Leases? Das obige ist aus der dhcpd.conf und somit eine DHCP
Reservation. Dafür wird kein Lease angelegt.

S°

[kay]

Post by Sven Hartge

Post by Juergen P. Meier

Post by Sven Hartge
dhcpd von ISC hat keine Probleme damit, lediglich der Name beim
host laptop-lan {
hardware ethernet 00:24:de:ad:be:ef;
fixed-address 192.168.100.17;
}
host laptop-wlan {
hardware ethernet 00:21:af:fe:ca:fe;
fixed-address 192.168.100.17;
}

Hast du beide Leases gleichzeitig aktiv? Das duerfte ISC dhcpd
verhindern.

Was für Leases? Das obige ist aus der dhcpd.conf und somit eine DHCP
Reservation. Dafür wird kein Lease angelegt.

HUPS. Merke eben das ich DEN Umstand übersah bei einer vorigen Antwort.
Logisch, da damit eine feste IP immer wieder der gleichen MAC zugewiesen
wird gibt es dafür kein Lease, keine ablaufzeit und prinzipiell können
auch beide gleichzeitig genutzt sein.

Dann aber vermutlich nur mit unterschiedlichen IPs, oder?

Ich weiß jetzt nicht ob eine arp-anfrage auch mehrere MAC zurück liefern
kann. Wenn ja, spielen die Verbindungen vermutlich ping-pong zwischen
LAN und WLAN wenn man mal beides an hat. Wenn nicht, dürfte sich das
Problem nur eine Ebene höher verlagern (IP, TCP/UDP)

Die Lösung ist aber einfach und Trivial. Erste das eine Deaktivieren
bevor man das andere Aktiviert.

Ist nur nicht DAU-tauglich.

Kay

[Sven Hartge]

Post by kay

Post by Sven Hartge

Post by Juergen P. Meier

Post by Sven Hartge
dhcpd von ISC hat keine Probleme damit, lediglich der Name beim
host laptop-lan {
hardware ethernet 00:24:de:ad:be:ef;
fixed-address 192.168.100.17;
}
host laptop-wlan {
hardware ethernet 00:21:af:fe:ca:fe;
fixed-address 192.168.100.17;
}

Hast du beide Leases gleichzeitig aktiv? Das duerfte ISC dhcpd
verhindern.

Was für Leases? Das obige ist aus der dhcpd.conf und somit eine DHCP
Reservation. Dafür wird kein Lease angelegt.

HUPS. Merke eben das ich DEN Umstand übersah bei einer vorigen Antwort.
Logisch, da damit eine feste IP immer wieder der gleichen MAC zugewiesen
wird gibt es dafür kein Lease, keine ablaufzeit und prinzipiell können
auch beide gleichzeitig genutzt sein.
Dann aber vermutlich nur mit unterschiedlichen IPs, oder?

Nein. Wie gesagt, mein Beispiel funktioniert. Seit Jahren.

Post by kay
Ich weiß jetzt nicht ob eine arp-anfrage auch mehrere MAC zurück liefern
kann.

Nein.

Post by kay
Wenn ja, spielen die Verbindungen vermutlich ping-pong zwischen LAN
und WLAN wenn man mal beides an hat.

Nein, wenn die Metrik nicht korrekt, also identisch ist, dann "gewinnt"
bei Linux das Interface, welches zuerst oben ist. Daher hat man
unterschiedliche Metriken pro Netzroute/Interface und dann gibt es das
Problem nicht.

Network-Manager macht dies z.B. automatisch, mein LAN hat 100, das WLAN
hat 600. Bei anderen Tools muss man ggfls. selbst Hand anlegen.

S°

[Bastian Blank]

Post by Juergen P. Meier
Hast du beide Leases gleichzeitig aktiv? Das duerfte ISC dhcpd
verhindern.

Der ISC dhcpd hat damit keine Problem, warum auch? Er weiß das die Lease
unbegrenzt gültig ist und zwar für beide MAC.

Allerdings ist der richtige Fix sowieso Client-ID, wie bei DHCPv6
Standard ist.

Bastian