Re: Promiscuous patches

Re: Promiscuous patches

[Alexander Aring]

Hi Martin,

On Fri, Sep 12, 2014 at 02:14:01PM +0100, Martin Townsend wrote:
> Hi Alex,
> 
> You sent me a patch not long ago to allow automatic setting of promiscous mode.  I seem to have lost this patch, could you resend as I want to look into it.
> 

some of my old branch [0].

btw.

I added to the rework now the promiscous mode and decided to not enable
this mode while setting promiscous mode flag.

It's now setted by doing a ifup of a monitor interface. See [1].

Maybe you will change it like this (it's better) but there are so many
issue to think about (Disable promiscous if netif on non MONITOR
interfaces etc...).

And also you can't have NODE and MONITOR running because it's phy mac
sublayer attribute.

I will cc linux-wpan, hope it's okay.

In next days I will draw some fancy architecture graphic about the
rework. To understand what I really did there. (I also have no idea
about to implement it 100% right, I do experiments and then think about
it "how we can do that in a better way") and very important in a way
where we could easily handle/add _new features_.

If anybody has questions about this implementation I would be very happy
to answer them. :-)

- Alex

[0] https://github.com/linux-wpan/linux-wpan-next/commits/alex/wip
[1] https://github.com/linux-wpan/linux-wpan-next/blob/d5d62172f69ecf8db4dce77e790403e532687662/net/mac802154/iface.c#L42

Re: Promiscuous patches

[Alexander Aring]

On Mon, Sep 15, 2014 at 01:45:51AM +0200, Alexander Aring wrote:
> Hi Martin,
> 
> On Fri, Sep 12, 2014 at 02:14:01PM +0100, Martin Townsend wrote:
> > Hi Alex,
> > 
> > You sent me a patch not long ago to allow automatic setting of promiscous mode.  I seem to have lost this patch, could you resend as I want to look into it.
> > 
> 
> some of my old branch [0].
> 
> btw.
> 
> I added to the rework now the promiscous mode and decided to not enable
> this mode while setting promiscous mode flag.
> 
> It's now setted by doing a ifup of a monitor interface. See [1].
> 
> Maybe you will change it like this (it's better) but there are so many
> issue to think about (Disable promiscous if netif on non MONITOR
> interfaces etc...).
> 
> And also you can't have NODE and MONITOR running because it's phy mac
> sublayer attribute.
> 

I mean with mac sublayer here, some timing critical mac operations/algorithmn
done by phy's. Like AACK/ARET, CSMA, etc handling. I don't beleieve that we can
ever handle these timing ciriticals inside mac802154.

So we have multiple interfaces but one phy. :-)

One phy means we need to check the constraints that these parameters are
always the same on each interface.

On phy pib handling we don't need that. This is no MAC algorithmn, it's
only physical changes to the phy rf handling and for the rework we don't
have the multiple phy handling anymore.

- Alex

Re: Promiscuous patches

[Alexander Aring]

On Mon, Sep 15, 2014 at 01:56:07AM +0200, Alexander Aring wrote:
> On Mon, Sep 15, 2014 at 01:45:51AM +0200, Alexander Aring wrote:
> > Hi Martin,
> > 
> > On Fri, Sep 12, 2014 at 02:14:01PM +0100, Martin Townsend wrote:
> > > Hi Alex,
> > > 
> > > You sent me a patch not long ago to allow automatic setting of promiscous mode.  I seem to have lost this patch, could you resend as I want to look into it.
> > > 
> > 
> > some of my old branch [0].
> > 
> > btw.
> > 
> > I added to the rework now the promiscous mode and decided to not enable
> > this mode while setting promiscous mode flag.
> > 
> > It's now setted by doing a ifup of a monitor interface. See [1].
> > 
> > Maybe you will change it like this (it's better) but there are so many
> > issue to think about (Disable promiscous if netif on non MONITOR
> > interfaces etc...).
> > 
> > And also you can't have NODE and MONITOR running because it's phy mac
> > sublayer attribute.
> > 
> 
> I mean with mac sublayer here, some timing critical mac operations/algorithmn
> done by phy's. Like AACK/ARET, CSMA, etc handling. I don't beleieve that we can
> ever handle these timing ciriticals inside mac802154.
> 
> So we have multiple interfaces but one phy. :-)
> 
> One phy means we need to check the constraints that these parameters are
> always the same on each interface.
> 
> On phy pib handling we don't need that. This is no MAC algorithmn, it's
> only physical changes to the phy rf handling and for the rework we don't
> have the multiple phy handling anymore.
> 

grml s/promiscous/promiscuous everywhere. I need to remember that.
Sorry.

I will fix it on the branch.

- Alex

Re: Promiscuous patches

[Alexander Aring]

On Mon, Sep 15, 2014 at 01:56:18PM +0200, Alexander Aring wrote:
> On Mon, Sep 15, 2014 at 01:56:07AM +0200, Alexander Aring wrote:
> > On Mon, Sep 15, 2014 at 01:45:51AM +0200, Alexander Aring wrote:
> > > Hi Martin,
> > > 
> > > On Fri, Sep 12, 2014 at 02:14:01PM +0100, Martin Townsend wrote:
> > > > Hi Alex,
> > > > 
> > > > You sent me a patch not long ago to allow automatic setting of promiscous mode.  I seem to have lost this patch, could you resend as I want to look into it.
> > > > 
> > > 
> > > some of my old branch [0].
> > > 
> > > btw.
> > > 
> > > I added to the rework now the promiscous mode and decided to not enable
> > > this mode while setting promiscous mode flag.
> > > 
> > > It's now setted by doing a ifup of a monitor interface. See [1].
> > > 
> > > Maybe you will change it like this (it's better) but there are so many
> > > issue to think about (Disable promiscous if netif on non MONITOR
> > > interfaces etc...).
> > > 
> > > And also you can't have NODE and MONITOR running because it's phy mac
> > > sublayer attribute.
> > > 
> > 
> > I mean with mac sublayer here, some timing critical mac operations/algorithmn
> > done by phy's. Like AACK/ARET, CSMA, etc handling. I don't beleieve that we can
> > ever handle these timing ciriticals inside mac802154.
> > 
> > So we have multiple interfaces but one phy. :-)
> > 
> > One phy means we need to check the constraints that these parameters are
> > always the same on each interface.
> > 
> > On phy pib handling we don't need that. This is no MAC algorithmn, it's
> > only physical changes to the phy rf handling and for the rework we don't
> > have the multiple phy handling anymore.
> > 
> 
> grml s/promiscous/promiscuous everywhere. I need to remember that.
> Sorry.
> 
> I will fix it on the branch.
> 

Seems to be a common error, "grep -r promiscous .":

./drivers/net/ethernet/wiznet/w5100.c:#define   S0_MR_MACRAW		  0x04 /* MAC RAW mode (promiscous) */
./drivers/net/ethernet/wiznet/w5300.c:#define   S0_MR_MACRAW		  0x0004  /* MAC RAW mode (promiscous) */
./drivers/net/wireless/ath/ath10k/htt.h:	/* Non-data in promiscous mode */

- Alex

Re: Promiscuous patches

[Martin Townsend]

Hi Alex,

Thanks for the links, I needed this to get wireshark working again as we now have address filtering support in HW.

The code looks good and using the net device op for detecting a rx flag change looks good to me.  A couple of thoughts.
1) Maybe you could remove the HW flag for promiscuous? just let the driver implement the set_promiscuous_mode driver ops function if the HW supports it or leave it NULL if it doesn't
2) I had to implement the ndo_change_rx_flags net device ops in wpan.c not monitor.c.  For remote wireshark captures that we do we use tcpdump -i wpan0 on the boards.  Are we doing something wrong here? Your code seems to suggest that we should bring up a separate monitor interface?

- Martin.



On 15/09/14 00:45, Alexander Aring wrote:
> Hi Martin,
>
> On Fri, Sep 12, 2014 at 02:14:01PM +0100, Martin Townsend wrote:
>> Hi Alex,
>>
>> You sent me a patch not long ago to allow automatic setting of promiscous mode.  I seem to have lost this patch, could you resend as I want to look into it.
>>
> some of my old branch [0].
>
> btw.
>
> I added to the rework now the promiscous mode and decided to not enable
> this mode while setting promiscous mode flag.
>
> It's now setted by doing a ifup of a monitor interface. See [1].
>
> Maybe you will change it like this (it's better) but there are so many
> issue to think about (Disable promiscous if netif on non MONITOR
> interfaces etc...).
>
> And also you can't have NODE and MONITOR running because it's phy mac
> sublayer attribute.
>
> I will cc linux-wpan, hope it's okay.
>
> In next days I will draw some fancy architecture graphic about the
> rework. To understand what I really did there. (I also have no idea
> about to implement it 100% right, I do experiments and then think about
> it "how we can do that in a better way") and very important in a way
> where we could easily handle/add _new features_.
>
> If anybody has questions about this implementation I would be very happy
> to answer them. :-)
>
> - Alex
>
> [0] https://github.com/linux-wpan/linux-wpan-next/commits/alex/wip
> [1] https://github.com/linux-wpan/linux-wpan-next/blob/d5d62172f69ecf8db4dce77e790403e532687662/net/mac802154/iface.c#L42

Re: Promiscuous patches

[Alexander Aring]

On Thu, Sep 18, 2014 at 09:57:09AM +0100, Martin Townsend wrote:
> Hi Alex,
> 
> Thanks for the links, I needed this to get wireshark working again as we now have address filtering support in HW.
> 
> The code looks good and using the net device op for detecting a rx flag change looks good to me.  A couple of thoughts.
> 1) Maybe you could remove the HW flag for promiscuous? just let the driver implement the set_promiscuous_mode driver ops function if the HW supports it or leave it NULL if it doesn't

yea, I had some issue with that. The issue was at86rf212 and at86rf23x
use the same driver, the at86rf230.

