Re: [netsniff-ng] [PATCH] netsniff-ng: Add support of pcap cooked header
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 :) Regards, -- 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.
Re: [netsniff-ng] [PATCH] netsniff-ng: Add support of pcap cooked header
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. -- 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.
Re: [netsniff-ng] [PATCH] netsniff-ng: Add support of pcap cooked header
On Tue, Jun 02, 2015 at 12:57:56PM +0200, Daniel Borkmann wrote: 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 Will do :) -- 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.
Re: [netsniff-ng] [PATCH] netsniff-ng: Add support of pcap cooked header
On Mon, Jun 01, 2015 at 02:09:39AM +0200, Daniel Borkmann wrote:
On 05/22/2015 04:45 PM, Vadim Kochan wrote:
Use pcap cooked header for Netlink messages as described here:
http://www.tcpdump.org/linktypes/LINKTYPE_NETLINK.html
Signed-off-by: Vadim Kochan vadi...@gmail.com
---
RFC - PATCH:
1) Add some clarifications about pcap cooked header in
netsniff-ng.8 man page.
2) Consider pcap type when checking if pcap cooked header
is needed in pcap_pkthdr_has_ll(...) func.
3) Fix wrong sll_protocol converting in pcap file. Removed
converting to big endian in sockaddr_to_pcap_ll(...) func.
...
Thanks Vadim for the follow-up! One question below:
...
+static inline void pcap_pkthdr_init(pcap_pkthdr_t *phdr, uint32_t link_type)
+{
+phdr-link_type = link_type;
}
Does this assumption still hold when you capture on i.e. '--in any' device,
and you have mixed data from Ethernet and Netlink combination to the same
pcap file?
#define FEATURE_UNKNOWN(0 0)
...
Hi,
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.
Regards,
--
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.
