tcpdump mailing list archives
Re: [tcpdump] About struct in_addr / struct in6_addr
From: Denis Ovsienko <denis () ovsienko info>
Date: Mon, 20 Feb 2023 08:17:08 +0000
On Sun, 17 Jul 2022 15:29:39 -0700 Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
On Jul 17, 2022, at 11:09 AM, Francois-Xavier Le Bail <devel.fx.lebail () orange fr> 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.hThat'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-leave () lists tcpdump org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Current thread:
- Re: [tcpdump] About struct in_addr / struct in6_addr Denis Ovsienko (Feb 18)
- Re: [tcpdump] About struct in_addr / struct in6_addr Guy Harris (Feb 18)
- <Possible follow-ups>
- Re: [tcpdump] About struct in_addr / struct in6_addr Denis Ovsienko (Feb 20)
- Re: [tcpdump] About struct in_addr / struct in6_addr Guy Harris (Feb 20)
- Re: [tcpdump] About struct in_addr / struct in6_addr Guy Harris (Feb 20)
- Re: [tcpdump] About struct in_addr / struct in6_addr Guy Harris (Feb 20)