The ieee802154_ops should be const (it's already const in the rework
branch). During runtime changes on this makes very very big problems.
Now the ieee802154_ops contains a callback for example listen before receive
".set_lbt". This functionality is only supported for at86rf212 not for
at86rf23x chips. I see no other solution to introduce flags which could
be change during runtime, to indicate that the chip supports this.

A other solution would be to check on chip revision and then "return
-EOPNOTSUPP;", this occurs also in another issue. From userspace you
need to know what the device supports. In this case if you want to know
what the device support's you need to run the driver ops and check if it
was -EOPNOTSUPP, otherwise you did a change into/out of promiscuous
mode. :-)

So replace .set_lbt with .set_promiscuous_mode (maybe I should remove
the "_mode") then we could run into same issues.

I add a check on NULL when calling "drv_set_promiscuous_mode", then this
is bug in driver layer. You setted the flag but not implement the driver
callback. -> this should never occur on a good driver.



btw.

I will add a check on creating monitor interfaces on promiscuous flag.
Simple if a driver doesn't support promiscuous flag, then a monitor
makes no sense.

> 2) I had to implement the ndo_change_rx_flags net device ops in wpan.c not monitor.c.  For remote wireshark captures that we do we use tcpdump -i wpan0 on the boards.  Are we doing something wrong here? Your code seems to suggest that we should bring up a separate monitor interface?
> 

not separate.

You have only one phy. The phy have some mac functionality like address
filter and promiscuous mode. If you go into the promiscuous mode you
disable all filtering blabla on the phy. You know what the promiscuous
does.

But you have only one phy, you can't use address filtering and
promiscuous at the same time. You could do a context switch for all the
registers, but this would not be practical. I hope we have the same
opinion here.

So the interfaces would be:

MONITOR -> enables promiscuous mode, no filtering by FCS(doesn't work
	   yet) addresses, etc... all frames on channel came in.

NODE -> address filtering (if supported), all filtering which is
	practical for common use and which belongs to us.

COORD -> like NODE but with address filtering functionality to run as
         pan coordinator.

These are the mac functionality for phy settings only! We also always
know the current interface type by doing internal linux mac802154 stuff
and that's good for handling mlme ops (managment layer). Very different
when running as NODE or COORD. You know NODE associates with COORDS and
channel scan etc...


Now to your question:

A node or wpan device uses address filtering, but we have also address
filter inside of mac802154, to be sure. So there are two address
filtering running, one of phy mac handling and one inside of mac802154.
The phy mac handling address filter makes sense, because it is really
fast.

In promiscuous mode, the phy interrupts on any frame which is received,
you don't have any address filtering mac functionality on the phy
anymore. That means you have only the linux mac802154 address filtering
functionality running. That means the phy doesn't filter anymore and you
get really all frames and the internal mac802154 filter drops the
packets.

To enable promiscuous mode on a wpan/node type makes no sense. To enables
promiscuous mode on MONITOR makes, sense. On  MONITOR type we don't run
any mac802154 address filtering and you will get any frame on the
monitor interface.


I hope it's understandable what I mean here a little bit.

-Alex

[0] https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/mac802154/driver-ops.h#L212

Re: Promiscuous patches

[Martin Townsend]

Hi Alex,

If I'm following correctly you need to add a monitor interface as well as a node/coord interface to the PHY.  so we would see wpan0 and wpanmon0 and then I could do a
tcpdump -i wpanmon0?

- Martin.

On 18/09/14 10:41, Alexander Aring wrote:
> In promiscuous mode, the phy interrupts on any frame which is received,
> you don't have any address filtering mac functionality on the phy
> anymore. That means you have only the linux mac802154 address filtering
> functionality running. That means the phy doesn't filter anymore and you
> get really all frames and the internal mac802154 filter drops the
> packets.
>
> To enable promiscuous mode on a wpan/node type makes no sense. To enables
> promiscuous mode on MONITOR makes, sense. On  MONITOR type we don't run
> any mac802154 address filtering and you will get any frame on the
> monitor interface.
>
>
> I hope it's understandable what I mean here a little bit.

Re: Promiscuous patches

[Alexander Aring]

On Thu, Sep 18, 2014 at 11:04:42AM +0100, Martin Townsend wrote:
> Hi Alex,
> 
> If I'm following correctly you need to add a monitor interface as well as a node/coord interface to the PHY.  so we would see wpan0 and wpanmon0 and then I could do a
> tcpdump -i wpanmon0?
> 

mhhh, no.

It's a question of design to have NODE, COORD and MONITOR parallel.

But when we have phy mac handling for a iftype we should not have this
parallel.

We have multiple interfaces support, BUT only ONE phy.

The phy have also mac handling, like addressfilter XOR promiscousmode.

The addressfilter doesn't interrupt the phy on ANY frame, only on frames
which belongs to us (the phy). That's why addressfilter makes sense on NODE and COORD.
After an interrupt the LINUX mac802154 stack also run a addressfilter to
be sure. (BUT only on NODE and COORD types).

The MONITOR type bypass the mac802154 filters and send any frame to the
interface, then you can see it on wireshark. But this required to
disable the addressfilter of mac phy handling -> promiscousmode.

Now having NODE and MONITOR parallel, you can't have promiscousmode and
addressfilter at the same time. promiscousmode disabled the
addressfilter. But then the LINUX mac802154 have a very workload because
it need to check any frame which is received on promiscousmode. This
isn't pracitcal, also promiscousmode isn't only addressfiltering also
CRC...


When you enable the promiscousmode on WPAN/NODE interface you only
enable that your cpu load increases because you don't have any phy
addressfilter anymore, then mac802154 do the job for you and remember a
MONITOR device bypass the mac802154 filtering, then you see ONLY on a
MONITOR interface every frame. Also frames which not in your pan or doesn'
belong to you. That's what's the monitor interface does.


More understandable? :/

- Alex

Re: Promiscuous patches

[Martin Townsend]

Hi Alex,

On 18/09/14 11:43, Alexander Aring wrote:
> On Thu, Sep 18, 2014 at 11:04:42AM +0100, Martin Townsend wrote:
>> Hi Alex,
>>
>> If I'm following correctly you need to add a monitor interface as well as a node/coord interface to the PHY.  so we would see wpan0 and wpanmon0 and then I could do a
>> tcpdump -i wpanmon0?
>>
> mhhh, no.
>
> It's a question of design to have NODE, COORD and MONITOR parallel.
>
> But when we have phy mac handling for a iftype we should not have this
> parallel.
>
> We have multiple interfaces support, BUT only ONE phy.
>
> The phy have also mac handling, like addressfilter XOR promiscousmode.
>
> The addressfilter doesn't interrupt the phy on ANY frame, only on frames
> which belongs to us (the phy). That's why addressfilter makes sense on NODE and COORD.
> After an interrupt the LINUX mac802154 stack also run a addressfilter to
> be sure. (BUT only on NODE and COORD types).
>
> The MONITOR type bypass the mac802154 filters and send any frame to the
> interface, then you can see it on wireshark. But this required to
> disable the addressfilter of mac phy handling -> promiscousmode.
>
> Now having NODE and MONITOR parallel, you can't have promiscousmode and
> addressfilter at the same time. promiscousmode disabled the
> addressfilter. But then the LINUX mac802154 have a very workload because
> it need to check any frame which is received on promiscousmode. This
> isn't pracitcal, also promiscousmode isn't only addressfiltering also
> CRC...
Is monitor mode like the one in WIFI (rfmon)
http://en.wikipedia.org/wiki/Monitor_mode
Where it can't transmit packets, it basically turns the device into a packet sniffer?
>
> When you enable the promiscousmode on WPAN/NODE interface you only
> enable that your cpu load increases because you don't have any phy
> addressfilter anymore, then mac802154 do the job for you and remember a
> MONITOR device bypass the mac802154 filtering, then you see ONLY on a
> MONITOR interface every frame. Also frames which not in your pan or doesn'
> belong to you. That's what's the monitor interface does.
>
>
> More understandable? :/
Basically I want to be able to run tcpdump on wpan0 to capture packets but not effect the functionality of device so if it's a node or coordinator it carries on acting like one and the packet traffic capture would reflect this.  So if I'm running as a coordinator and want to see RPL traffic that the coordinator generates and receives I can do this.
My understanding is that I put the WPAN interface into promiscuous mode to do this.  I accept that the CPU will come under more load but we are only talking about a 256kbps link.  If you a running a linux distribution chances are you are using a fairly powerful ARM or equivalent processor.
Are we saying this is not possible?

> - Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

- Martin.

Re: Promiscuous patches

[Alexander Aring]

Hi,

On Thu, Sep 18, 2014 at 01:00:34PM +0100, Martin Townsend wrote:
> Hi Alex,
> 
> On 18/09/14 11:43, Alexander Aring wrote:
> > On Thu, Sep 18, 2014 at 11:04:42AM +0100, Martin Townsend wrote:
> >> Hi Alex,
> >>
> >> If I'm following correctly you need to add a monitor interface as well as a node/coord interface to the PHY.  so we would see wpan0 and wpanmon0 and then I could do a
> >> tcpdump -i wpanmon0?
> >>
> > mhhh, no.
> >
> > It's a question of design to have NODE, COORD and MONITOR parallel.
> >
> > But when we have phy mac handling for a iftype we should not have this
> > parallel.
> >
> > We have multiple interfaces support, BUT only ONE phy.
> >
> > The phy have also mac handling, like addressfilter XOR promiscousmode.
> >
> > The addressfilter doesn't interrupt the phy on ANY frame, only on frames
> > which belongs to us (the phy). That's why addressfilter makes sense on NODE and COORD.
> > After an interrupt the LINUX mac802154 stack also run a addressfilter to
> > be sure. (BUT only on NODE and COORD types).
> >
> > The MONITOR type bypass the mac802154 filters and send any frame to the
> > interface, then you can see it on wireshark. But this required to
> > disable the addressfilter of mac phy handling -> promiscousmode.
> >
> > Now having NODE and MONITOR parallel, you can't have promiscousmode and
> > addressfilter at the same time. promiscousmode disabled the
> > addressfilter. But then the LINUX mac802154 have a very workload because
> > it need to check any frame which is received on promiscousmode. This
> > isn't pracitcal, also promiscousmode isn't only addressfiltering also
> > CRC...
> Is monitor mode like the one in WIFI (rfmon)
> http://en.wikipedia.org/wiki/Monitor_mode
> Where it can't transmit packets, it basically turns the device into a packet sniffer?

