>I will go ahead and put in Jun's ipv6 code and modify it for use with my
>new proto_*() functions. Jun: will the ipv6 code work well enough for you
>if I get rid of the OS-dependencies in the header files? Specifically, in
>your last patch, you have configure.in still looking for OS-supplied ipv6
>headers
There are two reasons for the OS checks in configure.in: headers
and libraries. I think we may be able to avoid some of checks for
headers, but not for the libraries.
Headers:
For operating systems with IPv6, struct ip6_hdr and other structs
will be defined in netinet/in.h. Those structures are roughly
standardized in RFC2133 and 2292. I believe, for ethereal we can
take either of the following paths:
- If ethereal never include netinet/in.h it is fine to define struct
ip6_hdr and others in packet-ipv6.h. I would like to see standard
struct ip6_hdr definitions in packet-ipv6.h (with guint8 or guint16,
if you want to). If we define some non-standard struct def
we add more confision so I suggest to stick to the standard.
- If ethereal includes netinet/in.h, we should check for existence
of struct ip6_hdr and other structures by AC_TRY_COMPILE, to
prevent duplicated defs.
Also, some of IPv6 distribution usees special include file path
(/usr/local/v6/include). For this we'll need to have OS check in
configure.in.
Libraries:
For IPv6 support we usually need to replace resolver libraries.
Most of IPv6 distribution distributes something like libinet6.a,
and it is necessary for ethereal to correctly link that
(-L/usr/local/v6/lib -linet6, for example).
>and packet-ipsec.c does a complicated little dance like this:
>#ifdef __KAME__
>#include <sys/socket.h>
>#include <net/route.h>
>struct mbuf;
>#include <netinet6/ipsec.h>
>#include <netinet6/ah.h>
>#include <netinet6/esp.h>
>#else
>struct newah {
> u_int8_t ah_nxt; /* Next Header */
> u_int8_t ah_len; /* Length of data + 1, in 32bit */
>...
>}
>Can I get rid of the #ifdef __KAME__ clause and just use the structs that
>are defined in packet-ipsec.c? I'll go ahead and convert them to glib
>fields like guint8.
For IPsec (AH and ESP) there is no standardized header defs.
I'm okay if you use the #else part only.
>It's best to supply ethereal with all necessary structs for ipv6 and ipsec
>decoding, so that ethereal built on any OS can decode these protocols, even
>if the box that is running ethereal doesn't support these protocols.
I agree.
>I'll continue with the work of merging your code, but please let me know if
>the changes that I want to make will hinder the usefulness of the code to
>you.
At some point please send your beta kit to me, I will be able to
check IPv6/IPsec support part. (or can I get the latest from, say,
anon-cvs?)
I've got IPv6-ready libpcap (which compiles "tcp" into "(ip6 or ip)
and tcp", for example) in our KAME IPv6 kit. If you want this to
be available separately from IPv6 kernel part, I can build a tar.gz
for this.
itojun
