[VFKD] Merkwürdige Ausfälle – MAC-Sperrung durch VF?

[Salocin]

Ich habe seit Monaten ein immer wieder auftretendes Problem. Vom einen auf den anderen Moment fällt mein Internetanschluss einfach aus. Ich bekomme zwar noch per DHCP meine öffentliche IP zugewiesen, es geht aber kein Traffic nach draußen – laut tcpdump kommt aber z. B. ein Ping von außen durchaus rein. Ich habe eine Vodafone Station (CGA4233DE) und betreibe diese im Bridge-Modus. Wenn ich den Bridge-Modus deaktiviere und die VF Station neu starte funktioniert es, aber ich hänge mit meinem eigenen Router dann hinter dem NAT der VF Station. Schalte ich den Bridge-Modus wieder ein tritt der Fehler direkt wieder auf. Jetzt das spannende: Spoofe ich in meinem eigenen Route die MAC-Adresse der Ethernetschnittstelle funktioniert auf einmal zumindest IPv4 wieder, IPv6 (habe Dual Stack) meist nicht bzw. erst deutlich später. Schalte ich die MAC-Adresse zurück auf die ursprüngliche tritt der Fehler wieder auf. Für mich sieht es so aus, als würde irgendetwas bei VF meinen Router anhand seiner MAC sperren. Diese Sperre lässt sich durch Spoofing natürlich umgehen aber es verursacht jedes Mal einen Ausfall und einen manuellen Eingriff meinerseits. Ich bin mir sehr sicher, dass es sich nicht um ein Config-Problem auf meiner Seite handelt, denn wenn ich meinen Laptop direkt an die VF Station anschließe und da wiederum die MAC-Adresse auf die aktuell nicht funktierende des Routers spoofe geht ebenfalls nichts durch, setze ich eine andere geht's.

Die Probleme habe ich mehrfach dem VF-Support gemeldet, aber da scheint man ausschließlich in Signalstörungen auf dem Kabel zu denken, die hier eher nicht ursächlich sein dürften. Die ersten Male wurden angeblich auch schlechte Signale auf dem Kabel gemessen und ein Techniker hat mir hier in mehreren Terminen mehrfach das Modem getauscht, außerdem die Kabel-Anschlussdose in der Wohnung und das Coax-Kabel vom Modem. Jedes Mal ging es dann erst mal wieder, bis nach einer Weile der Fehler erneut auftrat und sich erneut durch MAC-Spoofing „beheben“ ließ. Ein Hardware-Problem oder schlechtes Signal schließe ich aber aus, da es sich nicht durch MAC-Spoofing beheben ließe.

Kennt hier jemand das Phänomen und kann mich vielleicht in die richtige Richtung schubsen, wie ich das nachhaltig fixen kann?

Falls es relevant ist: Ich habe einen Red Business Internet 300 Cable mit Option Feste IP-Adresse und befinde mich in Bremen, also im ehemaligen Kabel-Deutschland-Netz.

[Flole]

Du kannst immer nur ein Gerät am Modem anschließen, alle weiteren Geräte (MAC Adressen) werden ignoriert. Also wenn du die MAC Adresse spoofst ohne das Modem neu zu starten so sind Probleme vorprogrammiert. Ebenso muss die IP Adresse per DHCP bezogen werden.

[Salocin]

Du kannst immer nur ein Gerät am Modem anschließen, alle weiteren Geräte (MAC Adressen) werden ignoriert. Also wenn du die MAC Adresse spoofst ohne das Modem neu zu starten so sind Probleme vorprogrammiert. Ebenso muss die IP Adresse per DHCP bezogen werden.

Es ist nur ein Gerät am Modem angeschlossen, mein Router. Alle anderen Geräte hängen an diesem Router. Ausnahme: Zum Testen mal der Laptop direkt – dann aber der Router abgesteckt. DHCP ist aktiv, die Adresse bekomme ich ja auch, nur geht dann nichts durch.

[Salocin]

Vorweg: Meine eigene IP-Adresse habe ich hier zensiert indem ich die letzten zwei Stellen genullt habe.

Aktuell geht es, nachdem ich heute Nachmittag die Adresse auf 04:08:15:16:23:02 gespooft hatte.

Code: Alles auswählen

root@router:~# ip a show eth4
4: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000
    link/ether 04:08:15:16:23:02 brd ff:ff:ff:ff:ff:ff
    inet 90.187.0.0/30 scope global dynamic eth4
       valid_lft 453334sec preferred_lft 453334sec
    inet6 fe80::608:15ff:fe16:2301/64 scope link
       valid_lft forever preferred_lft forever