I would says yea, but MONITOR can also transmit some packets. It's for
me something like a big playground for userspace. Doesn't make any
kernelspace handling and forward all frames into userspace. So you can
capture it.

> >
> > When you enable the promiscousmode on WPAN/NODE interface you only
> > enable that your cpu load increases because you don't have any phy
> > addressfilter anymore, then mac802154 do the job for you and remember a
> > MONITOR device bypass the mac802154 filtering, then you see ONLY on a
> > MONITOR interface every frame. Also frames which not in your pan or doesn'
> > belong to you. That's what's the monitor interface does.
> >
> >
> > More understandable? :/
> Basically I want to be able to run tcpdump on wpan0 to capture packets but not effect the functionality of device so if it's a node or coordinator it carries on acting like one and the packet traffic capture would reflect this.  So if I'm running as a coordinator and want to see RPL traffic that the coordinator generates and receives I can do this.
> My understanding is that I put the WPAN interface into promiscuous mode to do this.  I accept that the CPU will come under more load but we are only talking about a 256kbps link.  If you a running a linux distribution chances are you are using a fairly powerful ARM or equivalent processor.
> Are we saying this is not possible?
> 

I think you only want to have a wireshark on a interface.

wireshark/tcpdump whatever tolds you that the device is into
promiscousmode. But this doesn't change anything also for wireless
(802.11) because the multiple interface types, it's hard to handle it to change
this during runtime. This is some historial issue when you don't have
interface types like ethernet.


I think we need to clarify that promiscousmode in a NODE/COORD makes no
sense.

In userspace what you receive via wireshark/tcpdump makes no different
(should not do any different) if you are in promiscousmode or not. Because
the mac802154 filter packets like when the phy mac filters is
activated.

If you have a MONITOR type, there is no mac802154 filter activated. And
I mean with mac802154 the stack implementation of Linux kernel.


Repeat:

If you have promiscousmode and NODE/COORD then you only increase the cpu
load and there is (should) no different in userspace by capture with
wireshark/tcpdump. You don't get more frames behind the mac802154 filter.

On MONITOR type this differs, because you don't have the mac802154 filter.


Or I don't understand 100% what you meant here, sorry.

- Alex

Re: Promiscuous patches

[Alexander Aring]

On Thu, Sep 18, 2014 at 02:21:40PM +0200, Alexander Aring wrote:
...
> 
> I think you only want to have a wireshark on a interface.
> 
> wireshark/tcpdump whatever tolds you that the device is into
> promiscousmode. But this doesn't change anything also for wireless
> (802.11) because the multiple interface types, it's hard to handle it to change
> this during runtime. This is some historial issue when you don't have
> interface types like ethernet.
> 
> 
> I think we need to clarify that promiscousmode in a NODE/COORD makes no
> sense.
> 
> In userspace what you receive via wireshark/tcpdump makes no different
> (should not do any different) if you are in promiscousmode or not. Because
> the mac802154 filter packets like when the phy mac filters is
> activated.
> 
> If you have a MONITOR type, there is no mac802154 filter activated. And
> I mean with mac802154 the stack implementation of Linux kernel.
> 
> 
> Repeat:
> 
> If you have promiscousmode and NODE/COORD then you only increase the cpu
> load and there is (should) no different in userspace by capture with
> wireshark/tcpdump. You don't get more frames behind the mac802154 filter.
> 
> On MONITOR type this differs, because you don't have the mac802154 filter.
> 
> 
> Or I don't understand 100% what you meant here, sorry.
> 

I read now description of [0].

And now what 802.15.4-2011 says about the promiscousmode:

The second level of filtering shall be dependent on whether the MAC sublayer is currently operating in
promiscuous mode. In promiscuous mode, the MAC sublayer shall pass all frames received after the first
filter directly to the upper layers without applying any more filtering or processing. The MAC sublayer shall
be in promiscuous mode if macPromiscuousMode is set to TRUE.

There is lot of other description "simple disable all filtering". There
is no word about association with pan'ss.

This is for me the MONITOR mode. So MAYBE we could make some MONITOR
type which can associated with a PAN and then this can only show PAN
traffic. But when we can do this, when we support association with
pan's. :-) Then it's like promiscousmode what's desribed at [0].


[0] http://airsnort.shmoo.com/faq.html#Q3

Re: Promiscuous patches

[Alexander Aring]

On Thu, Sep 18, 2014 at 02:30:24PM +0200, Alexander Aring wrote:
> On Thu, Sep 18, 2014 at 02:21:40PM +0200, Alexander Aring wrote:
> ...
> > 
> > I think you only want to have a wireshark on a interface.
> > 
> > wireshark/tcpdump whatever tolds you that the device is into
> > promiscousmode. But this doesn't change anything also for wireless
> > (802.11) because the multiple interface types, it's hard to handle it to change
> > this during runtime. This is some historial issue when you don't have
> > interface types like ethernet.
> > 
> > 
> > I think we need to clarify that promiscousmode in a NODE/COORD makes no
> > sense.
> > 
> > In userspace what you receive via wireshark/tcpdump makes no different
> > (should not do any different) if you are in promiscousmode or not. Because
> > the mac802154 filter packets like when the phy mac filters is
> > activated.
> > 
> > If you have a MONITOR type, there is no mac802154 filter activated. And
> > I mean with mac802154 the stack implementation of Linux kernel.
> > 
> > 
> > Repeat:
> > 
> > If you have promiscousmode and NODE/COORD then you only increase the cpu
> > load and there is (should) no different in userspace by capture with
> > wireshark/tcpdump. You don't get more frames behind the mac802154 filter.
> > 
> > On MONITOR type this differs, because you don't have the mac802154 filter.
> > 
> > 
> > Or I don't understand 100% what you meant here, sorry.
> > 
> 
> I read now description of [0].
> 
> And now what 802.15.4-2011 says about the promiscousmode:
> 
> The second level of filtering shall be dependent on whether the MAC sublayer is currently operating in
> promiscuous mode. In promiscuous mode, the MAC sublayer shall pass all frames received after the first
> filter directly to the upper layers without applying any more filtering or processing. The MAC sublayer shall
> be in promiscuous mode if macPromiscuousMode is set to TRUE.
> 
> There is lot of other description "simple disable all filtering". There
> is no word about association with pan'ss.
> 
> This is for me the MONITOR mode. So MAYBE we could make some MONITOR
> type which can associated with a PAN and then this can only show PAN
> traffic. But when we can do this, when we support association with
> pan's. :-) Then it's like promiscousmode what's desribed at [0].
> 

or simple change the wireshark filters that you only get frames with
panid 0xbeef, or something else.

MONITOR and promiscousmode according 802.15.4-2011 simple means, disable
filtering for me. :/

I really not sure about that I understand what you want to do now with
promiscousmode.

- Alex

Re: Promiscuous patches

[Martin Townsend]

On 18/09/14 13:44, Alexander Aring wrote:
> On Thu, Sep 18, 2014 at 02:30:24PM +0200, Alexander Aring wrote:
>> On Thu, Sep 18, 2014 at 02:21:40PM +0200, Alexander Aring wrote:
>> ...
>>> I think you only want to have a wireshark on a interface.
>>>
>>> wireshark/tcpdump whatever tolds you that the device is into
>>> promiscousmode. But this doesn't change anything also for wireless
>>> (802.11) because the multiple interface types, it's hard to handle it to change
>>> this during runtime. This is some historial issue when you don't have
>>> interface types like ethernet.
>>>
>>>
>>> I think we need to clarify that promiscousmode in a NODE/COORD makes no
>>> sense.
>>>
>>> In userspace what you receive via wireshark/tcpdump makes no different
>>> (should not do any different) if you are in promiscousmode or not. Because
>>> the mac802154 filter packets like when the phy mac filters is
>>> activated.
>>>
>>> If you have a MONITOR type, there is no mac802154 filter activated. And
>>> I mean with mac802154 the stack implementation of Linux kernel.
>>>
>>>
>>> Repeat:
>>>
>>> If you have promiscousmode and NODE/COORD then you only increase the cpu
>>> load and there is (should) no different in userspace by capture with
>>> wireshark/tcpdump. You don't get more frames behind the mac802154 filter.
>>>
>>> On MONITOR type this differs, because you don't have the mac802154 filter.
>>>
>>>
>>> Or I don't understand 100% what you meant here, sorry.
>>>
>> I read now description of [0].
>>
>> And now what 802.15.4-2011 says about the promiscousmode:
>>
>> The second level of filtering shall be dependent on whether the MAC sublayer is currently operating in
>> promiscuous mode. In promiscuous mode, the MAC sublayer shall pass all frames received after the first
>> filter directly to the upper layers without applying any more filtering or processing. The MAC sublayer shall
>> be in promiscuous mode if macPromiscuousMode is set to TRUE.
>>
>> There is lot of other description "simple disable all filtering". There
>> is no word about association with pan'ss.
>>
>> This is for me the MONITOR mode. So MAYBE we could make some MONITOR
>> type which can associated with a PAN and then this can only show PAN
>> traffic. But when we can do this, when we support association with
>> pan's. :-) Then it's like promiscousmode what's desribed at [0].
>>
> or simple change the wireshark filters that you only get frames with
> panid 0xbeef, or something else.
>
> MONITOR and promiscousmode according 802.15.4-2011 simple means, disable
> filtering for me. :/
>
> I really not sure about that I understand what you want to do now with
> promiscousmode.
I want to be able from COORD or NODE mode to put the device in promiscuous mode so packets can be received by wireshark.  For example if we are seeing a problem on a device, I want to be able to ssh into this node via Ethernet (or maybe connect via the serial console) and run tcpdump -U -i wpan0 to help debugging by seeing what packets are being sent/received.  As it's going to stdout it will be sent over ssh and I can then do some pipe redirection to pipe it into Wireshark running on a different machine.

 From my understanding this is not MONITOR mode and I don't won't to put the device into MONITOR mode as this could effect it's functionality.
