Häufige Verbindungsabbrüche - fehlerhafte ppp.conf?

[Heidegger]

Hallo! Bei großen Downloads über mehrere hundert MByte bricht unter ISDN meine Verbindung jedesmal nach 30 - 60 Minuten ab. Ich konnte bisher keinerlei aufschlussreiche Fehlermeldungen in der ppp.log entdecken, verdächtige aber dennoch eine falsch konfigurierte ppp.conf:

default:
 set cd 180
 set device /dev/i4brbch0
 set proctitle ppp-isdn

citykom:
 set phone "110"
 set authname "benutzername"
 set authkey "benutzerpassswort"
 set ctsrts off
 nat enable yes
 nat log yes
 nat same_ports yes
 nat use_sockets yes
 nat unregistered_only yes
 enable dns
 enable lqr
 enable dns
 set enddisc mac
 set mrru 1500
 set mru 1504
 set dial
 set login
 set logout
 set hangup
 set speed sync
 set timeout 0
 set redial 0 0
 set ifaddr 172.16.0.1/0 212.0.0.0/0 0 0
 add default HISADDR

Ich bin mir nicht sicher, ob meine Eintragungen in der vorliegenden Form überhaupt sinnvoll sind - ppp ist ein umfangreiches und schwieriges Thema und verlangt zu seinem Verstndnis eine längerfristige Vertiefung in die betreffende Thematik. Mit der Option enable/disable lqr habe ich übrigens schon herumgespielt, ohne daß eine Optimierung deutlich geworden wäre. Vielleicht liegst es auch an der isdnd.rc oder an meiner pf.conf (kann ich natürlich auch posten, wenn gewünscht). Wäre für einen Hinweis dankbar.

 

[Heidegger]

Noch etwas ist äußerst merkwürdig: Wenn die Verbindung nach spätestens einer Stunde abgebrochen ist (Abbruch geschieht nicht plötzlich, sondern über mehere Minuten schleichend, mit zunehmd geringerem Datendurchsatz), ist eine Einwahl erst wieder nach einem Reboot von FreeBSD möglich! Wenn ich einen Host im Internet anpingen will, kommt die Meldung: no route to host, cannot resolve www.adresse.de. In /etc/rc.conf steht named="YES", bind läuft als caching nameserver - kann man auch ohne bind eine Namensauflösung über LAN erhalten?

 

[0815Chaot]

Was dein ISDN-Problem angeht: Da vermag ich dir nicht weiterzuhelfen, da ich mich damit nur sporadisch bei ein oder zwei Installationen beschäftigen muß. Ansonsten habe ich nur mit Analog- oder DSL-Anschlüssen zu tun.

Original geschrieben von Heidegger
kann man auch ohne bind eine Namensauflösung über LAN erhalten?

Ja, mit dns/dnsmasq. Du läßt den dnsmasq auf dem Einwahlrechner laufen. Der versucht dann Namensanfragen zunächst aus der /etc/hosts des Rechners zu ermitteln. Wenn er dort nicht fündig wird, wendet er sich an einen Nameserver aus /etc/resolv.conf. Durch "enable dns" läßt du den PPP dafür sorgen, daß dort immer die aktuellen Nameserver deines Providers drin stehen.

Dann mußt du in der /etc/resolv.conf der anderen Rechner im LAN nur noch den Einwahlrechner als Nameserver reinschreiben, schon hast du Namensauflösung für interne und externe Adressen erledigt.

Der dnsmasq ist auch ziemlich simpel zu konfigurieren:

/usr/local/sbin/dnsmasq --listen-adress=$Interne_IP_des_Rechners --user=nobody

Fertig, eine Konfigurationsdatei wird nicht benötigt.

 

[Heidegger]

Yupp, dnsmasq kenne ich, ich dachte mir nur, ich nehme named, der ist out-of-the-box schon gleich in die Standardinstallation integriert und funktioniert auf Anhieb. Hier noch mal meine pf.conf: (man sieht, sie trägt die Handschrift eines Anfängers)

loop="lo0"
ext_if="tun0"
int_if_1="xl0"
int_if_2="rl0"
internal_net="192.168.0.0/22"
table <p2p> persist file "/etc/firewall/p2p.conf"
set loginterface $ext_if
set optimization aggressive
set block-policy drop
set require-order yes
scrub in all
scrub out all random-id
nat on $ext_if from $internal_net to any -> ($ext_if)
block log all
antispoof for { $loop, $ext_if, $int_if_1, $int_if_2 }
pass quick on $loop all
pass quick on $int_if_1 all
pass quick on $int_if_2 all
pass on $ext_if proto { tcp udp icmp } all keep state
block in log on $ext_if inet proto icmp icmp-type 8
block in log on $ext_if from <p2p> to $internal_net
block out on $ext_if from $internal_net to <p2p>

Wie gesagt, die Downloads verlangsamen sich mit der Zeit stetig, bis irgendwann nach ca. 1 Stunde überhaupt kein Onlinezugang mehr möglich ist.

 

[0815Chaot]

