Re: LIBPCAP: ULOG iptables capturing

[Johan Verrept <jove () exelsys be>]

Guy Harris wrote:

> On Sep 10, 2003, at 2:07 PM, Johan Verrept wrote:
>
> > > That depends on the information supplied by the netlink stuff.  I
> > > presume you get raw network-layer (IP, IPv6, IPX, etc.) packet data 
> > > from
> > > it.  It probably also supplies an indication of the network-layer
> > > protocol, and perhaps other information.  What information does it
> > > supply?
> >
> > I haven't tried, but I think it are indeed raw packets. At least, 
> > when ulogd writes pcap files, it writes them with LINKTYPE_RAW.
>
> If you mean LINKTYPE_RAW as in the LINKTYPE_RAW in "savefile.c", that 
> is, indeed, raw network-layer packet data - meaning you get no 
> link-layer information, meaning no network-layer packet type.
>
> Is it only logging IP packets?  (I.e., no ARP, no non-IP network layer 
> protocols such as IPX, etc.?)

Yes. It can only log packets that pass through iptables and this are 
only ip packets. I don't think it even supports IPv6

> > Except the packet itself, ulog provides a message structure 
> > containing timestamp info, which iptables hook captured the data, 
> > input and output device name, a MAC address and an arbitrary prefix 
> > which can be controlled by the rule.
>
> So is this similar to, for example, the OpenBSD pflog stuff?  With 
> that, you get: 

Similar, but not the same.

>     an "address family" value for the packet (which the tcpdump and 
> Ethereal code for pflog assumes is either AF_INET or AF_INET6, i.e. 
> IPv4 or IPv6);

No address family as far as I can find. Always IPv4.

>     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.

>     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.

>     the action taken by PF on the packet (passed, dropped, scrubbed);

Absent. All ulog rules pass the packet. They log if they match.

>     a direction value (inout, in, out);

Only the hook field.

> along with a time stamp (the standard libpcap-format time stamp).

in secs and usecs.

> If so, I'd be inclined to use the timestamp info for a libpcap 
> timestamp, and supply the rest of the information in a 
> DLT_ULOG/LINKTYPE_ULOG header, unprocessed.  (Is that information 
> fixed-length or variable-length?) 

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.

What information do you want supplied in that DLT_ULOG/LINKTYPE_ULOG? As 
much as possible?

   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