root@router:~#
root@router:~# ping -I eth4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 90.187.0.0 eth4: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=13.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=11.1 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 11.051/11.852/12.991/0.812 ms

Ändere ich die MAC-Adresse auf die zuvor verwendete 04:08:15:16:23:42 …

Code: Alles auswählen

root@router:~# ip link set dev eth4 down
root@router:~# ip link set dev eth4 address 04:08:15:16:23:42
root@router:~# ip link set dev eth4 up

… bekomme ich zwar meine IP per DHCP:

Code: Alles auswählen

root@router:~# ip a show eth4
4: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000
    link/ether 04:08:15:16:23:42 brd ff:ff:ff:ff:ff:ff
    inet 90.187.0.0/30 scope global dynamic eth4
       valid_lft 453808sec preferred_lft 453808sec
    inet6 fe80::608:15ff:fe16:2302/64 scope link
       valid_lft forever preferred_lft forever

Ping geht aber nicht mehr durch:

Code: Alles auswählen

root@router:~# ping -I eth4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 90.187.0.0 eth4: 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3097ms
pipe 2

Ändere ich das Spoofing wieder auf die aktuell funktionierende Adresse geht's wieder:

Code: Alles auswählen

root@router:~# ip link set dev eth4 down
root@router:~# ip link set dev eth4 address 04:08:15:16:23:02
root@router:~# ip link set dev eth4 up
root@router:~# ping -I eth4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 90.187.0.0 eth4: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=14.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=13.4 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 13.350/14.091/14.832/0.741 ms
root@router:~#

Und ich kann jetzt schon voraussagen: Irgendwann in den nächsten 1-14 Tagen wird das wieder einfach aufhören zu funktionieren. Dann werde ich am Ende der MAC-Adresse aus der :02 eine :03 machen und dann geht's wieder für eine Weile.

[Flole]

Machst du nach jeder Änderung der MAC Adresse einen Neustart des Modems und fragst die IP per DHCP neu an?

[Salocin]

Machst du nach jeder Änderung der MAC Adresse einen Neustart des Modems und fragst die IP per DHCP neu an?

Neustart hatte ich zwischenzeitlich probiert, es macht keinen Unterschied. Entweder es geht nach der Änderung der MAC einfach so wieder oder eben nicht und ich nehme die nächste Adresse.

Aber: Ich bin überhaupt nicht scharf drauf, hier MAC-Adressen zu spoofen. Ich möchte eigentlich nur einen durchgehend funktionierenden Anschluss. Auch ein regelmäßig neu zu startendes Modem würde diese Voraussetzung nicht erfüllen.

Die IP fragt mein Router automatisch per DHCP an, dass das wirklich passiert kann ich in den Logs auch nachvollziehen:

Code: Alles auswählen

Sep 08 22:10:14 router ubios-udapi-server[1071169]: udhcpc: broadcasting discover (interface:eth4)
Sep 08 22:10:14 router ubios-udapi-server[1071169]: udhcpc: received offer of 90.187.0.0 (interface:eth4)
Sep 08 22:10:14 router ubios-udapi-server[1071217]: [info ] ubios-dhcpc-decline-script: DHCP offer 90.187.0.0/30 on interface eth4, gateway: 90.187.0.0
Sep 08 22:10:14 router ubios-udhcpc-decline-script[1071217]: ubios-dhcpc-decline-script: DHCP offer 90.187.0.0/30 on interface eth4, gateway: 90.187.0.0
Sep 08 22:10:14 router ubios-udapi-server[1071217]: [info ] ubios-dhcpc-decline-script: DHCP offer 90.187.0.0/30 accepted
Sep 08 22:10:14 router ubios-udhcpc-decline-script[1071217]: ubios-dhcpc-decline-script: DHCP offer 90.187.0.0/30 accepted
Sep 08 22:10:14 router ubios-udapi-server[1071169]: udhcpc: sending request (interface:eth4)
Sep 08 22:10:14 router ubios-udapi-server[1071169]: udhcpc: broadcasting select for 90.187.0.0, server 88.134.228.130
Sep 08 22:10:15 router ubios-udapi-server[1071169]: udhcpc: received ACK: lease of 90.187.0.0 obtained from 88.134.228.130, lease time 452797 (interface:eth4)
Sep 08 22:10:15 router ubios-udapi-server[943]: dhcp-client: Synchronizing eth4 DHCP lease 90.187.0.0:bound