Re: DLT type requested for OpenSolaris IPNET header

[Darren Reed <Darren.Reed () Sun COM>]

On 21/07/09 01:35 PM, Guy Harris wrote:
> On Jul 14, 2009, at 5:53 PM, Darren Reed wrote:
>
> > I'd like to request a DLT type for the "ipnet device" on OpenSolaris.
> >
> > A description of the packet header can be found here:
> >
> > http://arc.opensolaris.org/caselog/PSARC/2009/232/commitment.materials/bpf-psarc.txt 
> >
> >
> > and the relevant structure name is "dl_ipnetinfo".
>
> To quote the document:
>
> > struct dl_ipnetinfo {
> >     uint8_t        dli_version;
> >     uint8_t        dli_family;
> >     uint16_t    dli_htype;
> >     uint32_t    dli_pktlen;
> >     uint32_t    dli_ifindex;
> >     uint32_t    dli_grifindex;
> >     uint32_t    dli_zsrc;
> >     uint32_t    dli_zdst;
> > };
> > typedef struct dl_ipnetinfo dl_ipnetinfo_t;
> >
> > dli_version   - version number (2)
> > dli_family    - protocol family (AF_INET, AF_INET6, etc)
>
> Presumably those are Solaris values for the protocol family; could you 
> enumerate the possible numerical values for the protocol family?  AF_ 
> values can differ from platform to platform; everybody probably picked 
> up the same value for AF_INET from BSD, but AF_INET6 came after that 
> point, and it has different values on different platforms.

Indeed.
On Solaris, AF_INET is 2 and AF_INET6 is 26.


> > dli_htype     - hook type (in, out, local)
>
> Presumably there are specific values for those (0, 1, and 2, or whatever).

Yes, 0 for inbound, 1 for outbound, 2 for local.

> > dli_pktlen    - length of the packet excluding this header
> > dli_ifindex   - interface index number
> > dli_grifindex - group interface index number (for IPMP interfaces)
>
> Are those standard interface index numbers?  (Many OSes seem to have a 
> standard notion of interface numbers - does that come from SNMP?)

They are... but Solaris has many different indexes, at present...
There's an interface index number at the link level and a different
one at the IP layer. Although they may be the same, there is no
guarantee that it will be this way.

And yes, I believe that SNMP may be to blame :)

> > dli_zsrc      - zone identifier for the source of the packet
> > dli_zdst      - zone identifier for the destination of the packet
>
> Presumably those identifiers are just numbers.

Correct.
However, there are two that do have meaning:
0 - global zone
-1/0xffffffff -  no zone (e.g. packet receive from the wire)


In the changes I've made in libpcap locally (I can send diffs or post
them on a web page if you would like), I've :
- used "dli_htype" as the means for generating a filter for inbound
 and outbound packets (gencode.c);
- in pcap-bpf.c, made changes to allow DLT_IPNET to be returned
 as a DLT type, in addition to any other type present.

From the global zone:
# tcpdump -L
Data link types (use option -y to set):
 DOCSIS (DOCSIS) (printing not supported)
 IPNET (Solaris IPNET)
 EN10MB (Ethernet)

From a zone that shares its IP instance with the global zone:
# zlogin shared tcpdump -L
Data link types (use option -y to set):
 IPNET (Solaris IPNET)

From a zone that has an exclusive IP instance:
# zlogin exclusive tcpdump -L
Data link types (use option -y to set):
 DOCSIS (DOCSIS) (printing not supported)
 IPNET (Solaris IPNET)
 EN10MB (Ethernet)

Also, on Solaris, /dev/bpf is a symbolic link to a character device
file over in /devices somewhere. A small change to configure.in to
do "test -r /dev/bpf -o -h /dev/bpf" was required to get libpcap to
correctly auto-configure cloning BPF device support.

Darren

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.