Unerklaerliche Uebertragungen ins Internet - igmp query
Ich würde gerne die automatische Trennung bei keinem Traffic nach x
Minuten bei einer ISDN-Anbindung ins Internet verwenden.
Vermutlich funktioniert das deshalb nicht, weil da alle Augenblicke
irgendwas los ist, das nicht durch einen User ausgelöst wird.
ippp0 Link encap:Point-to-Point Protocol
inet addr:62.46.150.4 P-t-P:195.3.93.69
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP DYNAMIC MTU:1500 Metric:1
RX packets:1041 errors:0 dropped:0 overruns:0 frame:0
TX packets:978 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:609625 (595.3 Kb) TX bytes:54687 (53.4 Kb)
tcpdump -i ippp0
tcpdump: listening on ippp0
14:18:50.133064 195.3.93.69 > 224.0.0.1: igmp query v2 [ttl 1]
14:19:21.691980 63.200.144.2 > 62.46.150.4: icmp: echo request
14:19:21.692103 62.46.150.4 > 63.200.144.2: icmp: echo reply
14:19:22.649780 63.200.144.2.4772 > 62.46.150.4.http: S
1805706699:1805706699(0) win 8192
*** Al Bogner (suse-linux@pinguin.uni.cc) schrieb heute in suse-linux:
Ich würde gerne die automatische Trennung bei keinem Traffic nach x Minuten bei einer ISDN-Anbindung ins Internet verwenden.
Vermutlich funktioniert das deshalb nicht, weil da alle Augenblicke irgendwas los ist, das nicht durch einen User ausgelöst wird.
Vieleicht doch. Aber es kommt nicht von _Deiner_ Maschine. Einiges dürften "secvul-scanner" sein und ...
Wodurch erfolgt "igmp query"?
... das ein eventuell nachlässig konfigurierter Router Deines Providers (in Östereich?). IGMP ist das "Internet Group Management Protocol", dass sich mit multicast group member management beschäftigt. Da ich annehme, dass Du keinen IGMP-Client (also eine Anwendung, die sich als IGMP- Member registriert) gestartet hast, sollte das eigentlich nicht passieren. Wenn Dein Vorgänger auf dieser IP das allerdings getan hat... MfG Henning Hucke -- Thema: Selbsthilfegruppe Linux für Nicht-Informatiker "In der ersten Sitzung wird besprochen: 'Hilfe, ich habe ein Handbuch gelesen, statt Informatik zu studieren ... und... ICH KAM ZURECHT MIT LINUX'." -- Susanne Schmidt in de.comp.os.linux.misc
On Wednesday 25 June 2003 16:02, Henning Hucke wrote:
Einiges dürften "secvul-scanner" sein und ...
Was ist denn das? Google ist diesbzgl. nicht sehr gesprächig.
Wodurch erfolgt "igmp query"?
... das ein eventuell nachlässig konfigurierter Router Deines Providers (in Östereich?).
Mein ISP ist aon.at und in at.linux habe ich einige Postings dazu gefunden, sowie auch uralte Scripts mit denen man das abstellen könnte. Ich habe nur keine Ahnung, ob man das aktuell verwenden kann. Auf Wunsch poste ich das. Würde das etwas bzgl. automat. Disconnect bringen? # reject IGMP iptables -A INPUT -p igmp -j REJECT iptables -A OUTPUT -p igmp -j REJECT iptables -A FORWARD -p igmp -j REJECT Interessant ist aber, dass das automatische Disconnect schon mal unter 8.2 funktioniert hat. Aon hatte aber in letzter Zeit eine Änderung und vielleicht hängt es damit zusammen. Kann es etwas mit meinem grsec-Kernel zu tun haben? Ich finde hier: /usr/src/linux-2.4.21-rc7-grsec/include/linux/igmp.h /usr/src/linux-2.4.21-rc7-grsec/net/ipv4/.igmp.o.flags /usr/src/linux-2.4.21-rc7-grsec/net/ipv4/igmp.c /usr/src/linux-2.4.21-rc7-grsec/net/ipv4/igmp.o
IGMP ist das "Internet Group Management Protocol", dass sich mit multicast group member management beschäftigt. Da ich annehme, dass Du keinen IGMP-Client (also eine Anwendung, die sich als IGMP- Member registriert) gestartet hast, sollte das eigentlich nicht passieren. Wenn Dein Vorgänger auf dieser IP das allerdings getan hat...
Bewußt sicher nicht. Nach welchen Prozessen müsste ich suchen? ps axww PID TTY STAT TIME COMMAND 1 ? S 0:04 init 2 ? SW 0:00 [keventd] 3 ? SW 0:00 [kapmd] 4 ? SWN 0:00 [ksoftirqd_CPU0] 5 ? SW 0:00 [kswapd] 6 ? SW 0:00 [bdflush] 7 ? SW 0:00 [kupdated] 11 ? SW 0:00 [i2oevtd] 12 ? SW 0:00 [i2oblock] 15 ? SW 0:00 [kjournald] 17402 ? SW 0:00 [kjournald] 18570 ? SW 0:00 [kjournald] 11543 ? S 0:00 /usr/sbin/isdnlog -f /etc/isdn/isdnlog.options.contr0 /dev/isdnctrl0 22050 ? S 0:00 /sbin/syslogd -a /var/lib/frox/dev/log 31904 ? S 0:00 /sbin/klogd -c 1 -2 18191 ? S 0:00 /usr/sbin/smpppd 5584 ? S 0:00 /sbin/resmgrd 22507 ? S 0:00 /sbin/portmap 24592 ? S 0:00 lpd Waiting 32762 ? SL 0:00 /usr/sbin/ntpd -U ntp 5534 ? S 0:00 /usr/sbin/sshd -o PidFile /var/run/sshd.init.pid 19470 ? S 0:00 /usr/lib/postfix/master 14059 ? S 0:00 qmgr -l -t fifo -u 1785 ? S 0:00 /usr/sbin/atd 16412 ? S 0:00 /usr/sbin/cron 12792 ? S 0:01 /usr/bin/perl /usr/sbin/spamd -d -c -a -L 2498 ? S 0:00 /usr/sbin/nscd 14084 ? S 0:00 /usr/sbin/nscd 16521 ? S 0:00 /usr/sbin/nscd 23722 ? S 0:00 /usr/sbin/nscd 17816 ? S 0:00 /usr/sbin/nscd 1648 ? S 0:00 /usr/sbin/nscd 23778 ? S 0:00 /usr/sbin/nscd 16401 ? S 0:00 /usr/sbin/xinetd 16046 tty1 S 0:00 /sbin/mingetty --noclear tty1 29562 tty2 S 0:00 /sbin/mingetty tty2 26280 tty3 S 0:00 /sbin/mingetty tty3 5934 tty4 S 0:00 /sbin/mingetty tty4 6037 tty5 S 0:00 /sbin/mingetty tty5 27704 tty6 S 0:00 /sbin/mingetty tty6 13658 ? S 0:00 /usr/sbin/squid -sYD 23446 ? S 0:00 (squid) -sYD 25809 ? S 0:00 (unlinkd) 2620 ? S 0:00 /usr/sbin/sshd -o PidFile /var/run/sshd.init.pid 7869 ? S 0:00 /usr/bin/xisdnload 1479 ? S 0:00 /usr/sbin/sshd -o PidFile /var/run/sshd.init.pid 707 pts/0 S 0:00 -bash 11354 ? S 0:00 /usr/sbin/ipppd pidfile /var/run/ipppd.ippp0.pid /dev/ippp0 user 3658506000 name 3658506000 noipdefault netmask 255.255.255.255 defaultroute ipcp-accept-local ipcp-accept-remote 3563 ? S 0:00 /usr/sbin/sshd -o PidFile /var/run/sshd.init.pid 351 pts/1 S 0:00 -bash 27508 pts/0 S 0:00 tcpdump -n -i ippp0 4718 ? S 0:00 pickup -l -t fifo -u 5607 pts/1 R 0:00 ps axww Al
*** Al Bogner (suse-linux@pinguin.uni.cc) schrieb heute in suse-linux:
[...] Würde das etwas bzgl. automat. Disconnect bringen?
# reject IGMP iptables -A INPUT -p igmp -j REJECT iptables -A OUTPUT -p igmp -j REJECT iptables -A FORWARD -p igmp -j REJECT
Nein. Die Firewall greift - naturgemäß - erst, wenn der PPP-Daemon die Daten bereits übertragen hat. Du kannst einen kürzeren Timeout versuchen oder Deinen Provider bitte, zumindest das igmp-Zeugs abzuschalten.
[...] Bewußt sicher nicht. Nach welchen Prozessen müsste ich suchen?
Ja, latürlich nicht bewußt :). Ich betreibe seit Jahren einen Rechner mit ISDN-DOD und mir ist bisher keine Anwendung untergekommen, die igmp macht und nicht explizit dafür Gedacht ist. Grundsätzlich sind Anwendungen, die Video- und/oder Audio- Streams verarbeiten, gute Kandidaten. Ich kann ansich keinen Prozess sehen, der meinem Wissen nach igmp spricht. Ich schließe es für den NTPD nicht aus, würde mich aber im positiven Fall auch sehr wundern. Aber wie ich schon schrieb: Du emitierst kein igmp.
[...]
MfG Henning Hucke PS: Du betreibst einen NTPD!? Nur für interne Zwecke? Ansonsten solltest Du wohl besser sowas wie chronyd betreiben. Der kann den online- und offline-Zustand. -- Die "letzten Worte", die auf dem Grabstein der menschlichen Hochkultur eingraviert sein werden: "Du bist zu pessimistisch..."
On Wednesday 25 June 2003 20:09, Henning Hucke wrote:
Nein. Die Firewall greift - naturgemäß - erst, wenn der PPP-Daemon die Daten bereits übertragen hat.
So habe ich mir das auch vorgestellt.
PS: Du betreibst einen NTPD!?
Das ist vermutlich eine Auswirkung einer 8.2-Standardinstallation? Ich erinnere mich nicht den bei der Installation ausgewählt zu haben. Wie drehe ich den ab? Im Runlevel-Editor fand ich nichts mit ntpd und bei Netzwerkdienste auch nicht. Al
Hallo Al, am 25.06.03, um 14:29 h, schrieb Al Bogner:
Ich würde gerne die automatische Trennung bei keinem Traffic nach x Minuten bei einer ISDN-Anbindung ins Internet verwenden.
du brauchst wahrscheinlich einen active-filter für den ipppd schau mal ob http://www.google.de/search?q=active+filter+ipppd&ie=UTF-8&oe=UTF-8&hl=de&btnG=Google+Suche&meta= etwas brauchbares für dich ausspuckt. -- Mit freundlichen Grüßen/Yours sincerely, Dietmar Strasdat mailto:earthmate@gmx.net RSA 2048 PGP Key 0xBBE4EC81 available
On Friday 27 June 2003 10:57, Dietmar Strasdat wrote:
Ich würde gerne die automatische Trennung bei keinem Traffic nach x Minuten bei einer ISDN-Anbindung ins Internet verwenden.
du brauchst wahrscheinlich einen active-filter für den ipppd
Ich denke, der Hinweis geht in die richtige Richtung, aber: http://www.fli4l.de/german/extern/articles/dsl-hangup.html Soweit die guten Nachrichten für dsl Nutzer, nun die schlechten für ISDN-Nutzer. Der Kern und der ipppd unterstützen active-filter für isdn-Geräte nicht. Daher werden ISDN-Nutzer weiterhin das Problem haben, daß der Router nicht so zuverlässig auflegt. SuSE dürfte es aber doch geschafft haben den Kernel so zu patchen, dass es auch für ISDN funktioniert, da mein Rechner mit SuSE-Kernel auflegt und mit Vanilla-Kernel nicht. (Wo) Gibt es dafür einen Patch für den Vanilla-Kernel? Al
* Am Fre, 27 Jun 2003 schrieb Al Bogner:
On Friday 27 June 2003 10:57, Dietmar Strasdat wrote:
Ich würde gerne die automatische Trennung bei keinem Traffic nach x Minuten bei einer ISDN-Anbindung ins Internet verwenden.
du brauchst wahrscheinlich einen active-filter für den ipppd
Ich denke, der Hinweis geht in die richtige Richtung, aber:
http://www.fli4l.de/german/extern/articles/dsl-hangup.html Soweit die guten Nachrichten für dsl Nutzer, nun die schlechten für ISDN-Nutzer. Der Kern und der ipppd unterstützen active-filter für isdn-Geräte nicht. Daher werden ISDN-Nutzer weiterhin das Problem haben, daß der Router nicht so zuverlässig auflegt.
SuSE dürfte es aber doch geschafft haben den Kernel so zu patchen, dass es auch für ISDN funktioniert, da mein Rechner mit SuSE-Kernel auflegt und mit Vanilla-Kernel nicht.
(Wo) Gibt es dafür einen Patch für den Vanilla-Kernel?
http://trash.net/~kaber/ippp-filter/ Das ist der Patch, auf dem auch die SuSE-Implementierung beruht, wenn man whitespace-differences ignoriert, funzt der prima für den 2.4.21-vanilla. Dazu musst Du den ipppd selbst patchen, was aber bei mir auch weitgehend problemlos geklappt hat. Für Debian Woody könnte ich Dir entsprechende Pakete anbieten, für Suse leider nicht. Gruß Christoph -- Christoph Maurer - Tux#194235 - christoph-maurer@gmx.de
On Friday 27 June 2003 12:30, Christoph Maurer wrote:
SuSE dürfte es aber doch geschafft haben den Kernel so zu patchen, dass es auch für ISDN funktioniert, da mein Rechner mit SuSE-Kernel auflegt und mit Vanilla-Kernel nicht.
(Wo) Gibt es dafür einen Patch für den Vanilla-Kernel?
http://trash.net/~kaber/ippp-filter/
Das ist der Patch, auf dem auch die SuSE-Implementierung beruht, wenn man whitespace-differences ignoriert, funzt der prima für den 2.4.21-vanilla.
Was hast du genau gemacht? Aus INSTALL: - Patch your kernel with linux-2.4.20_ippp-filter.diff wenn ich im Verzeichnis der Kernel-Sourcen /usr/src/linux bin, wäre dann ein patch -p1 < /usr/src/linux-2.4.20_ippp-filter.diff ok? Muss patch isdn4k-utils with isdn4k-utils_ippp-filter.diff auch noch ausgeführt werden? Mit SuSE-Kernel funktioniert es ja bereits. Al
* Am Fre, 27 Jun 2003 schrieb Al Bogner:
On Friday 27 June 2003 12:30, Christoph Maurer wrote:
SuSE dürfte es aber doch geschafft haben den Kernel so zu patchen, dass es auch für ISDN funktioniert, da mein Rechner mit SuSE-Kernel auflegt und mit Vanilla-Kernel nicht.
(Wo) Gibt es dafür einen Patch für den Vanilla-Kernel?
http://trash.net/~kaber/ippp-filter/
Das ist der Patch, auf dem auch die SuSE-Implementierung beruht, wenn man whitespace-differences ignoriert, funzt der prima für den 2.4.21-vanilla.
Was hast du genau gemacht?
Aus INSTALL: - Patch your kernel with linux-2.4.20_ippp-filter.diff
wenn ich im Verzeichnis der Kernel-Sourcen /usr/src/linux bin, wäre dann ein
patch -p1 < /usr/src/linux-2.4.20_ippp-filter.diff ok?
Ich habe patch -p1 -l genommen, und vorher zum Testen noch --dry-run. Und danach dann make oldconfig, dann wirst Du nach CONFIG_IPPP_FILTER gefragt -> auf yes setzen.
Muss patch isdn4k-utils with isdn4k-utils_ippp-filter.diff auch noch ausgeführt werden? Mit SuSE-Kernel funktioniert es ja bereits.
Stimmt, sollte dann eigentlich nicht notwendig sein. Gruß Christoph -- Christoph Maurer - Tux#194235 - christoph-maurer@gmx.de
On Friday 27 June 2003 14:04, Christoph Maurer wrote:
patch -p1 < /usr/src/linux-2.4.20_ippp-filter.diff ok?
Ich habe patch -p1 -l genommen, und vorher zum Testen noch --dry-run.
/usr/src/linux-2.4.21-grsec-ippp # patch -p1 -l < /usr/src/linux-2.4.20_ippp-filter.diff patching file Documentation/Configure.help patching file drivers/isdn/Config.in patching file drivers/isdn/isdn_net.c patching file drivers/isdn/isdn_ppp.c patching file drivers/isdn/isdn_ppp.h patching file include/linux/isdn_ppp.h /usr/src/linux-2.4.21-grsec-ippp # patch -p1 < /usr/src/grsecurity-1.9.10-2.4.21.patch patching file Documentation/Configure.help Hunk #2 succeeded at 21754 (offset 11 lines). patching file Makefile ... Stellt das Offset ein Problem dar? Es gibt 1 Makefile bzw. kein Makefile.rej Al
* Am Fre, 27 Jun 2003 schrieb Al Bogner:
On Friday 27 June 2003 14:04, Christoph Maurer wrote:
patch -p1 < /usr/src/linux-2.4.20_ippp-filter.diff ok?
Ich habe patch -p1 -l genommen, und vorher zum Testen noch --dry-run.
/usr/src/linux-2.4.21-grsec-ippp # patch -p1 -l < /usr/src/linux-2.4.20_ippp-filter.diff patching file Documentation/Configure.help patching file drivers/isdn/Config.in patching file drivers/isdn/isdn_net.c patching file drivers/isdn/isdn_ppp.c patching file drivers/isdn/isdn_ppp.h patching file include/linux/isdn_ppp.h
/usr/src/linux-2.4.21-grsec-ippp # patch -p1 < /usr/src/grsecurity-1.9.10-2.4.21.patch patching file Documentation/Configure.help Hunk #2 succeeded at 21754 (offset 11 lines). patching file Makefile ...
Stellt das Offset ein Problem dar? Es gibt 1 Makefile bzw. kein Makefile.rej
Nein, heisst einfach, dass er die zu patchenden Zeilen nicht an der im Patch angegebenen Stelle, sondern 11 Zeilen später gefunden hat (z.B. weil der Patch nicht exakt für die Version war oder weil ein anderer Patch die Datei bereits verändert hatte). Gruß Christoph -- Christoph Maurer - Tux#194235 - christoph-maurer@gmx.de
On Friday 27 June 2003 12:30, Christoph Maurer wrote:
SuSE dürfte es aber doch geschafft haben den Kernel so zu patchen, dass es auch für ISDN funktioniert, da mein Rechner mit SuSE-Kernel auflegt und mit Vanilla-Kernel nicht.
(Wo) Gibt es dafür einen Patch für den Vanilla-Kernel?
Danke, es sieht so aus als ob es hier funktionieren würde. Ich habe nach dem ippp-filter-Patch auch noch den grsec-Patch eingespielt. Al
participants (4)
-
Al Bogner -
Christoph Maurer -
Dietmar Strasdat -
Henning Hucke