Re: [netsniff-ng] [PATCH] netsniff-ng: Add support of pcap cooked header
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. -- 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 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 ? 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 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 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.
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.
