Re: LIBPCAP: ULOG iptables capturing

[Guy Harris <guy () alum mit edu>]

On Sep 11, 2003, at 11:55 AM, Johan Verrept wrote:

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

OK, no network-layer-type field needed (if it *did* support IPv6, we 
could look at the version number in the IP header).

> > So is this similar to, for example, the OpenBSD pflog stuff?  With 
> > that, you get:
>
> Similar, but not the same.

But it seems similar enough that it should probably be treated 
similarly to pflog.

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

Then the pseudo-header shouldn't have an address family. :-)

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

> >     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?)

> >     a direction value (inout, in, out);
>
> Only the hook field.

Is that a number, a string, or something else?

> > along with a time stamp (the standard libpcap-format time stamp).
>
> in secs and usecs.

That matches the libpcap time stamp.

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

Would that be reconstructed from the MAC address you mentioned in an 
earlier message?

> 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?)

-
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