I'm currently looking at how tcpdump does this and it looks like it uses a raw socket using PF_PACKET.  I think it then sets the IFF_PROMISC flag on this socket to put the device into promiscuous mode.  As I'm in COORD or NODE mode this will arrive at the ndo_change_rx_flags for the net device ops defined in wpan.c not monitor.c in my linux tree.

I notice in your linux-wpan-next alex/wip branch there is no wpan.c or monitor.c, and I can't see how I can be a COORD or NODE and capture packets.

- Martin.


>
> - Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Promiscuous patches

[Alexander Aring]

On Thu, Sep 18, 2014 at 02:25:15PM +0100, Martin Townsend wrote:
> 
> On 18/09/14 13:44, Alexander Aring wrote:
> > On Thu, Sep 18, 2014 at 02:30:24PM +0200, Alexander Aring wrote:
> >> On Thu, Sep 18, 2014 at 02:21:40PM +0200, Alexander Aring wrote:
> >> ...
> >>> I think you only want to have a wireshark on a interface.
> >>>
> >>> wireshark/tcpdump whatever tolds you that the device is into
> >>> promiscousmode. But this doesn't change anything also for wireless
> >>> (802.11) because the multiple interface types, it's hard to handle it to change
> >>> this during runtime. This is some historial issue when you don't have
> >>> interface types like ethernet.
> >>>
> >>>
> >>> I think we need to clarify that promiscousmode in a NODE/COORD makes no
> >>> sense.
> >>>
> >>> In userspace what you receive via wireshark/tcpdump makes no different
> >>> (should not do any different) if you are in promiscousmode or not. Because
> >>> the mac802154 filter packets like when the phy mac filters is
> >>> activated.
> >>>
> >>> If you have a MONITOR type, there is no mac802154 filter activated. And
> >>> I mean with mac802154 the stack implementation of Linux kernel.
> >>>
> >>>
> >>> Repeat:
> >>>
> >>> If you have promiscousmode and NODE/COORD then you only increase the cpu
> >>> load and there is (should) no different in userspace by capture with
> >>> wireshark/tcpdump. You don't get more frames behind the mac802154 filter.
> >>>
> >>> On MONITOR type this differs, because you don't have the mac802154 filter.
> >>>
> >>>
> >>> Or I don't understand 100% what you meant here, sorry.
> >>>
> >> I read now description of [0].
> >>
> >> And now what 802.15.4-2011 says about the promiscousmode:
> >>
> >> The second level of filtering shall be dependent on whether the MAC sublayer is currently operating in
> >> promiscuous mode. In promiscuous mode, the MAC sublayer shall pass all frames received after the first
> >> filter directly to the upper layers without applying any more filtering or processing. The MAC sublayer shall
> >> be in promiscuous mode if macPromiscuousMode is set to TRUE.
> >>
> >> There is lot of other description "simple disable all filtering". There
> >> is no word about association with pan'ss.
> >>
> >> This is for me the MONITOR mode. So MAYBE we could make some MONITOR
> >> type which can associated with a PAN and then this can only show PAN
> >> traffic. But when we can do this, when we support association with
> >> pan's. :-) Then it's like promiscousmode what's desribed at [0].
> >>
> > or simple change the wireshark filters that you only get frames with
> > panid 0xbeef, or something else.
> >
> > MONITOR and promiscousmode according 802.15.4-2011 simple means, disable
> > filtering for me. :/
> >
> > I really not sure about that I understand what you want to do now with
> > promiscousmode.
> I want to be able from COORD or NODE mode to put the device in promiscuous mode so packets can be received by wireshark.  For example if we are seeing a problem on a device, I want to be able to ssh into this node via Ethernet (or maybe connect via the serial console) and run tcpdump -U -i wpan0 to help debugging by seeing what packets are being sent/received.  As it's going to stdout it will be sent over ssh and I can then do some pipe redirection to pipe it into Wireshark running on a different machine.
> 
> From my understanding this is not MONITOR mode and I don't won't to put the device into MONITOR mode as this could effect it's functionality.
> I'm currently looking at how tcpdump does this and it looks like it uses a raw socket using PF_PACKET.  I think it then sets the IFF_PROMISC flag on this socket to put the device into promiscuous mode.  As I'm in COORD or NODE mode this will arrive at the ndo_change_rx_flags for the net device ops defined in wpan.c not monitor.c in my linux tree.
> 
> I notice in your linux-wpan-next alex/wip branch there is no wpan.c or monitor.c, and I can't see how I can be a COORD or NODE and capture packets.
> 

Then you simple need to rum wireshark/tcpdump etc.

I use:

"ssh root@$IP 'tshark -i wpan0 -w -' | wireshark -k -i -"

replace $IP with $IP of ethernet 802.15.4 node. Then you only see frames
with filtering and belongs to you and whatever any interface capture then.
Require ssh on both, tshark on target and wireshark on host.


What we talking about is promiscousmode setting according 802.15.4-2011.
With that you don't need to set any register setting, just start
capturing the interface. Also no special handling for IFF_PROMISC is
needed.

- Alex

Re: Promiscuous patches

[Alexander Aring]

On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
...
> > I want to be able from COORD or NODE mode to put the device in promiscuous mode so packets can be received by wireshark.  For example if we are seeing a problem on a device, I want to be able to ssh into this node via Ethernet (or maybe connect via the serial console) and run tcpdump -U -i wpan0 to help debugging by seeing what packets are being sent/received.  As it's going to stdout it will be sent over ssh and I can then do some pipe redirection to pipe it into Wireshark running on a different machine.
> > 
> > From my understanding this is not MONITOR mode and I don't won't to put the device into MONITOR mode as this could effect it's functionality.
> > I'm currently looking at how tcpdump does this and it looks like it uses a raw socket using PF_PACKET.  I think it then sets the IFF_PROMISC flag on this socket to put the device into promiscuous mode.  As I'm in COORD or NODE mode this will arrive at the ndo_change_rx_flags for the net device ops defined in wpan.c not monitor.c in my linux tree.

Has nothing to do with raw sockets, I think.

> > 
> > I notice in your linux-wpan-next alex/wip branch there is no wpan.c or monitor.c, and I can't see how I can be a COORD or NODE and capture packets.
> > 

ahh these types are only for the rework. Mainline is NODE = WPAN and
COORD doesn't exist.

COORD is the new type for handling some pan coordinator functionality
inside of kernelspace. Forget this.

> 
> Then you simple need to rum wireshark/tcpdump etc.
> 
> I use:
> 
> "ssh root@$IP 'tshark -i wpan0 -w -' | wireshark -k -i -"
> 
> replace $IP with $IP of ethernet 802.15.4 node. Then you only see frames
> with filtering and belongs to you and whatever any interface capture then.
> Require ssh on both, tshark on target and wireshark on host.
> 
> 
> What we talking about is promiscousmode setting according 802.15.4-2011.
> With that you don't need to set any register setting, just start
s/With/In this case/
> capturing the interface. Also no special handling for IFF_PROMISC is
> needed.

I hope we comming near to any solution what we both want. :-/

- Alex

Re: Promiscuous patches

[Martin Townsend]

On 18/09/14 14:42, Alexander Aring wrote:
> On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
> ...
>>> I want to be able from COORD or NODE mode to put the device in promiscuous mode so packets can be received by wireshark.  For example if we are seeing a problem on a device, I want to be able to ssh into this node via Ethernet (or maybe connect via the serial console) and run tcpdump -U -i wpan0 to help debugging by seeing what packets are being sent/received.  As it's going to stdout it will be sent over ssh and I can then do some pipe redirection to pipe it into Wireshark running on a different machine.
>>>
>>> From my understanding this is not MONITOR mode and I don't won't to put the device into MONITOR mode as this could effect it's functionality.
>>> I'm currently looking at how tcpdump does this and it looks like it uses a raw socket using PF_PACKET.  I think it then sets the IFF_PROMISC flag on this socket to put the device into promiscuous mode.  As I'm in COORD or NODE mode this will arrive at the ndo_change_rx_flags for the net device ops defined in wpan.c not monitor.c in my linux tree.
> Has nothing to do with raw sockets, I think.
I'm just going on what I'm seeing in libpcap, I think tshark and tcpdump both use this library.  If you have a debug environment setup, set a breakpoint on activate_new or look through pcap-linux.c, one of the first things it does is:
    sock_fd = is_any_device ?
        socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL)) :
        socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));

is_any_device should be set to false as we are capturing a specific device so we should be creating a raw socket.  Then later on
    if (!is_any_device && handle->opt.promisc) {
        memset(&mr, 0, sizeof(mr));
        mr.mr_ifindex = handlep->ifindex;
        mr.mr_type    = PACKET_MR_PROMISC;
        if (setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
            &mr, sizeof(mr)) == -1) {
            snprintf(handle->errbuf, PCAP_ERRBUF_SIZE,
                "setsockopt: %s", pcap_strerror(errno));
            close(sock_fd);
            return PCAP_ERROR;
        }
    }
Then I think this ends up in the kernel at packet_dev_mc
http://lxr.free-electrons.com/source/net/packet/af_packet.c#L3060
which calls dev_set_promiscuity.



