PPP stürzt bei hoher Last regelmäßig ab

P

PatTheMav

Well-Known Member
Seit ich meinen FreeBSD-Server auf neue Hardware umgezogen habe, macht mir user-ppp regelmäßig Sorgen. Wann immer z.B. Torrents laufen, ist an ein flüssiges Surfen nicht mehr zu denken, die Webseiten kommen mit Modem-Geschwindigkeit auf den Monitor.

Das geht dann ein paar Minuten lang so, bevor dann sämtlicher Traffic zusammenbricht und ppp gemütlich weiterläuft, keinerlei Meldungen in der Logdatei anzeigt, sondern einfach nur "hängt". Erst ein Neustart des Prozesses hilft hier weiter bis zum nächsten Totalausfall. Dabei war es ganz egal, ob ich NAT mit ppp oder pf machen lasse, pf oder ipfw verwende.

Dabei lief alles mit der identischen Konfiguration auf der alten Hardware problemlos - internes Interface war die Onboard-Intelkarte (xl0), externes Interface zum DSL-Modem war eine Netgear-Karte (sis0).

Vielleicht weiß einer von euch eine Lösung, woran das liegen kann:

ppp.conf:
Code: 
default:
 set device PPPoE:sis0
 set MTU 1492
 set MRU 1492
 set dial
 set crtscts off
 set speed sync
 set server /var/run/ppp.sock "" 0177
 set urgent udp 53
 accept lqr
 disable deflate
 disable pred1
 disable vjcomp
 disable acfcomp
 disable protocomp
 disable ipv6cp
 add! default HISADDR
 nat enable no
 enable dns
 resolv readonly
 set log Phase Chat LCP IPCP CCP tun command
 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0
 set authname bla@t-online.de
 set authkey blubb
 
Die Version 5 des MPD hab ich mit FreeBSD 6.2-p9 ausprobiert. Wenn die Verbindung stand, hab ich mit pfctl -ef /etc/pf.conf die Firewall Regel neu geladen. Daraufhin hat mein Server rebootet.

Ich hatte den MPD mit NG_IPPACCOUNTING und NG_CAR gebaut.

Nach 3 Reboots habe ich aber auch nicht mehr Zeit investiert, sondern bin zum User PPP zurueck.
 
So habs gebaut, läuft bisher einwandfrei unter FreeBSD7 mit pf, altq und mpd5 - ich schau mir das mal an!
 
ALTQ verträgt sich nach wie vor nicht mit Netgraph, welches MPD nutzt! Es gibt einen Patch, der ist bis jetzt allerdings nur in -CURRENT. Ohne diesen Patch riskierst du eine panic(), sobald das Gerät ng0 verschwindet. Das ist zum Beispiel bei plötzlichen Verbindungsabrissen der Fall.
 
Ich werds beobachten.

Kann ich MPD ähnlich wie mit pppctl gezielt zu einem Neuaufbau der Verbindung bringen? Z.B. um gezielt um 7 Uhr morgens einen reconnect zu erzwingen?

Nachdem hier im Haus an offenen Leitungen gearbeitet werden musste und der Server daher einen gezielten Neustart hinter sich hat, ist mir noch was anderes aufgefallen: pf wird doch vor mpd gestartet - nun existiert ng0 noch nicht zum Zeitpunkt der Initialisierung der pf.conf und mir schmeißt pf dann auch nen schönen Fehler, dass ein Device nicht existiert (ich denke mal, dass der AltQ-Teil den Fehler schmeißt) - nach dem Boot löst ein "/etc/rc.d/pf restart" alle Probleme, aber das muss doch eleganter gehen? Zumal man per pfctl nur die Regelsets, nicht aber AltQ und NAT-Einstellungen usw. neu laden kann.
 
Zuletzt bearbeitet:
Yamagi schrieb:
ALTQ verträgt sich nach wie vor nicht mit Netgraph, welches MPD nutzt! Es gibt einen Patch, der ist bis jetzt allerdings nur in -CURRENT. Ohne diesen Patch riskierst du eine panic(), sobald das Gerät ng0 verschwindet. Das ist zum Beispiel bei plötzlichen Verbindungsabrissen der Fall.
Zum Vergrößern anklicken....

Danke fuer die Info, jetzt weiss ich, woher die panic kam. ;) Haette ich mich mal vorher informieren sollen... :(
 
Also ich habe bisher keine Kernel-Panics und seit der Verwendung von mpd5-RELEASE hab ich schon 3 24h-Reconnects hinter mir - hatte ich bisher nur Glück? :o

Auf jeden Fall muss eine Lösung für das Boot-Problem her. ng0 wird erst nach dem Start von pf initialisiert, also mecker ALTQ beim Boot und ein neustart von pf danach quasi erforderlich. Hilft hier echt nur, AltQ auf dem externen Interface laufen zu lassen, über das die PPPoE-Verbindung aufgebaut wird?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben