[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
[tcpdump-workers] Re: [tcpdump] About struct in_addr / struct in6_addr
On Feb 18, 2023, at 10:27 AM, Denis Ovsienko wrote: > OS IPv6 support would be a very reasonable requirement for tcpdump 5. Which would, among other things, let us remove the tests for various add-on IPv6 stacks in configure.ac. ___ 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 16:11:01 -0700 Guy Harris via tcpdump-workers wrote: > On Jul 17, 2022, at 3:39 PM, Bill Fenner wrote: > > > IMO it is safe to drop support for OSes lacking native IPv6 > > support. > > Yeah. Back when IPv6 support was added to tcpdump, it was an > experimental new technology and the configure script had to figure > out which of several add-on IPv6 packages you had installed. Now a > significant amount of Wikipedia vandalism comes from IPv6 addresses > rather than IPv4 addresses. :-) OS IPv6 support would be a very reasonable requirement for tcpdump 5. -- 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
