[tcpdump-workers] Re: Pcap debug at runtime
Thank you, I’ll do this. From: Guy Harris Sent: Monday, February 20, 2023 3:18:24 PM To: Paschal Chukwuebuk Amusuo Cc: tcpdump-workers@lists.tcpdump.org Subject: Re: [tcpdump-workers] Pcap debug at runtime External Email: Use caution with attachments, links, or sharing data On Feb 20, 2023, at 12:15 PM, Paschal Chukwuebuk Amusuo wrote: > Please, is there a way to print out debug statements at runtime when using > pcap? Debug statements in your program? Add printf() or fprintf(stderr, ...) or... calls to your program. Debug statements in libpcap? Get the libpcap source, add printf() or fprintf(stderr, ...) or... calls to it, build it, install it, and compile your program with it. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: Pcap debug at runtime
On Feb 20, 2023, at 12:15 PM, Paschal Chukwuebuk Amusuo wrote: > Please, is there a way to print out debug statements at runtime when using > pcap? Debug statements in your program? Add printf() or fprintf(stderr, ...) or... calls to your program. Debug statements in libpcap? Get the libpcap source, add printf() or fprintf(stderr, ...) or... calls to it, build it, install it, and compile your program with it. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Pcap debug at runtime
Hi, Please, is there a way to print out debug statements at runtime when using pcap? I am experiencing some weird behavior when using pcap. Packets get stuck in pcap even when using immediate mode. I would love for a way to view debug logs and maybe, understand what’s happening. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: [tcpdump] About struct in_addr / struct in6_addr
On Feb 20, 2023, at 2:20 AM, Guy Harris wrote: > So the code is correct, but could easily be misintrpreted. Perhaps it'd be > better if we used the values from af.h rather than using AF_INET and > AF_INET6. Done in 0dc32a024773968cb1ae00729758e61b7418564a I'll see whether anything else uses numbers rather than AFNUM_ values. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: [tcpdump] About struct in_addr / struct in6_addr
On Feb 20, 2023, at 12:17 AM, Denis Ovsienko wrote:
> AF_INET6 looks a bit more convoluted. There is some code that uses
> AF_INET6 to dissect wire encoding, which is usually a wrong idea. For
> example, pimv2_addr_print() switches on AF_INET and AF_INET6, and the
> PIMv2 header encoding (RFC 4601 Section 4.9.1) clearly says the AF is
> the IANA AF [1]:
>
> 1: IP
> 2: IP6
And RFC 7761:
https://www.rfc-editor.org/rfc/rfc7761#section-4.9
says the same thing.
> Which is different from most OS definitions of AF_INET and AF_INET6,
> but this function has been implemented this way since 1999, and somehow
> it seems to be able to decode a few PIMv2 packet captures I found on
> the Internet. So cases like this will require more attention and some
> of the remaining AF_INET6 instances may become wire encoding constants
> rather than the OS AF_INET6 constant.
That's handled by the code at the beginning of pimv2_addr_print():
if (addr_len == 0) {
if (len < 2)
goto trunc;
switch (GET_U_1(bp)) {
case 1:
af = AF_INET;
addr_len = (u_int)sizeof(nd_ipv4);
break;
case 2:
af = AF_INET6;
addr_len = (u_int)sizeof(nd_ipv6);
break;
default:
return -1;
}
if (GET_U_1(bp + 1) != 0)
return -1;
hdrlen = 2;
} else {
switch (addr_len) {
case sizeof(nd_ipv4):
af = AF_INET;
break;
case sizeof(nd_ipv6):
af = AF_INET6;
break;
default:
return -1;
break;
}
hdrlen = 0;
}
so, after that code, af is either AF_INET for IPv4 addresses or AF_INET6 for
IPv6 addresses, and af is what's tested against those two values.
So the code is correct, but could easily be misintrpreted. Perhaps it'd be
better if we used the values from af.h rather than using AF_INET and AF_INET6.
(And perhaps the values from af.h should be renamed AFNUM_IPv4 and AFNUM_IPv6,
to make them look even less like socket API AF_ values.)
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: [tcpdump] About struct in_addr / struct in6_addr
On Sun, 17 Jul 2022 15:29:39 -0700 Guy Harris via tcpdump-workers wrote: > On Jul 17, 2022, at 11:09 AM, Francois-Xavier Le Bail > wrote: > > > Remain some stuff about 'struct in6_addr'. Any need to keep them? > > > > $ git grep -l 'struct in6_addr' > > CMakeLists.txt > > cmakeconfig.h.in > > config.h.in > > configure > > configure.ac > > netdissect-stdinc.h > > That's there for the benefit of OSes whose APIs don't have standard > IPv6 support; if there are any left that we care about (or if there > are old non-IPv6 versions we care about for any OSes we support), > then it might be useful, but I'm not sure it would build (we use > gethostbyaddr(), so *maybe* it'll compile, and maybe gethostbyaddr() > will fail when passed AF_INET6 and the code will just show the IPv6 > address rather than a name). After a closer look at this code it turns out the only remaining case of struct in6_addr is Windows-specific win32_gethostbyaddr(), so the conditional declaration of struct in6_addr can be at least moved into the same "#ifdef _WIN32" block and at least Autoconf-specific checks for struct in6_addr are moot. If anyone could confirm that supported versions of Windows always have struct in6_addr, that could be removed altogether and the only occurrence of struct in6_addr would be in win_gethostbyaddr(). AF_INET6 looks a bit more convoluted. There is some code that uses AF_INET6 to dissect wire encoding, which is usually a wrong idea. For example, pimv2_addr_print() switches on AF_INET and AF_INET6, and the PIMv2 header encoding (RFC 4601 Section 4.9.1) clearly says the AF is the IANA AF [1]: 1: IP 2: IP6 Which is different from most OS definitions of AF_INET and AF_INET6, but this function has been implemented this way since 1999, and somehow it seems to be able to decode a few PIMv2 packet captures I found on the Internet. So cases like this will require more attention and some of the remaining AF_INET6 instances may become wire encoding constants rather than the OS AF_INET6 constant. The only sound reason for tcpdump to use AF_INET6 seems to be in ip6addr_string() for address-to-name resolving. That use case already has nd_ipv6 and could have a simple "#ifdef AF_INET6" guard. This would eliminate respective logistics in Autoconf and CMake and would make OS IPv6 support a nice-to-have, but not an essential dependency. 1: https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml -- Denis Ovsienko ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