Original geschrieben von Heidegger
Yupp, dnsmasq kenne ich, ich dachte mir nur, ich nehme named, der ist out-of-the-box schon gleich in die Standardinstallation integriert und funktioniert auf Anhieb.

Ähm, irgendwie verstehe ich dann deine Frage nicht. Zum einen möchtest du eine Alternative zu BIND, andererseits benutzt du BIND aber, weil es in der Standardinstallation vorhanden ist. Mir ist jedenfalls kein anderer Nameserver bekannt, der zum Basis-System unter FreeBSD gehört, wenn dies deine Frage war.

Was das "auf Anhieb funktionieren" angeht:
pkg_add -r dnsmasq && dnsmasq --listen-adress ... [Rest siehe oben]

Wie gesagt, die Downloads verlangsamen sich mit der Zeit stetig, bis irgendwann nach ca. 1 Stunde überhaupt kein Onlinezugang mehr möglich ist.

Ich denke eigentlich nicht, daß es am Paketfilter liegt. Oder hast du so was wie Traffic-Accounting aktiviert?

Naja, man könnte mal ein paar Systemparameter während eines größeren Downloads beobachten, z.B. mit "top" und "netstat -m". Vielleicht gehen die mbufs aus? Also jedenfalls so irgendwas, überwach einfach mal alles, was dir in den Sinn kommt. Guck mal, was sich während des Downloads verändert, insbesondere zu dem Zeitpunkt, wenn die Leitung plötzlich tot ist.

So ins Blaue reinraten dürfte schwierig werden.

 

[Heidegger]

Traffic-Accounting habe ich natürlich nicht aktiviert, und mbuf - hm, das muss irgendetwas mit dem Memorymanagement im Kernel IPC Subsystem zu tun haben, damit kenne ich mich jedoch kaum aus. Habe gerade seit 50 Minuten einen FTP-Download laufen, in spätestens einer halben Stunde wird er wieder abbrechen (obwohl er nach der Dateigröße mit ISDN noch mindestens 20 Stunden lang laufen müsste), hier einmal der Status mit netstat -m:

mbuf usage:
	GEN cache:	1/480 (in use/in pool)
	CPU #0 cache:	129/512 (in use/in pool)
	Total:		130/992 (in use/in pool)
	Mbuf cache high watermark: 512
	Maximum possible: 13952
	Allocated mbuf types:
	  130 mbufs allocated to data
	7% of mbuf map consumed
mbuf cluster usage:
	GEN cache:	0/232 (in use/in pool)
	CPU #0 cache:	129/184 (in use/in pool)
	Total:		129/416 (in use/in pool)
	Cluster cache high watermark: 128
	Maximum possible: 6976
	5% of cluster map consumed
1080 KBytes of wired memory reserved (26% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

Kannst du irgendwelche AUffälligkeiten ausmachen?

 

[Heidegger]

Ich habe jetzt TCP_DROP_SYNFIN aus dem Kernel und aus der /etc/rc.conf herausgenommen, und siehe da, die Downloads laufen durch, Problem gelöst! Offensichtlich lässt sich also auf meinem Rechner mit der vorliegenden, spezifischen Konfiguration OpenBSD'S Paketfilter pf-2.03 nicht zusammen mit TCP_DROP_SYNFIN betreiben. Die Schlussfolgerung, daß dies grundsätzlich für alle Rechner zutrifft, ist jedoch reine Mutmaßung. Pf ist z. Zt. noch weit weniger integraler Bestandteil des Basissystems von FreeBSD als z. B. ipfw2, ipfilter und natd, folglich können zusammen mit bestimmten Kernelkonfigurationen und config files Unregelmäßigkeiten in der Zusammenarbeit mit pf entstehen.

 

[Heidegger]

Die Paketfilterregeln habe ich nun auch noch so erweitert, daß einer meiner Rechner aus dem LAN eine High ID auf dem BitTorrent-Client erreicht:

loop="lo0"
ext_if="tun0"
int_if_1="xl0"
int_if_2="rl0"
all_if="{" $int_if_1 $int_if_2 "}"
total_if="{" $loop $ext_if $int_if_1 $int_if_2 "}"
internal_net="192.168.0.0/22"
pingunix="192.168.1.1"
bittorrent="6881:6882"
table <p2p> persist file "/etc/firewall/tables/p2p.conf"
table <rfc1918> persist file "/etc/firewall/tables/rfc1918.conf"
set loginterface $ext_if
set optimization aggressive
set block-policy drop
set require-order yes
scrub in all
scrub out all random-id
nat on $ext_if from $internal_net to any -> ($ext_if)
rdr on $ext_if proto tcp from any to any port $bittorrent -> $pingunix
block log all
pass quick on $loop all
antispoof for $total_if
pass quick on $all_if all keep state
pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp icmp } all keep state
pass in on $ext_if proto { tcp udp icmp } all keep state
block out log on $ext_if from $internal_net to <p2p>
block out log on $ext_if from $internal_net to <rfc1918>
block in log on $ext_if inet proto icmp icmp-type echoreq

Die bösen Buben bleiben über die <p2p>-table draußen.