TCP stirbt auf einem Linux-Laptop

17

Einmal in mehreren Tagen habe ich folgendes Problem. Mein Laptop (Debian-Test) kann plötzlich nicht mehr mit TCP-Verbindungen zum Internet arbeiten.

Die folgenden Dinge funktionieren weiterhin einwandfrei:

  • UDP (DNS), ICMP (Ping) - Ich erhalte sofort eine Antwort
  • TCP-Verbindungen zu anderen Rechnern im lokalen Netzwerk (z. B. kann ich zu einem benachbarten Laptop sshen)
  • Für andere Rechner in meinem LAN ist alles in Ordnung

Wenn ich jedoch TCP-Verbindungen von meinem Laptop aus versuche, tritt eine Zeitüberschreitung auf (keine Antwort auf SYN-Pakete). Hier ist eine typische Curl-Ausgabe:

% curl -v google.com     
* About to connect() to google.com port 80 (#0)
*   Trying 173.194.39.105...
* Connection timed out
*   Trying 173.194.39.110...
* Connection timed out
*   Trying 173.194.39.97...
* Connection timed out
*   Trying 173.194.39.102...
* Timeout
*   Trying 173.194.39.98...
* Timeout
*   Trying 173.194.39.96...
* Timeout
*   Trying 173.194.39.103...
* Timeout
*   Trying 173.194.39.99...
* Timeout
*   Trying 173.194.39.101...
* Timeout
*   Trying 173.194.39.104...
* Timeout
*   Trying 173.194.39.100...
* Timeout
*   Trying 2a00:1450:400d:803::1009...
* Failed to connect to 2a00:1450:400d:803::1009: Network is unreachable
* Success
* couldn't connect to host
* Closing connection #0
curl: (7) Failed to connect to 2a00:1450:400d:803::1009: Network is unreachable

Ein Neustart der Verbindung und / oder ein erneutes Laden des Netzwerkkartenkernelmoduls hilft nicht. Das einzige, was hilft, ist ein Neustart.

Offensichtlich stimmt etwas mit meinem System nicht (alles andere funktioniert einwandfrei), aber ich habe keine Ahnung, was genau.

Mein Setup ist ein WLAN-Router, der über PPPoE mit dem ISP verbunden ist.

Irgendein Rat?

Antworten auf Kommentare

Was für eine Netzwerkkarte ist das?

12:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
  Subsystem: Dell Inspiron M5010 / XPS 8300
  Flags: bus master, fast devsel, latency 0, IRQ 17
  Memory at fbb00000 (64-bit, non-prefetchable) [size=16K]
  Capabilities: [40] Power Management version 3
  Capabilities: [58] Vendor Specific Information: Len=78 <?>
  Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
  Capabilities: [d0] Express Endpoint, MSI 00
  Capabilities: [100] Advanced Error Reporting
  Capabilities: [13c] Virtual Channel
  Capabilities: [160] Device Serial Number 00-00-9d-ff-ff-aa-1c-65
  Capabilities: [16c] Power Budgeting <?>
  Kernel driver in use: brcmsmac

Wie ist der Status Ihrer Netzwerkkarte, wenn das Problem auftritt?

iptables-save druckt nichts.

ip rule show:

0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default

ip route show table all:

default via 192.168.1.1 dev wlan0 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.105 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.1.0 dev wlan0  table local  proto kernel  scope link  src 192.168.1.105 
local 192.168.1.105 dev wlan0  table local  proto kernel  scope host  src 192.168.1.105 
broadcast 192.168.1.255 dev wlan0  table local  proto kernel  scope link  src 192.168.1.105 
fe80::/64 dev wlan0  proto kernel  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101 hoplimit 255
local ::1 via :: dev lo  table local  proto none  metric 0 
local fe80::1e65:9dff:feaa:b1f1 via :: dev lo  table local  proto none  metric 0 
ff00::/8 dev wlan0  table local  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101 hoplimit 255

Alles oben Genannte ist dasselbe, wenn das Gerät im normalen Modus arbeitet.

ifconfig- Ich habe es ausgeführt, aber irgendwie vergessen, vor dem Neustart zu speichern. Muss warten, bis das nächste Mal das Problem auftritt. Das tut mir leid.

Ist eine QoS vorhanden?

Wahrscheinlich nicht - zumindest habe ich nichts spezielles getan, um dies zu ermöglichen.

Haben Sie versucht, den tatsächlich über die Schnittstelle gesendeten Datenverkehr zu überwachen?

Ich habe mehrere Male Curl und Tcpdump ausgeführt, und es gab zwei Muster.

Das erste sind nur SYN-Pakete ohne Antworten.

17:14:37.836917 IP (tos 0x0, ttl 64, id 4563, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42030 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0xbea8), seq 3764607647, win 13600, options [mss 1360,sackOK,TS val 33770316 ecr 0,nop,wscale 4], length 0
17:14:38.836650 IP (tos 0x0, ttl 64, id 4564, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42030 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0xbdae), seq 3764607647, win 13600, options [mss 1360,sackOK,TS val 33770566 ecr 0,nop,wscale 4], length 0
17:14:40.840649 IP (tos 0x0, ttl 64, id 4565, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42030 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0xbbb9), seq 3764607647, win 13600, options [mss 1360,sackOK,TS val 33771067 ecr 0,nop,wscale 4], length 0

Der zweite ist dieser:

17:22:56.507827 IP (tos 0x0, ttl 64, id 41583, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0x2244), seq 1564709704, win 13600, options [mss 1360,sackOK,TS val 33894944 ecr 0,nop,wscale 4], length 0
17:22:56.546763 IP (tos 0x58, ttl 54, id 65442, offset 0, flags [none], proto TCP (6), length 60)
    fra07s07-in-f102.1e100.net.http > 192.168.1.105.42036: Flags [S.], cksum 0x6b1e (correct), seq 1407776542, ack 1564709705, win 14180, options [mss 1430,sackOK,TS val 3721836586 ecr 33883552,nop,wscale 6], length 0
17:22:56.546799 IP (tos 0x58, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [R], cksum 0xf301 (correct), seq 1564709705, win 0, length 0
17:22:58.511843 IP (tos 0x0, ttl 64, id 41584, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [S], cksum 0x27fc (incorrect -> 0x204f), seq 1564709704, win 13600, options [mss 1360,sackOK,TS val 33895445 ecr 0,nop,wscale 4], length 0
17:22:58.555423 IP (tos 0x58, ttl 54, id 65443, offset 0, flags [none], proto TCP (6), length 60)
    fra07s07-in-f102.1e100.net.http > 192.168.1.105.42036: Flags [S.], cksum 0x3b03 (correct), seq 1439178112, ack 1564709705, win 14180, options [mss 1430,sackOK,TS val 3721838596 ecr 33883552,nop,wscale 6], length 0
17:22:58.555458 IP (tos 0x58, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.105.42036 > fra07s07-in-f102.1e100.net.http: Flags [R], cksum 0xf301 (correct), seq 1564709705, win 0, length 0

Ethtool-Ausgabe

ethtool -k wlan0:

Features for wlan0:
rx-checksumming: off [fixed]
tx-checksumming: off
  tx-checksum-ipv4: off [fixed]
  tx-checksum-unneeded: off [fixed]
  tx-checksum-ip-generic: off [fixed]
  tx-checksum-ipv6: off [fixed]
  tx-checksum-fcoe-crc: off [fixed]
  tx-checksum-sctp: off [fixed]
scatter-gather: off
  tx-scatter-gather: off [fixed]
  tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
  tx-tcp-segmentation: off [fixed]
  tx-tcp-ecn-segmentation: off [fixed]
  tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: on [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]

iptables

# namei -l "$(command -v iptables)"
f: /sbin/iptables
drwxr-xr-x root root /
drwxr-xr-x root root sbin
lrwxrwxrwx root root iptables -> xtables-multi
-rwxr-xr-x root root   xtables-multi

# dpkg -S "$(command -v iptables)"
iptables: /sbin/iptables

# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
# iptables -t security -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Modulinfo

# ethtool -i wlan0                   
driver: brcmsmac
version: 3.2.0-3-686-pae
firmware-version: N/A
bus-info: 0000:12:00.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

# modinfo brcmsmac
filename:       /lib/modules/3.2.0-3-686-pae/kernel/drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko
license:        Dual BSD/GPL
description:    Broadcom 802.11n wireless LAN driver.
author:         Broadcom Corporation
alias:          pci:v000014E4d00000576sv*sd*bc*sc*i*
alias:          pci:v000014E4d00004727sv*sd*bc*sc*i*
alias:          pci:v000014E4d00004353sv*sd*bc*sc*i*
alias:          pci:v000014E4d00004357sv*sd*bc*sc*i*
depends:        mac80211,brcmutil,cfg80211,cordic,crc8
intree:         Y
vermagic:       3.2.0-3-686-pae SMP mod_unload modversions 686

Es gibt keine /sys/module/brcmsmac/parameters. Folgendes habe ich dort:

# tree /sys/module/brcmsmac
/sys/module/brcmsmac
├── drivers
│   └── pci:brcmsmac -> ../../../bus/pci/drivers/brcmsmac
├── holders
├── initstate
├── notes
├── refcnt
├── sections
│   └── __bug_table
└── uevent

Einige Websites funktionieren tatsächlich

Wie von Dr. vorgeschlagen , habe ich einige andere Websites ausprobiert, und zu meiner großen Überraschung haben einige davon tatsächlich funktioniert. Hier sind einige Hosts, die funktioniert haben:

  • rambler.ru
  • google.ru
  • ya.ru
  • opennet.ru
  • tut.by
  • ro-che.info
  • yahoo.com
  • ebay.com

Und hier sind einige, die dies nicht taten:

  • vk.com
  • meta.ua
  • ukr.net
  • tenet.ua
  • prom.ua
  • reddit.com
  • github.com
  • stackexchange.com

Netzwerkerfassung

Ich habe ein Netzwerk-Capture erstellt und es hier hochgeladen .

debian networking tcp Roman Cheplyaka
quelle
1
Nur aus Neugier: Wie ist der Zustand Ihrer Netzwerkkarte, wenn das Problem auftritt? (/ sbin / ifconfig?)
yves Baumes
Hatten Sie versucht, den tatsächlich über die Schnittstelle gesendeten Datenverkehr zu überwachen (wireshark / tcpdump ...)? Was für eine Netzwerkkarte ist das? Ist es drahtlos? Was ist der Ausgang iptables-save, der ip rule show, ip route show table all. Ist eine QoS vorhanden?
Stéphane Chazelas
Aktualisiert den Beitrag mit Antworten auf Ihre Fragen.
Roman Cheplyaka
1
Ich habe keine Treiber aus der Quelle gebaut. Das Modul selbst stammt aus dem Debian-Kernel (Paket linux-image-3.2.0-3-686-pae) und die Firmware stammt aus dem firmware-brcm80211Paket. Hattest du ähnliche Probleme wie ich? Ich würde es lieber vermeiden, Dinge von Hand zu bauen, es sei denn, es ist ein bekanntes Problem. Warum sollte sich ein NIC-Modulproblem auf der Ebene 4 manifestieren?
Roman Cheplyaka
1
Höchstwahrscheinlich ist alles, was falsch ist, auf Ihrer Wi-Fi-Basisstation, Ihrem Switch oder Ihrem Router. Versuchen Sie dort nach Möglichkeit, Pakete (oder Paketzählungen) zu verfolgen. Wenn nicht, tauschen Sie sie gegen andere aus.
Bahamat

Antworten:

5

In der Erfassungs Sie zur Verfügung gestellt, die Antwort Time Stamp Echo in der SYN-ACK in dem zweiten Paket nicht die TSVal im SYN im ersten Paket übereinstimmen und ist nur ein paar Sekunden hinter sich .

Und sehen Sie, wie alle von 173.194.70.108 und 209.85.148.100 gesendeten TSecr gleich und für den von Ihnen gesendeten TSVal irrelevant sind.

Es sieht so aus, als ob sich etwas mit den TCP-Zeitstempeln vermischt. Ich habe keine Ahnung, was das verursacht, aber es klingt, als ob es sich außerhalb Ihres Computers befindet. Hilft in diesem Fall ein Neustart des Routers?

Ich weiß nicht, ob es der Grund ist, warum Ihr Computer eine RST sendet (im dritten Paket). Aber dieses SYN-ACK mag es definitiv nicht und es ist das einzige, was ich falsch finden kann. Die einzige andere Erklärung, die ich mir vorstellen kann, ist, dass ich dies bezweifle, wenn nicht Ihr Computer die RST sendet, sondern der Zeitunterschied zwischen SYN-ACK und RST. Aber nur für den Fall, verwenden Sie virtuelle Maschinen oder Container oder Netzwerknamespaces auf dieser Maschine?

Sie können versuchen, TCP-Zeitstempel vollständig zu deaktivieren, um festzustellen, ob dies hilft:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Entweder senden diese Sites falsches TSecr, oder es ist etwas auf dem Weg dorthin (ein beliebiger Router oder ein transparenter Proxy), das entweder den ausgehenden TSVal oder den eingehenden TSecr oder einen Proxy mit einem falschen TCP-Stack verstümmelt. Warum man die TCP-Zeitstempel verfälscht, kann ich nur spekulieren: Fehler, Ausweichen vor Eindringlingen, ein zu intelligenter / falscher Algorithmus zur Verkehrssteuerung. Davon habe ich noch nie gehört (aber dann bin ich kein Experte auf diesem Gebiet).

Wie weiter zu untersuchen:

  • Überprüfen Sie, ob der TPLink-Router schuld daran ist, dass er zurückgesetzt wurde, um festzustellen, ob dies hilfreich ist, oder erfassen Sie den Datenverkehr nach Möglichkeit auch von außen, um festzustellen, ob die Zeitstempel dadurch beschädigt werden
  • Überprüfen Sie, ob ein transparenter Proxy unterwegs ist, indem Sie mit TTLs spielen, Anforderungsheader anzeigen, die von Webservern empfangen wurden, oder das Verhalten beim Anfordern toter Websites anzeigen.
  • Erfassen Sie den Datenverkehr auf einem Remote-Webserver, um festzustellen, ob der TSVal oder der TSecr beschädigt ist.
Stéphane Chazelas
quelle
Nein, ich hatte keine VMS / Container am Laufen. Ich versuche es nächstes Mal mit deinen Vorschlägen, danke.
Roman Cheplyaka
1
Xm .. Dein Vorschlag über tcp_timestamps löst definitiv mein Problem. Kein Problem mit Google und anderen Websites, nachdem net.ipv4.tcp_timestamps auf 0 gesetzt wurde und alle Probleme erneut, falls net.ipv4.tcp_timestamps = 1, aber WARUM?
dr.
1

Es steht oben eine falsche Prüfsumme. Gibt es eine Prüfsummen-Auslagerung für dieses Gerät (ich wusste nicht, dass drahtlose Geräte Prüfsummen auslagern können)?

Was sudo ethtool -k wlan0sagt dir das ? Wenn es ein Entladen gibt, können Sie versuchen, es zu deaktivieren.

Sie müssen root sein, um iptables-save aufzurufen. Es gibt immer noch eine entfernte Chance, dass etwas Pakete dort zerfleischt. Wenn iptables-savees nicht funktioniert, versuchen Sie Folgendes:

iptables -nvL
iptables -t mangle -nvL
iptables -t nat -nvL
iptables -t security -nvL

Entspricht die Ziel-MAC-Adresse in Ihrer Netzwerkerfassung der des Routers? Interessant im Vergleich von UDP-Verkehr zu TCP-Verkehr?

Wo $devbefindet sich der Kerneltreiber (Modul) (siehe ethtool -i wlan0) für Ihren WLAN-Adapter ? Was tun modinfo "$dev"und grep . /sys/module/"$dev"/parameters/*sagen Sie?

Stéphane Chazelas
quelle
Guter Fang! Ich habe die falschen Prüfsummen nicht bemerkt. Ich aktualisiere die Antwort mit der Ausgabe von ethtool. iptables-save wurde als root ausgeführt, druckt nichts. Beim nächsten Mal starte ich tcpdump erneut, um die MAC-Adressen anzuzeigen.
Roman Cheplyaka
Wenn iptables-save nichts zurückgibt, stimmt definitiv etwas nicht. Was machst namei -l "$(command -v iptables)"und dpkg -S "$(command -v iptables)"sagst du?
Stéphane Chazelas
Veröffentlicht die Ausgabe.
Roman Cheplyaka
Der Beitrag wurde mit Modulinformationen aktualisiert.
Roman Cheplyaka
Vielen Dank. Siehe meine Änderungen an meiner Antwort. Können Sie auch irgendwo einen pcap für Ihr Capture einfügen, oder vielleicht die Ausgabe tshark -Viwlan0 tcpfür eines dieser SYN-Pakete hier?
Stéphane Chazelas
1

Anscheinend verhalte ich mich auch bei meinem Laptop genauso . Ich kenne den Grund nicht, aber von Zeit zu Zeit konnte ich keine Verbindung zu google.com und einigen anderen externen Ressourcen herstellen. Pings und DNS-Abfragen funktionieren einwandfrei. Außerdem habe ich nur eine Lösung gefunden: Neustart .

Ich könnte einige Beobachtungen hinzufügen:

  1. Wenn ich ein anderes Betriebssystem in meiner Virtual Box (Windows, ArchLinux, Ubuntu) starte, kann ich problemlos TCP-Verbindungen mit problematischen Hosts herstellen.
  2. Einige Hosts im Internet verhalten sich wie google.com, aber es gibt viele, auf die normalerweise über Telnet oder einen Webbrowser zugegriffen werden kann
  3. Ich habe keinen WIFI-Adapter auf meinem Laptop, ich habe nur eine Ethernet-Verbindung zum Router
  4. Ich habe versucht, in den Debian / Gentoo-Benutzerraum zu chrooten - es hilft nicht
  5. Ich habe meine Netzwerkkarte durch eine neue ersetzt - das hilft nicht

Einige technische Informationen zu meiner Box:

Betriebssystem: Letztes ArchLinux amd64

$ ethtool -i  eth0
driver: via-rhine
version: 1.5.0
firmware-version: 
bus-info: 0000:02:07.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

$uname -a
Linux eniac-2 3.5.4-1-ARCH #1 SMP PREEMPT Sat Sep 15 08:12:04 CEST 2012 x86_64 GNU/Linux

Ich nehme an, dieses fehlerhafte Verhalten tritt wegen eines subtilen Fehlers in einigen Versionen des Linux-Kernels auf, aber ich weiß nicht, wie ich dieses Problem beheben soll, und wegen der instabilen Reproduktion stecke ich fest.

DR.
quelle
Danke für das Teilen! Was sind einige Beispiele für Hosts, die funktionieren?
Roman Cheplyaka
Beispiele für Hosts, die bei Auftreten dieses fehlerhaften Verhaltens funktionieren: opennet.ru, tut.by.
dr.
Ich bin jetzt überzeugt, dass wir in der Tat das gleiche Problem haben ...
Roman Cheplyaka
Ja! Genau. Ich denke darüber nach, meine Router-Firmware auf etwas wie dd-wrt oder openwrt zu aktualisieren oder nur den Linux-Kernel zu downgraden. Haben Sie einen dieser Schritte ausprobiert?
dr.
1
Nein, ich würde gerne herausfinden, was zum Teufel hier los ist.
Roman Cheplyaka
0 
/sbin/iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Ich hatte das gleiche Problem, das Sie beschrieben haben, bis Sie den obigen Befehl my Internet Gateway iptables -Befehle hinzugefügt haben . In ist standardmäßig im Paket rp-pppoe und anderen enthalten. Wenn Sie sich jedoch für benutzerdefinierte Konfigurationen entscheiden und diese nicht manuell festlegen, treten bei den Computern im LAN hinter dem Gateway die beschriebenen Probleme auf.

Kostya Berger
quelle