Hallo Liste,
seit dem Kernelupdate auf 2.2.14 funktioniert die PLIP-Verbindung zwischen Server (192.168.1.1) und Notebook (192.168.1.3) nicht mehr. Die von wechselseitigen Pings ausgelösten ICMP Echo requests erscheinen, wie ein "tcpdump -i plip0" belegt, auf dem jeweils anderen Rechner. Die PLIP-Verbindung ist danach wohl ok.
Warum werden aber die ICMP echo-requests von dem Zielrechner nicht beantwortet, wenn sie dort ankommen?
"ifconfig" auf beiden Rechnern zeigt beim plip0-Interface nur die RX-Pakete der pings an, jedoch 0 TX-Pakete.
"netstat -s" gibt nur die ICMP Messages an localhost (ping localhost) aus.
Eine Firewall ist nicht hochgezogen, die chains sind leer.
Ein "ifconfig down" der anderen Interfaces (lo, eth0) bringt keine Abhilfe.
TIA
Klaus
On Mon, Feb 21, 2000 at 11:57:36PM +0100, klaus@huener.de wrote: : Hallo Liste, : : seit dem Kernelupdate auf 2.2.14 funktioniert die PLIP-Verbindung zwischen
Was war vorher drauf?
: Server (192.168.1.1) und Notebook (192.168.1.3) nicht mehr. Die von : wechselseitigen Pings ausgelösten ICMP Echo requests erscheinen, : wie ein "tcpdump -i plip0" belegt, auf dem jeweils anderen Rechner. : Die PLIP-Verbindung ist danach wohl ok. : : Warum werden aber die ICMP echo-requests von dem Zielrechner nicht : beantwortet, wenn sie dort ankommen?
Routen stimmen auch? Also eine Network-Route fuer das an der PLIP-Verbindung haengende Netzwerk ist fuer die jeweiligen Interfaces eingetragen? (Oder ist das Iface als PTP konfiguriert. ... Bleibt trotzdem die Frage nach den eingetragenen Routen.)
Heiko
Heiko Schlittermann heiko@schlittermann.de schrieb/wrote:
: : seit dem Kernelupdate auf 2.2.14 funktioniert die PLIP-Verbindung zwischen
Was war vorher drauf?
2.2.10 auf dem Server (Update auf 2.2.14), 2.2.12 auf dem Notebook.
Habe jetzt 2.2.10 nochmal eingespielt und kompiliert. Klappt auch nicht mehr.
: Server (192.168.1.1) und Notebook (192.168.1.3) nicht mehr. Die von : wechselseitigen Pings ausgelösten ICMP Echo requests erscheinen, : wie ein "tcpdump -i plip0" belegt, auf dem jeweils anderen Rechner. : Die PLIP-Verbindung ist danach wohl ok. : : Warum werden aber die ICMP echo-requests von dem Zielrechner nicht : beantwortet, wenn sie dort ankommen?
Zwischenzeitlich ist passiert:
1. neues Kabel.
2. /proc/parport/0 geprüft auf beiden Rechnern:
serv:[0] # less /proc/parport/0/devices +plip0 serv:[0] # less /proc/parport/0/hardware base: 0x378 irq: 7 dma: none modes: SPP,ECP,ECPEPP,ECPPS2 serv:[0] # less /proc/parport/0/irq 7
Notebook dto.
Dto. kein shared Interrupt.
Dann die Adressen zu Testzwecken verändert:
serv:[/root] # ifconfig eth0 Link encap:Ethernet HWaddr 00:90:27:8F:DE:86 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:10 Base address:0x6100
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:177 errors:0 dropped:0 overruns:0 frame:0 TX packets:177 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
plip0 Link encap:Ethernet HWaddr FC:FC:C0:A8:02:01 inet addr:192.168.2.1 P-t-P:192.168.2.3 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP PROMISC MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 Interrupt:7 Base address:0x378
serv:[/root] # ping 192.168.2.3 PING 192.168.2.3 (192.168.2.3): 56 data bytes
--- 192.168.2.3 ping statistics --- 8 packets transmitted, 0 packets received, 100% packet loss
serv:[/root] # tcpdump -i plip0 tcpdump: listening on plip0 21:19:10.061888 192.168.2.1 > 192.168.2.3: icmp: echo request 21:19:10.081888 192.168.2.3 > 192.168.2.1: icmp: echo reply 21:19:11.061888 192.168.2.1 > 192.168.2.3: icmp: echo request 21:19:11.081888 192.168.2.3 > 192.168.2.1: icmp: echo reply 21:19:12.061888 192.168.2.1 > 192.168.2.3: icmp: echo request 21:19:12.081888 192.168.2.3 > 192.168.2.1: icmp: echo reply
usw.
Wie man sieht, es gibt jetzt auch replys, nur ping bemerkt sie nicht, die Verbindung im übrigen auch nicht, rsync und ftp hängen.
Aud dem Notebook dto.
Routen stimmen auch? Also eine Network-Route fuer das an der PLIP-Verbindung haengende Netzwerk ist fuer die jeweiligen Interfaces eingetragen? (Oder ist das Iface als PTP konfiguriert
ja
... Bleibt trotzdem die Frage nach den eingetragenen Routen.)
serv:[/root] # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface serv.huener.de * 255.255.255.255 UH 0 0 0 eth0 serv.huener.de * 255.255.255.255 UH 0 0 0 lo 192.168.2.3 * 255.255.255.255 UH 0 0 0 plip0 192.168.2.0 * 255.255.255.0 U 0 0 0 plip0 haus * 255.255.255.0 U 0 0 0 eth0
BTW: Warum stimmen die Netzmasken von lo bei ifconfig und route nicht überein?
Klaus
On Mon, Feb 21, 2000 at 11:57:36PM +0100, klaus@huener.de wrote: : Hallo Liste, : : seit dem Kernelupdate auf 2.2.14 funktioniert die PLIP-Verbindung zwischen : Server (192.168.1.1) und Notebook (192.168.1.3) nicht mehr. Die von : wechselseitigen Pings ausgelösten ICMP Echo requests erscheinen, : wie ein "tcpdump -i plip0" belegt, auf dem jeweils anderen Rechner. : Die PLIP-Verbindung ist danach wohl ok.
Ich hab' gerade in debian-user-de gelesen, dass in einigen neueren 2.2.x das PLIP nicht astrein ist. Vielleicht liegt's daran?
Heiko
In local.lug-dd, Heiko Schlittermann heiko@schlittermann.de schrieb/wrote:
On Mon, Feb 21, 2000 at 11:57:36PM +0100, klaus@huener.de wrote: : : seit dem Kernelupdate auf 2.2.14 funktioniert die PLIP-Verbindung zwischen : Server (192.168.1.1) und Notebook (192.168.1.3) nicht mehr. Die von : wechselseitigen Pings ausgelösten ICMP Echo requests erscheinen, : wie ein "tcpdump -i plip0" belegt, auf dem jeweils anderen Rechner. : Die PLIP-Verbindung ist danach wohl ok.
Ich hab' gerade in debian-user-de gelesen, dass in einigen neueren 2.2.x das PLIP nicht astrein ist. Vielleicht liegt's daran?
Ja, 2.2.14 ist buggy. Lösung: 2.2.15pre2 enthält den Fix.
Klaus
On Sun, Mar 12, 2000 at 10:10:43PM -0000, klaus@huener.de wrote: : In local.lug-dd, Heiko Schlittermann heiko@schlittermann.de schrieb/wrote: : >2.2.x das PLIP nicht astrein ist. Vielleicht liegt's daran? : > : Ja, 2.2.14 ist buggy. Lösung: 2.2.15pre2 enthält den Fix.
Gut, tut mir leid, dass Du so lange auf die Loesung warten musstest ;-)
Heiko
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
klaus＠huener.de