proxyarp bei pppd, offene Dateien mit ipppd
Ich habe eine Einwahl mit pppd über /dev/ttyI0 konfiguriert, die auch prinzipiell funktioniert. Zur Anbindung an das lokale Netzwerk ist die Option "proxyarp" gesetzt. Die Version ist Suse-Linux 8.1. uname -a bringt Linux fw2 2.4.21-251-default #1 Thu Sep 23 20:52:18 UTC 2004 i686 unknown Updates sind eingespielt. Dem sich einwählenden Rechner wurde hier die Adresse 192.168.76.70 gegeben. Solange die Verbindung besteht, ist diese Adresse auch in der arp-Tabelle zu sehen. Wenn die Verbindung abgebaut ist, verschwindet der arp-Eintrag nicht wieder, sondern er verändert sich, indem aus der 192 eine 191 wird: fw2:~ # arp -n Address HWtype HWaddress Flags Mask Iface 192.168.76.2 ether 08:00:09:FE:0D:F7 C eth1 192.168.76.1 ether 08:00:09:C2:95:22 C eth1 191.168.76.70 * * MP eth1 fw2:~ # Mit der Zeit füllt sich die arp-Tabelle dann mit diesen Einträgen, bis irgendwann nichts mehr geht. Im Internet fand ich das Problem für BSD-Unix beschrieben. Ein ähnliches Problem zeigt der ipppd auf demselben Rechner. Die Verbindung ist dort als "dial on demand" konfiguriert. Bei jedem Verbindungsabbau bleibt eine offene Datei übrig. lsof zeigt dann Einträge der Art: pppd 668 root 3u sock 0,0 1987 can't identify protocol Dieses Problem ist, glaube ich, hier schon einmal beschrieben worden. Ein Lösung gab es damals nicht, sondern nur einen "Workaround" in der Art, daß man den Rechner wie einen NT-Server täglich bootet. Auch das arp-Problem könnte man so umgehen. Ich bin mir nicht ganz sicher, ob ich mit diesem Problem auf dieser Liste ganz richtig bin, aber da der Verbindungsauf- und -abbau über ISDN erfolgt, versuche ich es erst einmal hier. Jochen
Wenn schon niemand einen Beitrag zu diesem Problem hatte, so will ich doch wenigstens mitteilen, was ich weiter herausgefunden habe, damit nicht nur Fragen im Internet bzw. Mailinglistenarchiv stehen. Ich habe mir die Quellen von pppd 2.4.3 besorgt und compiliert. Das ging problemlos, und das Ergebnis vertrug sich auch mit Version 8.1 von Suse-Linux. Allein das Problem, daß die arp-Einträge nicht ge- löscht wurden, bestand weiterhin. So habe ich Tests mit dem arp-Programm gemacht. Dabei mußte ich fest- stellen, daß sich Einträge, die mit dem Flag "pub" erzeugt wurden, nicht wieder löschen ließen. Demnach scheint es also ein Kernel- Problem zu sein, vielleicht eines speziell des Suse-Kernels, aber jedenfalls keines, das mit pppd oder gar ISDN zusammenhängt. (Für das ebenfalls erwähnte Problem mit den offenen Dateien gilt diese Aussage natürlich nicht. Dort habe ich nach wie vor keine Vorstellung, wo die Ursache liegt.) Jochen Jochen Roedenbeck schrieb:
Ich habe eine Einwahl mit pppd über /dev/ttyI0 konfiguriert, die auch prinzipiell funktioniert. Zur Anbindung an das lokale Netzwerk ist die Option "proxyarp" gesetzt. Die Version ist Suse-Linux 8.1. uname -a bringt
Linux fw2 2.4.21-251-default #1 Thu Sep 23 20:52:18 UTC 2004 i686 unknown
Updates sind eingespielt.
Dem sich einwählenden Rechner wurde hier die Adresse 192.168.76.70 gegeben. Solange die Verbindung besteht, ist diese Adresse auch in der arp-Tabelle zu sehen.
Wenn die Verbindung abgebaut ist, verschwindet der arp-Eintrag nicht wieder, sondern er verändert sich, indem aus der 192 eine 191 wird:
fw2:~ # arp -n Address HWtype HWaddress Flags Mask Iface 192.168.76.2 ether 08:00:09:FE:0D:F7 C eth1 192.168.76.1 ether 08:00:09:C2:95:22 C eth1 191.168.76.70 * * MP eth1 fw2:~ #
Mit der Zeit füllt sich die arp-Tabelle dann mit diesen Einträgen, bis irgendwann nichts mehr geht.
Im Internet fand ich das Problem für BSD-Unix beschrieben.
Ein ähnliches Problem zeigt der ipppd auf demselben Rechner. Die Verbindung ist dort als "dial on demand" konfiguriert. Bei jedem Verbindungsabbau bleibt eine offene Datei übrig. lsof zeigt dann Einträge der Art:
pppd 668 root 3u sock 0,0 1987 can't identify protocol
Dieses Problem ist, glaube ich, hier schon einmal beschrieben worden. Ein Lösung gab es damals nicht, sondern nur einen "Workaround" in der Art, daß man den Rechner wie einen NT-Server täglich bootet. Auch das arp-Problem könnte man so umgehen.
Ich bin mir nicht ganz sicher, ob ich mit diesem Problem auf dieser Liste ganz richtig bin, aber da der Verbindungsauf- und -abbau über ISDN erfolgt, versuche ich es erst einmal hier.
Jochen
-- SPL Spindel und Präzisionslager GmbH Feldstraße 5, D-04720 Döbeln Telefon: +49 3431 610200 Fax: +49 3431 610205 Internet: http://www.spl-spindel.de
participants (1)
-
Jochen Roedenbeck