Re: LIBPCAP: ULOG iptables capturing

[Johan Verrept <jove () exelsys be>]

hi guy,

This is the header supplied by the ulog module.

typedef struct ulog_packet_msg {
        unsigned long mark;
        long timestamp_sec;
        long timestamp_usec;
        unsigned int hook;
        char indev_name[IFNAMSIZ];
        char outdev_name[IFNAMSIZ];
        size_t data_len;
        char prefix[ULOG_PREFIX_LEN];
        unsigned char mac_len;
        unsigned char mac[ULOG_MAC_LEN];
        unsigned char payload[0];
} ulog_packet_msg_t;


ULOG_MAC_LEN is 80 (which is a maximum)

The MAC field contains a copy of the ethernet header when the packet is 
captured on the input hook.

> > >     an interface name (presumably the interface on which the packet 
> > > was received);
> >
> >
> > Two interface names. in and out, presence depending on which hook in 
> > the firewall the packet was captured.
>
>
> Is there a maximum length for those names?

IFNAMSIZ is 16

> > >     a rule number;
> > >     a reason code saying why the packet was logged;
> >
> >
> > Neither. there is a text field that can be set by the rule that logs 
> > the packet.
>
>
> Is there a maximum length for that text field?  (Is that the "arbitrary 
> prefix which can be controlled by the rule" you mentioned in an earlier 
> message?)

ULOG_PREFIX_LEN is 32
I don't know if it is usefull, but the user could filter on those to get 
a view on where the packets where the packets were logged in the firewall.

> > >     a direction value (inout, in, out);
> >
> >
> > Only the hook field.
>
>
> Is that a number, a string, or something else?

unsigned int hook;

> > It is more or less fixed length. There is a fixed length header 
> > defined but some of the fields are going to be empty.
> > In some cases it will be possible to reconstruct a MAC header, but 
> > only for those packets captured on the input hook.
>
>
> Would that be reconstructed from the MAC address you mentioned in an 
> earlier message?

Yes.

> > What information do you want supplied in that DLT_ULOG/LINKTYPE_ULOG? 
> > As much as possible?
>
>
> That would be my inclination, but I'm not writing applications to 
> process those files, nor am I writing code to generate them, so I'd say 
> "as much as people who read the files might find interesting".
>
> They might find the MAC address interesting; if so, it's probably 
> sufficient to supply the MAC address, you probably don't have to 
> reconstruct a MAC header.  (Is the MAC address variable-length, or does 
> it assume a 6-byte Ethernet/IEEE 802-style MAC address?)

Maybe we can just use the ulog_packet_msg header?

I have a question. Is there some function in libpcap that allows the 
user to extract a pointer to a protocol type it knows (and needs) 
regardless of the exact DLT_ type?
ie, I want the IP header from DLT_x, which returns a pointer or NIL if 
this layer isn't present.
This would make it easier to handle unknown DLT_ types without code 
duplication.

        J.

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe