Der ISDN-Teil von SuSE 9.1 bringt mich schon langsam zum Verzweifeln. Irgendwie scheinen manche Dinge zufällig zu sein. Ich verwende: 0000:00:0c.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH A1 ISDN [Fritz] (rev 02) Mit dem AVM-Treiber (Default!) funktionierte unter dem bei 9.1 mitgelieferten Kernel das Timeout nicht, ebenso nicht nach dem 1. Kernel-Update. Zufällig merkte ich dann, dass das Timeout mit dem Hisax-Treiber funktioniert, also habe ich auf Hisax umgestellt. Nach dem 2. Kerne-Update funktionierte ISDN nicht mehr und ich sah keine andere Lösung als das Gateway neu aufzusetzen. Der Fehler im ip-up-Script ist mir bekannt, aber trotzdem war es letztlich ein zufälliges Ergebnis, dass ich wieder einen Internetverbindung schaffte. Vielleicht meinte das Schicksal, ich sollte 9.1 installieren üben :-) IMO kann man bei der Konfiguration ja nicht so viel falsch machen und ich verwende ISDN schon seit 6.1. Nun wurde direkt auf 2.6.4-54.5-default upgedatet und ich weiß nicht, woran es liegt, dass das Timeout nun mit dem Hisax-Treiber nicht funktioniert. Bitte sagt mir welche Infos ihr braucht, die poste ich dann gerne. FÜr mich ist ein funktionierendes Timeout sehr wichtig. Al
On Tue, May 11, 2004 at 11:09:46PM +0200, Al Bogner wrote:
Der ISDN-Teil von SuSE 9.1 bringt mich schon langsam zum Verzweifeln. Irgendwie scheinen manche Dinge zufällig zu sein.
Ich verwende:
0000:00:0c.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH A1 ISDN [Fritz] (rev 02)
Mit dem AVM-Treiber (Default!) funktionierte unter dem bei 9.1 mitgelieferten Kernel das Timeout nicht, ebenso nicht nach dem 1. Kernel-Update. Zufällig merkte ich dann, dass das Timeout mit dem Hisax-Treiber funktioniert, also habe ich auf Hisax umgestellt.
Nein mit Sicherheit nicht, das war Zufall.
Nach dem 2. Kerne-Update funktionierte ISDN nicht mehr und ich sah keine andere Lösung als das Gateway neu aufzusetzen. Der Fehler im ip-up-Script ist mir bekannt, aber trotzdem war es letztlich ein zufälliges Ergebnis, dass ich wieder einen Internetverbindung schaffte. Vielleicht meinte das Schicksal, ich sollte 9.1 installieren üben :-) IMO kann man bei der Konfiguration ja nicht so viel falsch machen und ich verwende ISDN schon seit 6.1.
Die mit dem ip-up script sind inzwischen alle mit YOU updates (sysconfig) gefixt (letztes Update seit gestern verfügbar). Das Hangup ist 100% unabhängig vom Hardwaretreiber und wurde ziemlich ausgiebig getestet, da es hier durch die libpcap einige Veränderungen beim activ/passiv filtern gab. Die Update Kernel unterscheiden sich diesbezüglich nicht. Da das Autotimeout stark von Firwallsettings und vom Traffik abhängig ist, kann es durchaus sein das unerwünschter Traffik es so aussehen lässt, als ob es Probleme gibt. Hier kann nur eine gründliche Analyse mit tcpdump (Namesauflösung abschalten) helfen den Schuldigen zu finden.
Nun wurde direkt auf 2.6.4-54.5-default upgedatet und ich weiß nicht, woran es liegt, dass das Timeout nun mit dem Hisax-Treiber nicht funktioniert.
Bitte sagt mir welche Infos ihr braucht, die poste ich dann gerne. FÜr mich ist ein funktionierendes Timeout sehr wichtig.
Danke auch für den Footnote Hinweis, ist weitergeleitet. -- Karsten Keil SuSE Labs ISDN development
Hallo zusammen, ich versuche einen "Eicon Server Bri PCI" unter suse 9.1 x86_64 zum laufen zu bringen. YAST hat die Karte auch korrekt erkannt und eingerichtet. Beim booten bekomme ich die Fehlermeldung: Setting up ISDN card contr0 Eicon Diva Server BRI PCIdone Loading Driver contr0FATAL: Module eicon not found. und damit hat es recht. ;-) Unter: /lib/modules/2.6.4-54.5-default/kernel/drivers/isdn/hardware/ hätte ich eigentlich die eicon Module erwartet, aber dort gibt es nur welche für AVM. Ich benutze im Moment den 2.6.4-54.5-default Kernel. Langsam glaube ich das ich der einzige bin der das Problem hat, google hat nix zu dem Problem gefunden. Vielleicht hat ja einer von euch ne Idee. Gruß Marc Bauer
Am Mittwoch, 12. Mai 2004 11:54 schrieb Karsten Keil:
On Tue, May 11, 2004 at 11:09:46PM +0200, Al Bogner wrote:
Der ISDN-Teil von SuSE 9.1 bringt mich schon langsam zum Verzweifeln. Irgendwie scheinen manche Dinge zufällig zu sein.
Ich verwende:
0000:00:0c.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH A1 ISDN [Fritz] (rev 02)
Mit dem AVM-Treiber (Default!) funktionierte unter dem bei 9.1 mitgelieferten Kernel das Timeout nicht, ebenso nicht nach dem 1. Kernel-Update. Zufällig merkte ich dann, dass das Timeout mit dem Hisax-Treiber funktioniert, also habe ich auf Hisax umgestellt.
Nein mit Sicherheit nicht, das war Zufall.
Vor ca. 1/2h habe ich erneut aktualisiert. Es gibt also nichts das zum Update vorgeschlagen wird. Was meinst du genau? Das Timeout beim AVM-Treiber sollte funktionieren? Ich glaube dir aber sofort, dass unter 9.1 einige Dinge rein zufällig passieren.
Da das Autotimeout stark von Firwallsettings und vom Traffik abhängig ist, kann es durchaus sein das unerwünschter Traffik es so aussehen lässt, als ob es Probleme gibt. Hier kann nur eine gründliche Analyse mit tcpdump (Namesauflösung abschalten) helfen den Schuldigen zu finden.
Ok. Ich kann bestätigen, dass das Timeout mittlerweile selten unter 9.1 funktioniert hat. /etc/sysconfig/network/providers/provider0 ASKPASSWORD='no' AUTODNS='no' DEMAND='yes' DSLSUPPORTED='no' ENCAP='syncppp' IDLETIME='180' ISDNSUPPORTED='yes' MODEMSUPPORTED='no' MODIFYDNS='no' Gegenüber 8.2 sollte sich von meinen Einstellungen bzw. Diensten nichts geändert haben und unter 8.2 hatte ich in der Regel innerhalb von 15 Minuten ein Timeout. Per cronjob werden alle 15 Minuten Mails abgefragt. BTW: Es läuft auch ein "forwarding bind" Mein ISP nervt mit IGMP, aber das sollte der Kernel wegfiltern. Welche tcpdump-Parameter würdest du empfehlen? Ich beobachte mit xisdnload und da sieht man auch ungefähr, ob Transfer existiert. Al
Am Mittwoch, 12. Mai 2004 11:54 schrieb Karsten Keil:
Da das Autotimeout stark von Firwallsettings und vom Traffik abhängig ist, kann es durchaus sein das unerwünschter Traffik es so aussehen lässt, als ob es Probleme gibt. Hier kann nur eine gründliche Analyse mit tcpdump (Namesauflösung abschalten) helfen den Schuldigen zu finden.
Ich habe mir das nun etwas näher angesehen, und ich könnte mir
vorstellen, dass der Kernel nicht genug filtert.
7 packets captured
107 packets received by filter
0 packets dropped by kernel
Zur Zeit:
uname -r
2.6.4-54.5-default
Ich behaupte mal, dass das Timeout nach
kernel-default-2.6.4-54.3.i586.patch.rpm mit dem Hisax-Treiber
funktionierte.
Das Timeout ist auf 180 eingestellt. Im folgenden siehst du etwas
mehr als 3 Minuten, wo ich keinen ausgehenden Traffic, der zählen
sollte, gesehen habe:
~ # tcpdump -v -i ippp0
tcpdump: listening on ippp0, link-type LINUX_SLL (Linux cooked),
capture size 96 bytes
21:49:00.675435 IP (tos 0x0, ttl 116, id 37051, offset 0, flags
[DF], length: 48) dsl-213-023-023-203.arcor-ip.net.4375 >
L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok]
2714107883:2714107883(0) win 64800
L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 1909946522:1909946522(0) win 65535
21:49:35.365299 IP (tos 0x10, ttl 64, id 1358, offset 0, flags [DF], length: 82) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 16596+% [1au] PTR? 72.198.56.81.in-addr.arpa. (54) 21:49:35.483525 IP (tos 0x0, ttl 59, id 45987, offset 0, flags [DF], length: 211) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 16596 1/2/3 72.198.56.81.in-addr.arpa. (183) 21:49:38.372136 IP (tos 0x0, ttl 115, id 39675, offset 0, flags [DF], length: 52) lns-th2-5f-81-56-198-72.adsl.proxad.net.apc-3052 L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 1909946522:1909946522(0) win 65535 21:49:44.393097 IP (tos 0x0, ttl 115, id 39944, offset 0, flags [DF], length: 52) lns-th2-5f-81-56-198-72.adsl.proxad.net.apc-3052 L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 1909946522:1909946522(0) win 65535 21:49:45.930082 IP (tos 0x0, ttl 117, id 27488, offset 0, flags [DF], length: 48) dyn-213-36-124-187.ppp.tiscali.fr.chimera-hwm > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 329305898:329305898(0) win 8760 21:49:45.936561 IP (tos 0x10, ttl 64, id 1359, offset 0, flags [DF], length: 84) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 41066+% [1au] PTR? 187.124.36.213.in-addr.arpa. (56) 21:49:46.032590 IP (tos 0x0, ttl 59, id 61786, offset 0, flags [DF], length: 269) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 41066 1/4/4 187.124.36.213.in-addr.arpa. (241) 21:49:46.419587 IP (tos 0x0, ttl 121, id 2064, offset 0, flags [none], length: 28) L0189P30.dipool.highway.telekom.at > L0694P14.dipool.highway.telekom.at: icmp 8: echo request seq 32514 21:49:46.420423 IP (tos 0x0, ttl 64, id 54501, offset 0, flags [none], length: 28) L0694P14.dipool.highway.telekom.at > L0189P30.dipool.highway.telekom.at: icmp 8: echo reply seq 32514 21:49:46.424645 IP (tos 0x10, ttl 64, id 1360, offset 0, flags [DF], length: 82) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 26677+% [1au] PTR? 158.87.46.62.in-addr.arpa. (54) 21:49:46.483314 IP (tos 0x0, ttl 59, id 62453, offset 0, flags [DF], length: 202) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 26677 1/2/3 158.87.46.62.in-addr.arpa. (174) 21:49:48.784448 IP (tos 0x0, ttl 117, id 27510, offset 0, flags [DF], length: 48) dyn-213-36-124-187.ppp.tiscali.fr.chimera-hwm > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 329305898:329305898(0) win 8760 21:49:50.358052 IP (tos 0x0, ttl 115, id 57822, offset 0, flags [DF], length: 48) d80-170-216-127.cust.tele2.fr.stun-p1 > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 678150270:678150270(0) win 65535 21:49:50.364968 IP (tos 0x10, ttl 64, id 1361, offset 0, flags [DF], length: 84) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 36628+% [1au] PTR? 127.216.170.80.in-addr.arpa. (56) 21:49:50.459038 IP (tos 0x0, ttl 59, id 2968, offset 0, flags [DF], length: 262) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 36628 1/4/3 127.216.170.80.in-addr.arpa. (234) 21:49:53.485523 IP (tos 0x0, ttl 115, id 57968, offset 0, flags [DF], length: 48) d80-170-216-127.cust.tele2.fr.stun-p1 > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 678150270:678150270(0) win 65535 21:49:55.295266 IP (tos 0x0, ttl 117, id 27568, offset 0, flags [DF], length: 48) dyn-213-36-124-187.ppp.tiscali.fr.chimera-hwm > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 329305898:329305898(0) win 8760 21:49:57.581251 IP (tos 0x0, ttl 113, id 15381, offset 0, flags [DF], length: 48) APuteaux-151-1-6-252.w82-120.abo.wanadoo.fr.net-device > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 4240292653:4240292653(0) win 16384 21:49:57.587736 IP (tos 0x10, ttl 64, id 1362, offset 0, flags [DF], length: 83) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 41864+% [1au] PTR? 252.50.120.82.in-addr.arpa. (55) 21:49:57.677622 IP (tos 0x0, ttl 59, id 13994, offset 0, flags [DF], length: 207) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 41864 1/2/3 252.50.120.82.in-addr.arpa. (179) 21:49:59.120985 IP (tos 0x0, ttl 115, id 58189, offset 0, flags [DF], length: 48) d80-170-216-127.cust.tele2.fr.stun-p1 > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 678150270:678150270(0) win 65535 21:50:00.448356 IP (tos 0x0, ttl 113, id 15565, offset 0, flags [DF], length: 48) APuteaux-151-1-6-252.w82-120.abo.wanadoo.fr.net-device > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 4240292653:4240292653(0) win 16384 21:50:03.999464 IP (tos 0x0, ttl 115, id 4240, offset 0, flags [none], length: 28) dial-62-64-142-60.access.uk.tiscali.com > L0694P14.dipool.highway.telekom.at: icmp 8: echo request seq 63496 21:50:04.000039 IP (tos 0x0, ttl 64, id 14374, offset 0, flags [none], length: 28) L0694P14.dipool.highway.telekom.at > dial-62-64-142-60.access.uk.tiscali.com: icmp 8: echo reply seq 63496 21:50:04.004190 IP (tos 0x10, ttl 64, id 1363, offset 0, flags [DF], length: 82) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 20932+% [1au] PTR? 60.142.64.62.in-addr.arpa. (54) 21:50:04.096940 IP (tos 0x0, ttl 59, id 23774, offset 0, flags [DF], length: 207) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 20932 1/2/2 60.142.64.62.in-addr.arpa. (179) 21:50:04.745196 IP (tos 0x0, ttl 116, id 10392, offset 0, flags [DF], length: 48) 62-43-57-23.user.ono.com.pxc-pin > L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 3882097601:3882097601(0) win 64240 21:50:04.751611 IP (tos 0x10, ttl 64, id 1364, offset 0, flags [DF], length: 81) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 43234+% [1au] PTR? 23.57.43.62.in-addr.arpa. (53) 21:50:04.806076 IP (tos 0x0, ttl 59, id 24818, offset 0, flags [DF], length: 175) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 43234 1/2/2 23.57.43.62.in-addr.arpa. (147) 21:50:05.807193 IP (tos 0x0, ttl 113, id 16058, offset 0, flags [DF], length: 48) APuteaux-151-1-6-252.w82-120.abo.wanadoo.fr.net-device > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 4240292653:4240292653(0) win 16384 21:50:07.682919 IP (tos 0x0, ttl 116, id 10707, offset 0, flags [DF], length: 48) 62-43-57-23.user.ono.com.pxc-pin > L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 3882097601:3882097601(0) win 64240 21:50:17.261857 IP (tos 0x0, ttl 120, id 20203, offset 0, flags [DF], length: 48) M214P020.dipool.highway.telekom.at.csvr-proxy > L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 2086931039:2086931039(0) win 8760 21:50:17.268850 IP (tos 0x10, ttl 64, id 1365, offset 0, flags [DF], length: 82) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 59938+% [1au] PTR? 180.16.46.62.in-addr.arpa. (54) 21:50:17.328342 IP (tos 0x0, ttl 59, id 43408, offset 0, flags [DF], length: 202) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 59938 1/2/3 180.16.46.62.in-addr.arpa. (174) 21:50:20.186078 IP (tos 0x0, ttl 120, id 20455, offset 0, flags [DF], length: 48) M214P020.dipool.highway.telekom.at.csvr-proxy > L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 2086931039:2086931039(0) win 8760 21:50:31.295005 IP (tos 0x0, ttl 120, id 62383, offset 0, flags [DF], length: 48) p508301A9.dip0.t-ipconnect.de.mediaspace > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 2969916495:2969916495(0) win 65535 21:50:31.302072 IP (tos 0x10, ttl 64, id 1366, offset 0, flags [DF], length: 82) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 47783+% [1au] PTR? 169.1.131.80.in-addr.arpa. (54) 21:50:31.394492 IP (tos 0x0, ttl 59, id 112, offset 0, flags [DF], length: 268) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 47783 1/4/4 169.1.131.80.in-addr.arpa. (240) 21:50:34.117234 IP (tos 0x0, ttl 120, id 62487, offset 0, flags [DF], length: 48) p508301A9.dip0.t-ipconnect.de.mediaspace > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 2969916495:2969916495(0) win 65535 21:50:40.262682 IP (tos 0x0, ttl 120, id 62719, offset 0, flags [DF], length: 48) p508301A9.dip0.t-ipconnect.de.mediaspace > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 2969916495:2969916495(0) win 65535 21:50:50.159857 IP (tos 0x0, ttl 118, id 24777, offset 0, flags [DF], length: 48) 210-71.242.81.adsl.skynet.be.iapp > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 4148253222:4148253222(0) win 16384 21:50:50.166909 IP (tos 0x10, ttl 64, id 1367, offset 0, flags [DF], length: 83) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 21358+% [1au] PTR? 210.71.242.81.in-addr.arpa. (55) 21:50:50.257355 IP (tos 0x0, ttl 59, id 30381, offset 0, flags [DF], length: 254) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 21358 1/5/3 210.71.242.81.in-addr.arpa. (226) 21:50:53.113720 IP (tos 0x0, ttl 118, id 25013, offset 0, flags [DF], length: 48) 210-71.242.81.adsl.skynet.be.iapp > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 4148253222:4148253222(0) win 16384 21:50:58.993795 IP (tos 0x0, ttl 118, id 25495, offset 0, flags [DF], length: 48) 210-71.242.81.adsl.skynet.be.iapp > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 4148253222:4148253222(0) win 16384 21:51:17.147928 IP (tos 0x0, ttl 109, id 2160, offset 0, flags [none], length: 28) adsl-43.150-DynIP.ssp.fi > L0694P14.dipool.highway.telekom.at: icmp 8: echo request seq 54271 21:51:17.148691 IP (tos 0x0, ttl 64, id 126, offset 0, flags [none], length: 28) L0694P14.dipool.highway.telekom.at > adsl-43.150-DynIP.ssp.fi: icmp 8: echo reply seq 54271 21:51:17.152967 IP (tos 0x10, ttl 64, id 1368, offset 0, flags [DF], length: 83) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 10679+% [1au] PTR? 150.43.121.62.in-addr.arpa. (55) 21:51:17.205034 IP (tos 0x0, ttl 59, id 3746, offset 0, flags [DF], length: 156) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 10679 1/2/1 150.43.121.62.in-addr.arpa. (128) 21:51:20.019901 IP (tos 0x0, ttl 114, id 28303, offset 0, flags [DF], length: 48) 62.43.146.87.idps > L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 514318224:514318224(0) win 64240 21:51:20.026230 IP (tos 0x10, ttl 64, id 1369, offset 0, flags [DF], length: 82) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 21863+% [1au] PTR? 87.146.43.62.in-addr.arpa. (54) 21:51:20.076508 IP (tos 0x0, ttl 59, id 7819, offset 0, flags [DF], length: 136) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 21863 NXDomain 0/1/1 (108) 21:51:22.736381 IP (tos 0x0, ttl 114, id 28551, offset 0, flags [DF], length: 48) 62.43.146.87.idps > L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 514318224:514318224(0) win 64240 21:51:33.216045 IP (tos 0x0, ttl 51, id 25444, offset 0, flags [DF], length: 60) host135-59.pool62211.interbusiness.it.26593 > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 3456956673:3456956673(0) win 32768 21:51:33.223331 IP (tos 0x10, ttl 64, id 1370, offset 0, flags [DF], length: 83) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 6897+% [1au] PTR? 135.59.211.62.in-addr.arpa. (55) 21:51:33.310412 IP (tos 0x0, ttl 59, id 27511, offset 0, flags [DF], length: 215) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 6897 1/3/2 135.59.211.62.in-addr.arpa. (187) 21:51:36.210024 IP (tos 0x0, ttl 51, id 25656, offset 0, flags [DF], length: 60) host135-59.pool62211.interbusiness.it.26593 > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 3456956673:3456956673(0) win 32768 21:51:39.213258 IP (tos 0x0, ttl 51, id 25759, offset 0, flags [DF], length: 44) host135-59.pool62211.interbusiness.it.26593 > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 3456956673:3456956673(0) win 32768 21:51:42.215486 IP (tos 0x0, ttl 51, id 25867, offset 0, flags [DF], length: 44) host135-59.pool62211.interbusiness.it.26593 > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 3456956673:3456956673(0) win 32768 21:51:45.240213 IP (tos 0x0, ttl 51, id 25992, offset 0, flags [DF], length: 44) host135-59.pool62211.interbusiness.it.26593 > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 3456956673:3456956673(0) win 32768 21:51:47.012204 IP (tos 0x0, ttl 121, id 35676, offset 0, flags [DF], length: 48) M509P016.dipool.highway.telekom.at.omnilink-port L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 3686508231:3686508231(0) win 8760 21:51:47.019301 IP (tos 0x10, ttl 64, id 1371, offset 0, flags [DF], length: 82) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 10952+% [1au] PTR? 144.53.46.62.in-addr.arpa. (54) 21:51:47.076434 IP (tos 0x0, ttl 59, id 48716, offset 0, flags [DF], length: 202) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 10952 1/2/3 144.53.46.62.in-addr.arpa. (174) 21:51:49.010184 IP (tos 0x0, ttl 114, id 63845, offset 0, flags [DF], length: 48) 82.102.47.249.trellisagt > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 4148469059:4148469059(0) win 64240 21:51:49.016857 IP (tos 0x10, ttl 64, id 1372, offset 0, flags [DF], length: 83) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 2815+% [1au] PTR? 249.47.102.82.in-addr.arpa. (55) 21:51:49.093294 IP (tos 0x0, ttl 59, id 51748, offset 0, flags [DF], length: 137) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 2815 NXDomain 0/1/1 (109) 21:51:49.421580 IP (tos 0x0, ttl 123, id 26928, offset 0, flags [none], length: 28) L0920P16.dipool.highway.telekom.at > L0694P14.dipool.highway.telekom.at: icmp 8: echo request seq 10557 21:51:49.422753 IP (tos 0x0, ttl 64, id 45839, offset 0, flags [none], length: 28) L0694P14.dipool.highway.telekom.at > L0920P16.dipool.highway.telekom.at: icmp 8: echo reply seq 10557 21:51:49.425421 IP (tos 0x10, ttl 64, id 1373, offset 0, flags [DF], length: 83) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 3872+% [1au] PTR? 240.178.46.62.in-addr.arpa. (55) 21:51:49.485557 IP (tos 0x0, ttl 59, id 52320, offset 0, flags [DF], length: 203) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 3872 1/2/3 240.178.46.62.in-addr.arpa. (175) 21:51:50.185437 IP (tos 0x0, ttl 121, id 35967, offset 0, flags [DF], length: 48) M509P016.dipool.highway.telekom.at.omnilink-port L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 3686508231:3686508231(0) win 8760 21:51:51.202664 IP (tos 0x0, ttl 51, id 26284, offset 0, flags [DF], length: 44) host135-59.pool62211.interbusiness.it.26593 > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 3456956673:3456956673(0) win 32768 21:51:51.883415 IP (tos 0x0, ttl 114, id 64021, offset 0, flags [DF], length: 48) 82.102.47.249.trellisagt > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 4148469059:4148469059(0) win 64240 21:51:57.896114 IP (tos 0x0, ttl 114, id 64351, offset 0, flags [DF], length: 48) 82.102.47.249.trellisagt > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 4148469059:4148469059(0) win 64240 21:52:02.016475 IP (tos 0x0, ttl 121, id 52416, offset 0, flags [DF], length: 48) L1138P29.dipool.highway.telekom.at.sitewatch > L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 954612845:954612845(0) win 8760 21:52:02.022675 IP (tos 0x10, ttl 64, id 1374, offset 0, flags [DF], length: 82) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 33712+% [1au] PTR? 61.206.46.62.in-addr.arpa. (54) 21:52:02.082325 IP (tos 0x0, ttl 59, id 5261, offset 0, flags [DF], length: 202) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 33712 1/2/3 61.206.46.62.in-addr.arpa. (174) 21:52:03.206321 IP (tos 0x0, ttl 51, id 26765, offset 0, flags [DF], length: 44) host135-59.pool62211.interbusiness.it.26593 > L0694P14.dipool.highway.telekom.at.4662: S [tcp sum ok] 3456956673:3456956673(0) win 32768 21:52:04.982204 IP (tos 0x0, ttl 121, id 52659, offset 0, flags [DF], length: 48) L1138P29.dipool.highway.telekom.at.sitewatch > L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 954612845:954612845(0) win 8760 21:52:06.015441 IP (tos 0x0, ttl 122, id 12907, offset 0, flags [DF], length: 48) L0116P24.dipool.highway.telekom.at.4405 > L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 2073563815:2073563815(0) win 8760 21:52:06.022179 IP (tos 0x10, ttl 64, id 1375, offset 0, flags [DF], length: 82) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 57505+% [1au] PTR? 120.78.46.62.in-addr.arpa. (54) 21:52:06.081294 IP (tos 0x0, ttl 59, id 11417, offset 0, flags [DF], length: 202) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 57505 1/2/3 120.78.46.62.in-addr.arpa. (174) 21:52:07.819930 IP (tos 0x0, ttl 122, id 13322, offset 0, flags [DF], length: 48) L0116P24.dipool.highway.telekom.at.4405 > L0694P14.dipool.highway.telekom.at.epmap: S [tcp sum ok] 2073563815:2073563815(0) win 8760 21:52:30.514645 IP (tos 0x0, ttl 113, id 64916, offset 0, flags [none], length: 28) 138.231.62.62.9nanterr1-0-ro-bas-1.9tel.net > L0694P14.dipool.highway.telekom.at: icmp 8: echo request seq 21128 21:52:30.515526 IP (tos 0x0, ttl 64, id 28301, offset 0, flags [none], length: 28) L0694P14.dipool.highway.telekom.at > 138.231.62.62.9nanterr1-0-ro-bas-1.9tel.net: icmp 8: echo reply seq 21128 21:52:30.519766 IP (tos 0x10, ttl 64, id 1376, offset 0, flags [DF], length: 83) L0694P14.dipool.highway.telekom.at.1024 > WS01IS01.highway.telekom.at.domain: 597+% [1au] PTR? 138.231.62.62.in-addr.arpa. (55) 21:52:30.605995 IP (tos 0x0, ttl 59, id 48443, offset 0, flags [DF], length: 208) WS01IS01.highway.telekom.at.domain > L0694P14.dipool.highway.telekom.at.1024: 597 1/2/3 138.231.62.62.in-addr.arpa. (180) 21:52:30.918003 IP (tos 0x0, ttl 113, id 64956, offset 0, flags [DF], length: 48) 138.231.62.62.9nanterr1-0-ro-bas-1.9tel.net.4971 L0694P14.dipool.highway.telekom.at.microsoft-ds: S [tcp sum ok] 1624696491:1624696491(0) win 65535 21:52:33.690358 IP (tos 0x0, ttl 113, id 65469, offset 0, flags [DF], length: 48) 138.231.62.62.9nanterr1-0-ro-bas-1.9tel.net.4971 L0694P14.dipool.highway.telekom.at.microsoft-ds: S [tcp sum ok] 1624696491:1624696491(0) win 65535
107 packets captured 107 packets received by filter 0 packets dropped by kernel
On Thu, May 13, 2004 at 10:01:08PM +0200, Al Bogner wrote:
Am Mittwoch, 12. Mai 2004 11:54 schrieb Karsten Keil:
Da das Autotimeout stark von Firwallsettings und vom Traffik abhängig ist, kann es durchaus sein das unerwünschter Traffik es so aussehen lässt, als ob es Probleme gibt. Hier kann nur eine gründliche Analyse mit tcpdump (Namesauflösung abschalten) helfen den Schuldigen zu finden.
Ich habe mir das nun etwas näher angesehen, und ich könnte mir vorstellen, dass der Kernel nicht genug filtert.
Der kernel filtert ja auch nichts, das soll er ja auch nicht machen. Nur sollen bestimmte Pakete nicht den IDLE counter resetten, dummerweise kann man das nicht ohne zusaaetlichen debug code im kernel sichtbar machen. Die Filterregel steht im /etc/ppp/ioption file, die Synax entspricht tcpdump.
7 packets captured 107 packets received by filter 0 packets dropped by kernel
Zur Zeit: uname -r 2.6.4-54.5-default
Ich behaupte mal, dass das Timeout nach kernel-default-2.6.4-54.3.i586.patch.rpm mit dem Hisax-Treiber funktionierte.
Das Timeout ist auf 180 eingestellt. Im folgenden siehst du etwas mehr als 3 Minuten, wo ich keinen ausgehenden Traffic, der zählen sollte, gesehen habe:
Doch DNS Anfragen.
~ # tcpdump -v -i ippp0
Das erzeugt schon selbst traffic (DNS Aufloesung). -n ist notwendig, Theoretisch sollte: tcpdump -v -n -i ippp0 'outbound and not icmp[0] == 3 and not tcp[13] & 4 != 0' Dir genau die schuldigen Pakete anzeigen. -- Karsten Keil SuSE Labs ISDN development
Am Donnerstag, 13. Mai 2004 23:14 schrieb Karsten Keil:
On Thu, May 13, 2004 at 10:01:08PM +0200, Al Bogner wrote:
Am Mittwoch, 12. Mai 2004 11:54 schrieb Karsten Keil:
Da das Autotimeout stark von Firwallsettings und vom Traffik abhängig ist, kann es durchaus sein das unerwünschter Traffik es so aussehen lässt, als ob es Probleme gibt. Hier kann nur eine gründliche Analyse mit tcpdump (Namesauflösung abschalten) helfen den Schuldigen zu finden.
Ich habe mir das nun etwas näher angesehen, und ich könnte mir vorstellen, dass der Kernel nicht genug filtert.
Der kernel filtert ja auch nichts, das soll er ja auch nicht machen. Nur sollen bestimmte Pakete nicht den IDLE counter resetten, dummerweise kann man das nicht ohne zusaaetlichen debug code im kernel sichtbar machen.
Du hast recht, ich meinte, dass vielleicht der Code zur Kerneloption CONFIG_IPPP_FILTER geändert wurde und das Verhalten nun deswegen ein anderes ist.
Die Filterregel steht im /etc/ppp/ioption file, die Synax entspricht tcpdump.
7 packets captured 107 packets received by filter 0 packets dropped by kernel
Zur Zeit: uname -r 2.6.4-54.5-default
Ich behaupte mal, dass das Timeout nach kernel-default-2.6.4-54.3.i586.patch.rpm mit dem Hisax-Treiber funktionierte.
Das Timeout ist auf 180 eingestellt. Im folgenden siehst du etwas mehr als 3 Minuten, wo ich keinen ausgehenden Traffic, der zählen sollte, gesehen habe:
Doch DNS Anfragen.
Die gab es unter 8.2 aber auch schon und da merkte ich die Disconnects deutlich. Kann man diese automatischen DNS.-Abfragen filtern?
Theoretisch sollte: tcpdump -v -n -i ippp0 'outbound and not icmp[0] == 3 and not tcp[13] & 4 != 0'
Dir genau die schuldigen Pakete anzeigen.
Leider "sollte". 3 Minuten vergehen, tcpdump gibt nichts aus und der Disconnect passiert nicht. Allerdings habe ich manchmal Disconnects. Al
On Fri, May 14, 2004 at 04:59:21PM +0200, Al Bogner wrote:
Am Donnerstag, 13. Mai 2004 23:14 schrieb Karsten Keil:
On Thu, May 13, 2004 at 10:01:08PM +0200, Al Bogner wrote:
Am Mittwoch, 12. Mai 2004 11:54 schrieb Karsten Keil:
Da das Autotimeout stark von Firwallsettings und vom Traffik abhängig ist, kann es durchaus sein das unerwünschter Traffik es so aussehen lässt, als ob es Probleme gibt. Hier kann nur eine gründliche Analyse mit tcpdump (Namesauflösung abschalten) helfen den Schuldigen zu finden.
Ich habe mir das nun etwas näher angesehen, und ich könnte mir vorstellen, dass der Kernel nicht genug filtert.
Der kernel filtert ja auch nichts, das soll er ja auch nicht machen. Nur sollen bestimmte Pakete nicht den IDLE counter resetten, dummerweise kann man das nicht ohne zusaaetlichen debug code im kernel sichtbar machen.
Du hast recht, ich meinte, dass vielleicht der Code zur Kerneloption CONFIG_IPPP_FILTER geändert wurde und das Verhalten nun deswegen ein anderes ist.
Die Filterregel steht im /etc/ppp/ioption file, die Synax entspricht tcpdump.
7 packets captured 107 packets received by filter 0 packets dropped by kernel
Zur Zeit: uname -r 2.6.4-54.5-default
Ich behaupte mal, dass das Timeout nach kernel-default-2.6.4-54.3.i586.patch.rpm mit dem Hisax-Treiber funktionierte.
Das Timeout ist auf 180 eingestellt. Im folgenden siehst du etwas mehr als 3 Minuten, wo ich keinen ausgehenden Traffic, der zählen sollte, gesehen habe:
Doch DNS Anfragen.
Die gab es unter 8.2 aber auch schon und da merkte ich die Disconnects deutlich. Kann man diese automatischen DNS.-Abfragen filtern?
Nein die DNS Anfragen kamen nur durch tcpdump selbst (ohne -n versucht er bei jedem Paket die adresse aufzulösen, wenn sie nicht schon im Cache ist).
Theoretisch sollte: tcpdump -v -n -i ippp0 'outbound and not icmp[0] == 3 and not tcp[13] & 4 != 0'
Dir genau die schuldigen Pakete anzeigen.
Leider "sollte". 3 Minuten vergehen, tcpdump gibt nichts aus und der Disconnect passiert nicht. Allerdings habe ich manchmal Disconnects.
Das habe ich schon fast vermutet, alle Pakete werden wahrscheinlich von tcpdump als inbound erkannt und damit nicht angezeigt. probier mal folgende Regel: 'src host 1.1.1.1 and not icmp[0] == 3 and not tcp[13] & 4 != 0' 1.1.1.1 durch Deine IP Adresse am ippp0 ersetzen. Diese Regel ist unabhängig vom (In/Out Flag, das nur für die ativ/passiv filter gesetzt werden kann, aber nicht für die abgehörten Pakete bei TCP dump. -- Karsten Keil SuSE Labs ISDN development
On Thu, May 13, 2004 at 06:35:55PM +0200, Marc Bauer wrote:
Hallo zusammen, ich versuche einen "Eicon Server Bri PCI" unter suse 9.1 x86_64 zum laufen zu bringen. YAST hat die Karte auch korrekt erkannt und eingerichtet. Beim booten bekomme ich die Fehlermeldung:
Setting up ISDN card contr0 Eicon Diva Server BRI PCIdone Loading Driver contr0FATAL: Module eicon not found.
und damit hat es recht. ;-)
Unter: /lib/modules/2.6.4-54.5-default/kernel/drivers/isdn/hardware/ hätte ich eigentlich die eicon Module erwartet, aber dort gibt es nur welche für AVM.
Ich benutze im Moment den 2.6.4-54.5-default Kernel.
Langsam glaube ich das ich der einzige bin der das Problem hat, google hat nix zu dem Problem gefunden.
Soviele x86_64 Nutzer gibt es noch nicht. Der EICON driver ist lt. Author noch nicht 64 bit clean und deshalb für diese Architektur disabled, wie viele andere Treiber auch. -- Karsten Keil SuSE Labs ISDN development
Hallo, seit einiger Zeit funktioniert das IDLE-Timeout für meine ISDN Verbindung nicht mehr (Suse 8.0 mit Fritzcard-Classic) Da in /var/log/firewall nahezu pausenlos (während eine ISDN-Verbindung besteht) Einträge in der Form: SuSE-FW-DROP-DEFAULT IN=ippp0 OUT= MAC= SRC=213.225.76.102 DST=213.168.73.166 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=2049 DF PROTO=TCP SPT=2737 DPT=445 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B401010402) auftauchen, nehme ich an, daß irgendjemand/etwas von außerhalb versucht auf meinen Rechner zuzugreifen und damit das Timeout aushebelt. Liege ich damit richtig, was kann man dagegen tun? Gruß Joachim
participants (4)
-
Al Bogner -
Joachim Weber -
Karsten Keil -
Marc Bauer