Promiscuous patches

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.

Hi Martin,

Quoted 4 lines · Martin Townsend

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.

Quoted 15 lines · Alexander Aring

Hi Martin,

Quoted 4 lines · Martin Townsend

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.

Quoted 9 lines

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.

Quoted 30 lines · Alexander Aring

Quoted 15 lines · Alexander Aring

Hi Martin,

Quoted 4 lines · Martin Townsend

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.

Quoted 9 lines

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.

Quoted 9 lines

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.

Hi Martin,

Quoted 4 lines · Martin Townsend

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

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?

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.

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?

Quoted 5 lines · 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?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi Alex,

Quoted 26 lines · Alexander Aring

Quoted 5 lines · 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?

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.

Quoted 6 lines

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?

Quoted 9 lines

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.

Quoted 1 line

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.

On Thu, Sep 18, 2014 at 02:21:40PM +0200, Alexander Aring wrote:
...

Quoted 24 lines

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:

Quoted 9 lines

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

Quoted 43 lines · Alexander Aring

On Thu, Sep 18, 2014 at 02:21:40PM +0200, Alexander Aring wrote:
...

Quoted 23 lines

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:

Quoted 9 lines

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.

Quoted 8 lines

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
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 58 lines · Alexander Aring

Quoted 43 lines · Alexander Aring

On Thu, Sep 18, 2014 at 02:21:40PM +0200, Alexander Aring wrote:
...

Quoted 23 lines

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:

Quoted 9 lines

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.

Quoted 8 lines

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

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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.

On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
...

Quoted 4 lines

Quoted 4 lines

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.

Quoted 3 lines

Quoted 3 lines

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.

Quoted 11 lines

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.

Quoted 2 lines

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/

Quoted 2 lines

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

Quoted 7 lines · Alexander Aring

On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
...

Quoted 4 lines

Quoted 4 lines

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.

Hi Martin,

Quoted 26 lines · Martin Townsend

Quoted 7 lines · Alexander Aring

On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
...

Quoted 4 lines

Quoted 4 lines

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

Quoted 4 lines

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

Hi Alex,

Quoted 48 lines · Alexander Aring

Hi Martin,

Quoted 26 lines · Martin Townsend

Quoted 7 lines · Alexander Aring

On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
...

Quoted 4 lines

Quoted 4 lines

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

Quoted 4 lines

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?

Quoted 1 line

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

Hi Martin,

Quoted 51 lines · Martin Townsend

Hi Alex,

Quoted 48 lines · Alexander Aring

Hi Martin,

Quoted 26 lines · Martin Townsend

Quoted 7 lines · Alexander Aring

On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
...

Quoted 4 lines

Quoted 4 lines

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

Quoted 4 lines

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?

Quoted 8 lines

Quoted 1 line

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

Again me,

Quoted 63 lines · Alexander Aring

Hi Martin,

Quoted 51 lines · Martin Townsend

Hi Alex,

Quoted 48 lines · Alexander Aring

Hi Martin,

Quoted 26 lines · Martin Townsend

Quoted 7 lines · Alexander Aring

On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
...

Quoted 4 lines

Quoted 4 lines

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

Quoted 4 lines

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?

Quoted 8 lines

Quoted 1 line

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

Quoted 3 lines

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

Quoted 68 lines · Alexander Aring

Again me,

Quoted 65 lines · Alexander Aring

Hi Martin,

Quoted 51 lines · Martin Townsend

Hi Alex,

Quoted 48 lines · Alexander Aring

Hi Martin,

Quoted 26 lines · Martin Townsend

Quoted 7 lines · Alexander Aring

On Thu, Sep 18, 2014 at 03:34:24PM +0200, Alexander Aring wrote:
...

Quoted 4 lines

Quoted 4 lines

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

Quoted 4 lines

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?

Quoted 8 lines

Quoted 1 line

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

Quoted 6 lines

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

Quoted 3 lines

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?

On Thu, Sep 18, 2014 at 07:30:34PM +0100, Martin Townsend wrote:
...

Quoted 10 lines

Quoted 3 lines

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

Quoted 40 lines · Alexander Aring

On Thu, Sep 18, 2014 at 07:30:34PM +0100, Martin Townsend wrote:
...

Quoted 10 lines

Quoted 3 lines

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.

Quoted 8 lines

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?

Quoted 48 lines · Alexander Aring

Quoted 39 lines · Alexander Aring

On Thu, Sep 18, 2014 at 07:30:34PM +0100, Martin Townsend wrote:
...

Quoted 10 lines

Quoted 3 lines

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.

Quoted 8 lines

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

Quoted 3 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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.