>
>>> I notice in your linux-wpan-next alex/wip branch there is no wpan.c or monitor.c, and I can't see how I can be a COORD or NODE and capture packets.
>>>
> ahh these types are only for the rework. Mainline is NODE = WPAN and
> COORD doesn't exist.
>
> COORD is the new type for handling some pan coordinator functionality
> inside of kernelspace. Forget this.
>
>> Then you simple need to rum wireshark/tcpdump etc.
>>
>> I use:
>>
>> "ssh root@$IP 'tshark -i wpan0 -w -' | wireshark -k -i -"
>>
>> replace $IP with $IP of ethernet 802.15.4 node. Then you only see frames
>> with filtering and belongs to you and whatever any interface capture then.
>> Require ssh on both, tshark on target and wireshark on host.
>>
>>
>> What we talking about is promiscousmode setting according 802.15.4-2011.
>> With that you don't need to set any register setting, just start
> s/With/In this case/
>> capturing the interface. Also no special handling for IFF_PROMISC is
>> needed.
> I hope we comming near to any solution what we both want. :-/
I think I understand enough now to add what I need so I can keep this out of your linux-wpan mainline tree.  :)
> - Alex

- Martin.

Re: Promiscuous patches

[Alexander Aring]

Hi Martin,

On Thu, Sep 18, 2014 at 03:36:55PM +0100, Martin Townsend wrote:
> 
> On 18/09/14 14:42, Alexander Aring wrote:
> > On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
> > ...
> >>> I want to be able from COORD or NODE mode to put the device in promiscuous mode so packets can be received by wireshark.  For example if we are seeing a problem on a device, I want to be able to ssh into this node via Ethernet (or maybe connect via the serial console) and run tcpdump -U -i wpan0 to help debugging by seeing what packets are being sent/received.  As it's going to stdout it will be sent over ssh and I can then do some pipe redirection to pipe it into Wireshark running on a different machine.
> >>>
> >>> From my understanding this is not MONITOR mode and I don't won't to put the device into MONITOR mode as this could effect it's functionality.
> >>> I'm currently looking at how tcpdump does this and it looks like it uses a raw socket using PF_PACKET.  I think it then sets the IFF_PROMISC flag on this socket to put the device into promiscuous mode.  As I'm in COORD or NODE mode this will arrive at the ndo_change_rx_flags for the net device ops defined in wpan.c not monitor.c in my linux tree.
> > Has nothing to do with raw sockets, I think.
> I'm just going on what I'm seeing in libpcap, I think tshark and tcpdump both use this library.  If you have a debug environment setup, set a breakpoint on activate_new or look through pcap-linux.c, one of the first things it does is:
>     sock_fd = is_any_device ?
>         socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL)) :
>         socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
> 
> is_any_device should be set to false as we are capturing a specific device so we should be creating a raw socket.  Then later on
>     if (!is_any_device && handle->opt.promisc) {
>         memset(&mr, 0, sizeof(mr));
>         mr.mr_ifindex = handlep->ifindex;
>         mr.mr_type    = PACKET_MR_PROMISC;
>         if (setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
>             &mr, sizeof(mr)) == -1) {
>             snprintf(handle->errbuf, PCAP_ERRBUF_SIZE,
>                 "setsockopt: %s", pcap_strerror(errno));
>             close(sock_fd);
>             return PCAP_ERROR;
>         }
>     }
> Then I think this ends up in the kernel at packet_dev_mc
> http://lxr.free-electrons.com/source/net/packet/af_packet.c#L3060
> which calls dev_set_promiscuity.
> 

yes, there existing any magic for capturing all interface incomming and
outcomming data. But I don't know now how this is related currently.

You exacly want the incomming/outcomming data of an interface and that's
what the default behaviour is. There existing also some netdev flag
which activate this the "IFF_PROMISC". But then we don't need any
handling to turn the device driver into any special mode?

We already support the promiscuous mode. I mean the normal capturing of
interface data and this is the default behaviour, we don't need any
extra implementation to make something when rx flag IFF_PROMISC is set.

Is there something missing now, which we should support when activate
wireshark & co on a wpan interface?

- Alex

Re: Promiscuous patches

[Martin Townsend]

Hi Alex,

On 18/09/14 17:05, Alexander Aring wrote:
> Hi Martin,
>
> On Thu, Sep 18, 2014 at 03:36:55PM +0100, Martin Townsend wrote:
>> On 18/09/14 14:42, Alexander Aring wrote:
>>> On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
>>> ...
>>>>> I want to be able from COORD or NODE mode to put the device in promiscuous mode so packets can be received by wireshark.  For example if we are seeing a problem on a device, I want to be able to ssh into this node via Ethernet (or maybe connect via the serial console) and run tcpdump -U -i wpan0 to help debugging by seeing what packets are being sent/received.  As it's going to stdout it will be sent over ssh and I can then do some pipe redirection to pipe it into Wireshark running on a different machine.
>>>>>
>>>>>  From my understanding this is not MONITOR mode and I don't won't to put the device into MONITOR mode as this could effect it's functionality.
>>>>> I'm currently looking at how tcpdump does this and it looks like it uses a raw socket using PF_PACKET.  I think it then sets the IFF_PROMISC flag on this socket to put the device into promiscuous mode.  As I'm in COORD or NODE mode this will arrive at the ndo_change_rx_flags for the net device ops defined in wpan.c not monitor.c in my linux tree.
>>> Has nothing to do with raw sockets, I think.
>> I'm just going on what I'm seeing in libpcap, I think tshark and tcpdump both use this library.  If you have a debug environment setup, set a breakpoint on activate_new or look through pcap-linux.c, one of the first things it does is:
>>      sock_fd = is_any_device ?
>>          socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL)) :
>>          socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
>>
>> is_any_device should be set to false as we are capturing a specific device so we should be creating a raw socket.  Then later on
>>      if (!is_any_device && handle->opt.promisc) {
>>          memset(&mr, 0, sizeof(mr));
>>          mr.mr_ifindex = handlep->ifindex;
>>          mr.mr_type    = PACKET_MR_PROMISC;
>>          if (setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
>>              &mr, sizeof(mr)) == -1) {
>>              snprintf(handle->errbuf, PCAP_ERRBUF_SIZE,
>>                  "setsockopt: %s", pcap_strerror(errno));
>>              close(sock_fd);
>>              return PCAP_ERROR;
>>          }
>>      }
>> Then I think this ends up in the kernel at packet_dev_mc
>> http://lxr.free-electrons.com/source/net/packet/af_packet.c#L3060
>> which calls dev_set_promiscuity.
>>
> yes, there existing any magic for capturing all interface incomming and
> outcomming data. But I don't know now how this is related currently.
>
> You exacly want the incomming/outcomming data of an interface and that's
> what the default behaviour is. There existing also some netdev flag
> which activate this the "IFF_PROMISC". But then we don't need any
> handling to turn the device driver into any special mode?
>
> We already support the promiscuous mode. I mean the normal capturing of
> interface data and this is the default behaviour, we don't need any
> extra implementation to make something when rx flag IFF_PROMISC is set.
>
> Is there something missing now, which we should support when activate
> wireshark & co on a wpan interface?
>
> - Alex
I thought the default behaviour was to filter? Currently we implement 
the hw filter driver op function and our HW implements the third level 
of filtering as per 802.15.4 spec so by default we only get packets for 
our PAN/Address.  I think one of the user space functions, probably iz 
sends a netlink command which invokes the driver operation to set the 
filter up in the driver.
So I want to use set promisc to disable this HW filter and let all 
packets through.

- Martin.

Re: Promiscuous patches

[Alexander Aring]

Hi Martin,

On Thu, Sep 18, 2014 at 05:54:19PM +0100, Martin Townsend wrote:
> Hi Alex,
> 
> On 18/09/14 17:05, Alexander Aring wrote:
> >Hi Martin,
> >
> >On Thu, Sep 18, 2014 at 03:36:55PM +0100, Martin Townsend wrote:
> >>On 18/09/14 14:42, Alexander Aring wrote:
> >>>On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
> >>>...
> >>>>>I want to be able from COORD or NODE mode to put the device in promiscuous mode so packets can be received by wireshark.  For example if we are seeing a problem on a device, I want to be able to ssh into this node via Ethernet (or maybe connect via the serial console) and run tcpdump -U -i wpan0 to help debugging by seeing what packets are being sent/received.  As it's going to stdout it will be sent over ssh and I can then do some pipe redirection to pipe it into Wireshark running on a different machine.
> >>>>>
> >>>>> From my understanding this is not MONITOR mode and I don't won't to put the device into MONITOR mode as this could effect it's functionality.
> >>>>>I'm currently looking at how tcpdump does this and it looks like it uses a raw socket using PF_PACKET.  I think it then sets the IFF_PROMISC flag on this socket to put the device into promiscuous mode.  As I'm in COORD or NODE mode this will arrive at the ndo_change_rx_flags for the net device ops defined in wpan.c not monitor.c in my linux tree.
> >>>Has nothing to do with raw sockets, I think.
> >>I'm just going on what I'm seeing in libpcap, I think tshark and tcpdump both use this library.  If you have a debug environment setup, set a breakpoint on activate_new or look through pcap-linux.c, one of the first things it does is:
> >>     sock_fd = is_any_device ?
> >>         socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL)) :
> >>         socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
> >>
> >>is_any_device should be set to false as we are capturing a specific device so we should be creating a raw socket.  Then later on
> >>     if (!is_any_device && handle->opt.promisc) {
> >>         memset(&mr, 0, sizeof(mr));
> >>         mr.mr_ifindex = handlep->ifindex;
> >>         mr.mr_type    = PACKET_MR_PROMISC;
> >>         if (setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
> >>             &mr, sizeof(mr)) == -1) {
> >>             snprintf(handle->errbuf, PCAP_ERRBUF_SIZE,
> >>                 "setsockopt: %s", pcap_strerror(errno));
> >>             close(sock_fd);
> >>             return PCAP_ERROR;
> >>         }
> >>     }
> >>Then I think this ends up in the kernel at packet_dev_mc
> >>http://lxr.free-electrons.com/source/net/packet/af_packet.c#L3060
> >>which calls dev_set_promiscuity.
> >>
> >yes, there existing any magic for capturing all interface incomming and
> >outcomming data. But I don't know now how this is related currently.
> >
> >You exacly want the incomming/outcomming data of an interface and that's
> >what the default behaviour is. There existing also some netdev flag
> >which activate this the "IFF_PROMISC". But then we don't need any
> >handling to turn the device driver into any special mode?
> >
> >We already support the promiscuous mode. I mean the normal capturing of
> >interface data and this is the default behaviour, we don't need any
> >extra implementation to make something when rx flag IFF_PROMISC is set.
> >
> >Is there something missing now, which we should support when activate
> >wireshark & co on a wpan interface?
> >
> >- Alex
> I thought the default behaviour was to filter? Currently we implement the hw
> filter driver op function and our HW implements the third level of filtering
> as per 802.15.4 spec so by default we only get packets for our PAN/Address.
> I think one of the user space functions, probably iz sends a netlink command
> which invokes the driver operation to set the filter up in the driver.
> So I want to use set promisc to disable this HW filter and let all packets
> through.

