tcpdump getifaddrs: Connection refused
Jan 'Red Bully' Seiffert
redbully at cc.fh-luh.de
Wed Mar 16 18:30:32 CET 2005
Ola!
Andreas Koch schrieb:
>>>tcpdump -i eth0 geht
>>
>>Äh, was denn nun, funktioniert oder funktioniert tcpdump nicht? ...oder
>>nur, wenn Du mit '-i eth0' ein Interface angibst?
>>
> Es funktioniert wenn ich ihm ein Interface angebe. Er wird dann wohl
> getifaddrs() nicht aufrufen.
>
Wird wohl sowas sein.
>>Der 2te Treffer bei "google://getifaddrs: Connection refused" sagt, daß
>>anscheinend der libc-Aufruf getifaddrs() nicht funktioniert.
>
> hab ich auch gelesen, hat mir nur nichts gesagt. Ich hatte mehr nach "
> dann must du paket xyz installieren" ausschau gehalten.
>
Nagut, andere herangehensweise.
JBG ist da eher der "Use the Source, Luke"-Mensch
[ltrace]
> pcap_lookupdev(0xbffffca0) = NULL
hmmm, das sieht nach Misserfolg aus. Thou shalt not follow the NULL
pointer...
Es wird dann wohl innerhalb der libpcap getifaddr() aufgerufen, nur
warum das dann nicht im ltrace is (is ne glibc funktion, die
ge-inline-d?), oder glibc ohne debug-symbole ...
[strace]
[linker-blabla]
[malloc-blabla]
> fstat64(3, 0xbffff9c4) = -1 ENOSYS (Function not implemented)
Das ist ja schon mal garnich nett, sieht wirklich so aus, als wenn deine
libc nicht so ganz zum Kernel passt...
> socket(PF_NETLINK, SOCK_RAW, 0) = 3
> bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
> getsockname(3, {sa_family=AF_NETLINK, pid=1566, groups=00000000}, [12]) = 0
> time(NULL) = 1110994717
> sendto(3, "\24\0\0\0\22\0\1\3\35o8B\0\0\0\0\0\0\21\300", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = -1
> ECONNREFUSED (Connection refused)
Hier wirds interressant.
Sieht so aus, als wenn getifaddr() einen netlink(7)-Socket oeffnet.
Warscheinlich getrieben durch libnetlink, die scheinen sich mit dem
iproute/ipchains/iptables-Teil des Kernel unterhalten zu wollen.
Naja, das entscheidende Problem ist anscheinend die letzte Zeile, das
senden der Anfrage schlaegt fehl, da die Gegenseite die Verbindung
abgelehnt hat (geaendertes Antwortverhalten im Kernel > 2.2 ?).
Alles sehr misterioes was die da Probieren, ich schau mir mal den source
an...
> close(3) = 0
> write(2, "tcpdump: ", 9) = 9
> write(2, "getifaddrs: Connection refused", 30) = 30
> write(2, "\n", 1) = 1
> exit_group(1) = ?
>
Naja, und dann beenden wir uns.
> Andreas
>
Gruss
Jan
--
> Assembler, verdammt nah an der CPU!
VHDL, bei uns sitzen sie in der ersten Reihe!
> Was man nicht in Assembler programmieren kann, muß man löten.
Was man nicht in VHDL programmieren kann, muß in Software emuliert werden.
More information about the Linux
mailing list