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