But this is MONITOR iftype then "to see all packets without filtering".
Doing a ifup on a MONITOR interface will enable the HW promiscuous mode.

Then you need also to disable the linux address filtering -> mac802154
and a MONITOR interface bypass this filtering.

This behaviour is not currently at mainline. But you also want to
interact as a normal node? I don't follow right now.



Doing a ifup on a NODE/WPAN enables normal hw address filtering.

Then you need also to enable the linux address filtering -> mac802154
and a NODE interface does not bypass the filtering. Because we need to
be sure that's belong to us and sending pkt_type, etc...

- Alex

Re: Promiscuous patches

[Alexander Aring]

Again me,

On Thu, Sep 18, 2014 at 07:07:24PM +0200, Alexander Aring wrote:
> Hi Martin,
> 
> On Thu, Sep 18, 2014 at 05:54:19PM +0100, Martin Townsend wrote:
> > Hi Alex,
> > 
> > On 18/09/14 17:05, Alexander Aring wrote:
> > >Hi Martin,
> > >
> > >On Thu, Sep 18, 2014 at 03:36:55PM +0100, Martin Townsend wrote:
> > >>On 18/09/14 14:42, Alexander Aring wrote:
> > >>>On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
> > >>>...
> > >>>>>I want to be able from COORD or NODE mode to put the device in promiscuous mode so packets can be received by wireshark.  For example if we are seeing a problem on a device, I want to be able to ssh into this node via Ethernet (or maybe connect via the serial console) and run tcpdump -U -i wpan0 to help debugging by seeing what packets are being sent/received.  As it's going to stdout it will be sent over ssh and I can then do some pipe redirection to pipe it into Wireshark running on a different machine.
> > >>>>>
> > >>>>> From my understanding this is not MONITOR mode and I don't won't to put the device into MONITOR mode as this could effect it's functionality.
> > >>>>>I'm currently looking at how tcpdump does this and it looks like it uses a raw socket using PF_PACKET.  I think it then sets the IFF_PROMISC flag on this socket to put the device into promiscuous mode.  As I'm in COORD or NODE mode this will arrive at the ndo_change_rx_flags for the net device ops defined in wpan.c not monitor.c in my linux tree.
> > >>>Has nothing to do with raw sockets, I think.
> > >>I'm just going on what I'm seeing in libpcap, I think tshark and tcpdump both use this library.  If you have a debug environment setup, set a breakpoint on activate_new or look through pcap-linux.c, one of the first things it does is:
> > >>     sock_fd = is_any_device ?
> > >>         socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL)) :
> > >>         socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
> > >>
> > >>is_any_device should be set to false as we are capturing a specific device so we should be creating a raw socket.  Then later on
> > >>     if (!is_any_device && handle->opt.promisc) {
> > >>         memset(&mr, 0, sizeof(mr));
> > >>         mr.mr_ifindex = handlep->ifindex;
> > >>         mr.mr_type    = PACKET_MR_PROMISC;
> > >>         if (setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
> > >>             &mr, sizeof(mr)) == -1) {
> > >>             snprintf(handle->errbuf, PCAP_ERRBUF_SIZE,
> > >>                 "setsockopt: %s", pcap_strerror(errno));
> > >>             close(sock_fd);
> > >>             return PCAP_ERROR;
> > >>         }
> > >>     }
> > >>Then I think this ends up in the kernel at packet_dev_mc
> > >>http://lxr.free-electrons.com/source/net/packet/af_packet.c#L3060
> > >>which calls dev_set_promiscuity.
> > >>
> > >yes, there existing any magic for capturing all interface incomming and
> > >outcomming data. But I don't know now how this is related currently.
> > >
> > >You exacly want the incomming/outcomming data of an interface and that's
> > >what the default behaviour is. There existing also some netdev flag
> > >which activate this the "IFF_PROMISC". But then we don't need any
> > >handling to turn the device driver into any special mode?
> > >
> > >We already support the promiscuous mode. I mean the normal capturing of
> > >interface data and this is the default behaviour, we don't need any
> > >extra implementation to make something when rx flag IFF_PROMISC is set.
> > >
> > >Is there something missing now, which we should support when activate
> > >wireshark & co on a wpan interface?
> > >
> > >- Alex
> > I thought the default behaviour was to filter? Currently we implement the hw
> > filter driver op function and our HW implements the third level of filtering
> > as per 802.15.4 spec so by default we only get packets for our PAN/Address.
> > I think one of the user space functions, probably iz sends a netlink command
> > which invokes the driver operation to set the filter up in the driver.
> > So I want to use set promisc to disable this HW filter and let all packets
> > through.
> 
> But this is MONITOR iftype then "to see all packets without filtering".
> Doing a ifup on a MONITOR interface will enable the HW promiscuous mode.
> 
do hw promiscuous while setting IFF_PROMISC, please don't do this. It isn't
easy to handle because we have these multiple interfaces tupes. Simple have a
monitor interface type which enables HW promiscuous mode while interface
up. (ifconfig foo0 up, ip set link dev foo0 up)

Again look at rework code what I did there [0].

- Alex

[0] https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/mac802154/iface.c#L42

Re: Promiscuous patches

[Alexander Aring]

On Thu, Sep 18, 2014 at 07:54:05PM +0200, Alexander Aring wrote:
> Again me,
> 
> On Thu, Sep 18, 2014 at 07:07:24PM +0200, Alexander Aring wrote:
> > Hi Martin,
> > 
> > On Thu, Sep 18, 2014 at 05:54:19PM +0100, Martin Townsend wrote:
> > > Hi Alex,
> > > 
> > > On 18/09/14 17:05, Alexander Aring wrote:
> > > >Hi Martin,
> > > >
> > > >On Thu, Sep 18, 2014 at 03:36:55PM +0100, Martin Townsend wrote:
> > > >>On 18/09/14 14:42, Alexander Aring wrote:
> > > >>>On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
> > > >>>...
> > > >>>>>I want to be able from COORD or NODE mode to put the device in promiscuous mode so packets can be received by wireshark.  For example if we are seeing a problem on a device, I want to be able to ssh into this node via Ethernet (or maybe connect via the serial console) and run tcpdump -U -i wpan0 to help debugging by seeing what packets are being sent/received.  As it's going to stdout it will be sent over ssh and I can then do some pipe redirection to pipe it into Wireshark running on a different machine.
> > > >>>>>
> > > >>>>> From my understanding this is not MONITOR mode and I don't won't to put the device into MONITOR mode as this could effect it's functionality.
> > > >>>>>I'm currently looking at how tcpdump does this and it looks like it uses a raw socket using PF_PACKET.  I think it then sets the IFF_PROMISC flag on this socket to put the device into promiscuous mode.  As I'm in COORD or NODE mode this will arrive at the ndo_change_rx_flags for the net device ops defined in wpan.c not monitor.c in my linux tree.
> > > >>>Has nothing to do with raw sockets, I think.
> > > >>I'm just going on what I'm seeing in libpcap, I think tshark and tcpdump both use this library.  If you have a debug environment setup, set a breakpoint on activate_new or look through pcap-linux.c, one of the first things it does is:
> > > >>     sock_fd = is_any_device ?
> > > >>         socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL)) :
> > > >>         socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
> > > >>
> > > >>is_any_device should be set to false as we are capturing a specific device so we should be creating a raw socket.  Then later on
> > > >>     if (!is_any_device && handle->opt.promisc) {
> > > >>         memset(&mr, 0, sizeof(mr));
> > > >>         mr.mr_ifindex = handlep->ifindex;
> > > >>         mr.mr_type    = PACKET_MR_PROMISC;
> > > >>         if (setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
> > > >>             &mr, sizeof(mr)) == -1) {
> > > >>             snprintf(handle->errbuf, PCAP_ERRBUF_SIZE,
> > > >>                 "setsockopt: %s", pcap_strerror(errno));
> > > >>             close(sock_fd);
> > > >>             return PCAP_ERROR;
> > > >>         }
> > > >>     }
> > > >>Then I think this ends up in the kernel at packet_dev_mc
> > > >>http://lxr.free-electrons.com/source/net/packet/af_packet.c#L3060
> > > >>which calls dev_set_promiscuity.
> > > >>
> > > >yes, there existing any magic for capturing all interface incomming and
> > > >outcomming data. But I don't know now how this is related currently.
> > > >
> > > >You exacly want the incomming/outcomming data of an interface and that's
> > > >what the default behaviour is. There existing also some netdev flag
> > > >which activate this the "IFF_PROMISC". But then we don't need any
> > > >handling to turn the device driver into any special mode?
> > > >
> > > >We already support the promiscuous mode. I mean the normal capturing of
> > > >interface data and this is the default behaviour, we don't need any
> > > >extra implementation to make something when rx flag IFF_PROMISC is set.
> > > >
> > > >Is there something missing now, which we should support when activate
> > > >wireshark & co on a wpan interface?
> > > >
> > > >- Alex
> > > I thought the default behaviour was to filter? Currently we implement the hw
> > > filter driver op function and our HW implements the third level of filtering
> > > as per 802.15.4 spec so by default we only get packets for our PAN/Address.
> > > I think one of the user space functions, probably iz sends a netlink command
> > > which invokes the driver operation to set the filter up in the driver.
> > > So I want to use set promisc to disable this HW filter and let all packets
> > > through.
> > 
> > But this is MONITOR iftype then "to see all packets without filtering".
> > Doing a ifup on a MONITOR interface will enable the HW promiscuous mode.
> > 
> do hw promiscuous while setting IFF_PROMISC, please don't do this. It isn't
> easy to handle because we have these multiple interfaces tupes. Simple have a
> monitor interface type which enables HW promiscuous mode while interface
> up. (ifconfig foo0 up, ip set link dev foo0 up)
> 
> Again look at rework code what I did there [0].
> 

