On 06/02/2015 11:24 AM, Vadim Kochan wrote:
On Tue, Jun 02, 2015 at 10:51:01AM +0200, Daniel Borkmann wrote:
On 06/02/2015 10:44 AM, Vadim Kochan wrote:
On Tue, Jun 02, 2015 at 10:36:12AM +0200, Daniel Borkmann wrote:
On 06/01/2015 05:43 PM, Vadim Kochan wrote:
On Mon, Jun 01, 2015 at 05:14:10PM +0200, Daniel Borkmann wrote:
On 06/01/2015 04:23 PM, Vadim Kochan wrote:
...
I checked that in this case Ethernet & Netlink frames will be mixed in the
pcap file, but netsniff-ng tries to identify all the frames as Ethernet,
and in this case frames is not wrapped with cooked header.
Right, so for that use case, it wouldn't work currently. I'm thinking that
in case of 'any' device *and* if there's at least one device present at the
time we bind the socket to any that would have netlink type, then we would
need to turn on cooked mode generally, so that in such environments Ethernet
and Netlink would have both cooked headers.
I think that would be useful to adapt the patch towards covering such use
cases as well since people might also like to correlate i.e. Netlink events
together with network packets. Could you please respin the patch towards
supporting this, too? Then I think, it should be ready to go in.
...
Then I think link type can be set as LINKTYPE_LINUX_SLL in the pcap
header. May be it would be useful to use LINKTYPE_LINUX_SLL by default
if 'any' was specified or only if the Netlink device present in UP state ?
I'm thinking that the following might be useful for the pcap writer:
Have an option --cooked that generally adds cooked header (no matter
what the underlying device is, so could be 'any' as well). Whenever
we bound our socket specifically to a nlmon device, then we enable
that option transparently in the case of default/ns pcap.
So, the solution might be - use cooked header automatically if only
nlmon device was specified or when --cooked option was specified ?
Yes, I would go for that as a start.
OK, but it sounds like "--cooked" option might be as additional feature
so I think the current patch can be applied as it is ? I have no problem
with re-working the patch, I am just asking :)
Ok, sure. I would prefer to have this in a single patch, so would be glad if
you could respin/rework your patch towards this.
Thanks again,
Daniel
--
You received this message because you are subscribed to the Google Groups
"netsniff-ng" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