and I hope we clarified now that promiscuous mode with NODE/WPAN type
doesn't make any sense than increasing cpu load. You don't get more
frames into userspace.

- Alex

Re: Promiscuous patches

[Martin Townsend]

Hi Alex
On 18/09/14 18:56, Alexander Aring wrote:
> On Thu, Sep 18, 2014 at 07:54:05PM +0200, Alexander Aring wrote:
>> Again me,
>>
>> On Thu, Sep 18, 2014 at 07:07:24PM +0200, Alexander Aring wrote:
>>> Hi Martin,
>>>
>>> On Thu, Sep 18, 2014 at 05:54:19PM +0100, Martin Townsend wrote:
>>>> Hi Alex,
>>>>
>>>> On 18/09/14 17:05, Alexander Aring wrote:
>>>>> Hi Martin,
>>>>>
>>>>> On Thu, Sep 18, 2014 at 03:36:55PM +0100, Martin Townsend wrote:
>>>>>> On 18/09/14 14:42, Alexander Aring wrote:
>>>>>>> On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
>>>>>>> ...
>>>>>>>>> I want to be able from COORD or NODE mode to put the device in promiscuous mode so packets can be received by wireshark.  For example if we are seeing a problem on a device, I want to be able to ssh into this node via Ethernet (or maybe connect via the serial console) and run tcpdump -U -i wpan0 to help debugging by seeing what packets are being sent/received.  As it's going to stdout it will be sent over ssh and I can then do some pipe redirection to pipe it into Wireshark running on a different machine.
>>>>>>>>>
>>>>>>>>>  From my understanding this is not MONITOR mode and I don't won't to put the device into MONITOR mode as this could effect it's functionality.
>>>>>>>>> I'm currently looking at how tcpdump does this and it looks like it uses a raw socket using PF_PACKET.  I think it then sets the IFF_PROMISC flag on this socket to put the device into promiscuous mode.  As I'm in COORD or NODE mode this will arrive at the ndo_change_rx_flags for the net device ops defined in wpan.c not monitor.c in my linux tree.
>>>>>>> Has nothing to do with raw sockets, I think.
>>>>>> I'm just going on what I'm seeing in libpcap, I think tshark and tcpdump both use this library.  If you have a debug environment setup, set a breakpoint on activate_new or look through pcap-linux.c, one of the first things it does is:
>>>>>>      sock_fd = is_any_device ?
>>>>>>          socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL)) :
>>>>>>          socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
>>>>>>
>>>>>> is_any_device should be set to false as we are capturing a specific device so we should be creating a raw socket.  Then later on
>>>>>>      if (!is_any_device && handle->opt.promisc) {
>>>>>>          memset(&mr, 0, sizeof(mr));
>>>>>>          mr.mr_ifindex = handlep->ifindex;
>>>>>>          mr.mr_type    = PACKET_MR_PROMISC;
>>>>>>          if (setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
>>>>>>              &mr, sizeof(mr)) == -1) {
>>>>>>              snprintf(handle->errbuf, PCAP_ERRBUF_SIZE,
>>>>>>                  "setsockopt: %s", pcap_strerror(errno));
>>>>>>              close(sock_fd);
>>>>>>              return PCAP_ERROR;
>>>>>>          }
>>>>>>      }
>>>>>> Then I think this ends up in the kernel at packet_dev_mc
>>>>>> http://lxr.free-electrons.com/source/net/packet/af_packet.c#L3060
>>>>>> which calls dev_set_promiscuity.
>>>>>>
>>>>> yes, there existing any magic for capturing all interface incomming and
>>>>> outcomming data. But I don't know now how this is related currently.
>>>>>
>>>>> You exacly want the incomming/outcomming data of an interface and that's
>>>>> what the default behaviour is. There existing also some netdev flag
>>>>> which activate this the "IFF_PROMISC". But then we don't need any
>>>>> handling to turn the device driver into any special mode?
>>>>>
>>>>> We already support the promiscuous mode. I mean the normal capturing of
>>>>> interface data and this is the default behaviour, we don't need any
>>>>> extra implementation to make something when rx flag IFF_PROMISC is set.
>>>>>
>>>>> Is there something missing now, which we should support when activate
>>>>> wireshark & co on a wpan interface?
>>>>>
>>>>> - Alex
>>>> I thought the default behaviour was to filter? Currently we implement the hw
>>>> filter driver op function and our HW implements the third level of filtering
>>>> as per 802.15.4 spec so by default we only get packets for our PAN/Address.
>>>> I think one of the user space functions, probably iz sends a netlink command
>>>> which invokes the driver operation to set the filter up in the driver.
>>>> So I want to use set promisc to disable this HW filter and let all packets
>>>> through.
>>> But this is MONITOR iftype then "to see all packets without filtering".
>>> Doing a ifup on a MONITOR interface will enable the HW promiscuous mode.
>>>
>> do hw promiscuous while setting IFF_PROMISC, please don't do this. It isn't
>> easy to handle because we have these multiple interfaces tupes. Simple have a
>> monitor interface type which enables HW promiscuous mode while interface
>> up. (ifconfig foo0 up, ip set link dev foo0 up)
>>
>> Again look at rework code what I did there [0].
OK I will have look again at [0], I think I am missing something.
> and I hope we clarified now that promiscuous mode with NODE/WPAN type
> doesn't make any sense than increasing cpu load. You don't get more
> frames into userspace.
We are implementing 802.15.4 on powerline.  If we had say a peer to peer 
network involving 4 different PANs and because we aren't restricted by 
distance as much as wireless we could potentially put one of the 
Coordinator nodes into promiscuous mode and then capture traffic from 
all 4 PAN's whereas if we are filtering we only see the traffic for the 
PAN(s) we are involved in.  Wouldn't this be more frames that just the 
filter?

> - Alex
- Martin.
- Martin

Re: Promiscuous patches

[Alexander Aring]

On Thu, Sep 18, 2014 at 07:30:34PM +0100, Martin Townsend wrote:
...
> >and I hope we clarified now that promiscuous mode with NODE/WPAN type
> >doesn't make any sense than increasing cpu load. You don't get more
> >frames into userspace.
> We are implementing 802.15.4 on powerline.  If we had say a peer to peer
> network involving 4 different PANs and because we aren't restricted by
> distance as much as wireless we could potentially put one of the Coordinator
> nodes into promiscuous mode and then capture traffic from all 4 PAN's
> whereas if we are filtering we only see the traffic for the PAN(s) we are
> involved in.  Wouldn't this be more frames that just the filter?
> 

I can't follow, with monitor interface you will get any frame from pans,
also all frame types like ACK's etc... you can also send some frames
(okay the 802.15.4 standard doesn't say that) but at86rf231 seems to
allow this.

I need to show you moooore implementation details, then you know what a
WPAN/NODE type does on receiving and MONITOR will do on receiving.

WPAN/NODE/COORD -> have hardwware filtering, addresses, FCS etc..

MONITOR -> Doesn't filter anything, okay it filters when a SFD was
           receivied but nothing more.

Now LINUX the "mac802154" does also do filtering stuff, but only on
WPAN/NODE/COORD because these are to interact practical in a network,
not just sniffing.

On WPAN/NODE/COORD we have filter in mac802154, see [0]. This shows
frame parsing of data frames. You can more look into this how this works.
Now if you have address filter on PHY you will decreasing the load of
mac802154, because most of these frames are already filtered by the phy.

NOW if you set promiscuous mode on WPAN/NODE you increasing workload but
the most frames will dropped at [0]. You don't get more frames into the
interface (userspace). You only increasing the workload of the cpu.


On Monitor interface the PHY doesn't filter anything and the filtering
of [0] is disabled. It's directly send it to the interface so you can
see all frames, also frames which doesn't belong to you.
What a monitor interface does on receiving is [1]. Don't check anything
directly send it to the MONITOR interface. That's why I said "the
monitor interface is a big userspace playground - no filtering on PHY
and kernel is involved".

- Alex

[0] https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/mac802154/rx.c#L72
[1] https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/mac802154/rx.c#L289

Re: Promiscuous patches

[Alexander Aring]

On Thu, Sep 18, 2014 at 08:53:48PM +0200, Alexander Aring wrote:
> On Thu, Sep 18, 2014 at 07:30:34PM +0100, Martin Townsend wrote:
> ...
> > >and I hope we clarified now that promiscuous mode with NODE/WPAN type
> > >doesn't make any sense than increasing cpu load. You don't get more
> > >frames into userspace.
> > We are implementing 802.15.4 on powerline.  If we had say a peer to peer
> > network involving 4 different PANs and because we aren't restricted by
> > distance as much as wireless we could potentially put one of the Coordinator
> > nodes into promiscuous mode and then capture traffic from all 4 PAN's
> > whereas if we are filtering we only see the traffic for the PAN(s) we are
> > involved in.  Wouldn't this be more frames that just the filter?
> > 
> 
> I can't follow, with monitor interface you will get any frame from pans,
> also all frame types like ACK's etc... you can also send some frames
> (okay the 802.15.4 standard doesn't say that) but at86rf231 seems to
> allow this.
> 
> I need to show you moooore implementation details, then you know what a
> WPAN/NODE type does on receiving and MONITOR will do on receiving.
> 
> WPAN/NODE/COORD -> have hardwware filtering, addresses, FCS etc..
> 
> MONITOR -> Doesn't filter anything, okay it filters when a SFD was
>            receivied but nothing more.
> 
> Now LINUX the "mac802154" does also do filtering stuff, but only on
> WPAN/NODE/COORD because these are to interact practical in a network,
> not just sniffing.
> 
> On WPAN/NODE/COORD we have filter in mac802154, see [0]. This shows
> frame parsing of data frames. You can more look into this how this works.
> Now if you have address filter on PHY you will decreasing the load of
> mac802154, because most of these frames are already filtered by the phy.
> 
> NOW if you set promiscuous mode on WPAN/NODE you increasing workload but
> the most frames will dropped at [0]. You don't get more frames into the
> interface (userspace). You only increasing the workload of the cpu.
> 
> 
> On Monitor interface the PHY doesn't filter anything and the filtering
> of [0] is disabled. It's directly send it to the interface so you can
> see all frames, also frames which doesn't belong to you.
> What a monitor interface does on receiving is [1]. Don't check anything
> directly send it to the MONITOR interface. That's why I said "the
> monitor interface is a big userspace playground - no filtering on PHY
> and kernel is involved".
> 

Is there maybe some practical use for being in promiscuous mode and
operate as coordinator/node? Is that what you want?

Because at the moment you need to ifconfig down/ip set link dev foo0
down on all non monitor interfaces and up then a monitor interfaces to
get all unfiltered frames. After that you can do wireshark -i monitor0
or something else... to debug network traffic.

I see no sense to run promiscuous mode while coordinator/node. I think
more to handle this correctly would make the stack much complicated.

- Alex

Re: Promiscuous patches

[Alexander Aring]

On Thu, Sep 18, 2014 at 10:34:45PM +0200, Alexander Aring wrote:
> On Thu, Sep 18, 2014 at 08:53:48PM +0200, Alexander Aring wrote:
> > On Thu, Sep 18, 2014 at 07:30:34PM +0100, Martin Townsend wrote:
> > ...
> > > >and I hope we clarified now that promiscuous mode with NODE/WPAN type
> > > >doesn't make any sense than increasing cpu load. You don't get more
> > > >frames into userspace.
> > > We are implementing 802.15.4 on powerline.  If we had say a peer to peer
> > > network involving 4 different PANs and because we aren't restricted by
> > > distance as much as wireless we could potentially put one of the Coordinator
> > > nodes into promiscuous mode and then capture traffic from all 4 PAN's
> > > whereas if we are filtering we only see the traffic for the PAN(s) we are
> > > involved in.  Wouldn't this be more frames that just the filter?
> > > 
> > 
> > I can't follow, with monitor interface you will get any frame from pans,
> > also all frame types like ACK's etc... you can also send some frames
> > (okay the 802.15.4 standard doesn't say that) but at86rf231 seems to
> > allow this.
> > 
> > I need to show you moooore implementation details, then you know what a
> > WPAN/NODE type does on receiving and MONITOR will do on receiving.
> > 
> > WPAN/NODE/COORD -> have hardwware filtering, addresses, FCS etc..
> > 
> > MONITOR -> Doesn't filter anything, okay it filters when a SFD was
> >            receivied but nothing more.
> > 
> > Now LINUX the "mac802154" does also do filtering stuff, but only on
> > WPAN/NODE/COORD because these are to interact practical in a network,
> > not just sniffing.
> > 
> > On WPAN/NODE/COORD we have filter in mac802154, see [0]. This shows
> > frame parsing of data frames. You can more look into this how this works.
> > Now if you have address filter on PHY you will decreasing the load of
> > mac802154, because most of these frames are already filtered by the phy.
> > 
> > NOW if you set promiscuous mode on WPAN/NODE you increasing workload but
> > the most frames will dropped at [0]. You don't get more frames into the
> > interface (userspace). You only increasing the workload of the cpu.
> > 
> > 
> > On Monitor interface the PHY doesn't filter anything and the filtering
> > of [0] is disabled. It's directly send it to the interface so you can
> > see all frames, also frames which doesn't belong to you.
> > What a monitor interface does on receiving is [1]. Don't check anything
> > directly send it to the MONITOR interface. That's why I said "the
> > monitor interface is a big userspace playground - no filtering on PHY
> > and kernel is involved".
> > 
> 
> Is there maybe some practical use for being in promiscuous mode and
> operate as coordinator/node? Is that what you want?
> 

I see this could make also big trouble because ACK handling is disabled
in promiscuous mode. So in ARET networks this could really make trouble.
On at86rf231 there is a switch to enable/disable ack handling, datasheet
describes always to disable ACK handling there, need to look what
802.15.4-2011 says for this.

- Alex

Re: Promiscuous patches

[Martin Townsend]

Hi Alex,

I noticed the 802.15.4 spec mentions that when promiscuous mode is set 
it zeroes out the source and destination addressing mode of received 
packets which seems to suggest that the packet should not be handled by 
the stack also implying this is a monitor mode. Carry on with your 
design which I've had a chance to look through and it looks great.  I 
can implement whatever I need in a separate debug branch.

- Martin.

On 19/09/14 11:11, Alexander Aring wrote:
> On Thu, Sep 18, 2014 at 10:34:45PM +0200, Alexander Aring wrote:
>> On Thu, Sep 18, 2014 at 08:53:48PM +0200, Alexander Aring wrote:
>>> On Thu, Sep 18, 2014 at 07:30:34PM +0100, Martin Townsend wrote:
>>> ...
>>>>> and I hope we clarified now that promiscuous mode with NODE/WPAN type
>>>>> doesn't make any sense than increasing cpu load. You don't get more
>>>>> frames into userspace.
>>>> We are implementing 802.15.4 on powerline.  If we had say a peer to peer
>>>> network involving 4 different PANs and because we aren't restricted by
>>>> distance as much as wireless we could potentially put one of the Coordinator
>>>> nodes into promiscuous mode and then capture traffic from all 4 PAN's
>>>> whereas if we are filtering we only see the traffic for the PAN(s) we are
>>>> involved in.  Wouldn't this be more frames that just the filter?
>>>>
>>> I can't follow, with monitor interface you will get any frame from pans,
>>> also all frame types like ACK's etc... you can also send some frames
>>> (okay the 802.15.4 standard doesn't say that) but at86rf231 seems to
>>> allow this.
>>>
>>> I need to show you moooore implementation details, then you know what a
>>> WPAN/NODE type does on receiving and MONITOR will do on receiving.
>>>
>>> WPAN/NODE/COORD -> have hardwware filtering, addresses, FCS etc..
>>>
>>> MONITOR -> Doesn't filter anything, okay it filters when a SFD was
>>>             receivied but nothing more.
>>>
>>> Now LINUX the "mac802154" does also do filtering stuff, but only on
>>> WPAN/NODE/COORD because these are to interact practical in a network,
>>> not just sniffing.
>>>
>>> On WPAN/NODE/COORD we have filter in mac802154, see [0]. This shows
>>> frame parsing of data frames. You can more look into this how this works.
>>> Now if you have address filter on PHY you will decreasing the load of
>>> mac802154, because most of these frames are already filtered by the phy.
>>>
>>> NOW if you set promiscuous mode on WPAN/NODE you increasing workload but
>>> the most frames will dropped at [0]. You don't get more frames into the
>>> interface (userspace). You only increasing the workload of the cpu.
>>>
>>>
>>> On Monitor interface the PHY doesn't filter anything and the filtering
>>> of [0] is disabled. It's directly send it to the interface so you can
>>> see all frames, also frames which doesn't belong to you.
>>> What a monitor interface does on receiving is [1]. Don't check anything
>>> directly send it to the MONITOR interface. That's why I said "the
>>> monitor interface is a big userspace playground - no filtering on PHY
>>> and kernel is involved".
>>>
>> Is there maybe some practical use for being in promiscuous mode and
>> operate as coordinator/node? Is that what you want?
>>
> I see this could make also big trouble because ACK handling is disabled
> in promiscuous mode. So in ARET networks this could really make trouble.
> On at86rf231 there is a switch to enable/disable ack handling, datasheet
> describes always to disable ACK handling there, need to look what
> 802.15.4-2011 says for this.
>
> - Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Promiscuous patches

[Alexander Aring]

Hi Martin,

On Sat, Sep 20, 2014 at 08:03:33AM +0100, Martin Townsend wrote:
> Hi Alex,
> 
> I noticed the 802.15.4 spec mentions that when promiscuous mode is set it
> zeroes out the source and destination addressing mode of received packets
> which seems to suggest that the packet should not be handled by the stack
> also implying this is a monitor mode. Carry on with your design which I've
> had a chance to look through and it looks great.  I can implement whatever I
> need in a separate debug branch.
> 

this design is like mac80211 and removed all unnecessary things which we
don't need, just grab some ideas from. I feeling happy that you like that, thanks.
But note this isn't finished also names like ieee802154_hdr_foo, of
course I will not name it _foo, just for integration process. But there
are also some other issues/todos and need to find solutions.

- Alex