From: Martin Townsend <martin.townsend@xsilon.com>
To: Alexander Aring <alex.aring@gmail.com>
Cc: linux-wpan@vger.kernel.org
Subject: Re: Promiscuous patches
Date: Thu, 18 Sep 2014 17:54:19 +0100 [thread overview]
Message-ID: <541B0E3B.9000201@xsilon.com> (raw)
In-Reply-To: <20140918160458.GB9262@omega>
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.
next prev parent reply other threads:[~2014-09-18 16:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5412F199.7010803@xsilon.com>
2014-09-14 23:45 ` Promiscuous patches Alexander Aring
2014-09-14 23:56 ` Alexander Aring
2014-09-15 11:56 ` Alexander Aring
2014-09-15 12:01 ` Alexander Aring
2014-09-18 8:57 ` Martin Townsend
2014-09-18 9:41 ` Alexander Aring
2014-09-18 10:04 ` Martin Townsend
2014-09-18 10:43 ` Alexander Aring
2014-09-18 12:00 ` Martin Townsend
2014-09-18 12:21 ` Alexander Aring
2014-09-18 12:30 ` Alexander Aring
2014-09-18 12:44 ` Alexander Aring
2014-09-18 13:25 ` Martin Townsend
2014-09-18 13:34 ` Alexander Aring
2014-09-18 13:42 ` Alexander Aring
2014-09-18 14:36 ` Martin Townsend
2014-09-18 16:05 ` Alexander Aring
2014-09-18 16:54 ` Martin Townsend [this message]
2014-09-18 17:07 ` Alexander Aring
2014-09-18 17:54 ` Alexander Aring
2014-09-18 17:56 ` Alexander Aring
2014-09-18 18:30 ` Martin Townsend
2014-09-18 18:53 ` Alexander Aring
2014-09-18 20:34 ` Alexander Aring
2014-09-19 10:11 ` Alexander Aring
2014-09-20 7:03 ` Martin Townsend
2014-09-21 10:06 ` Alexander Aring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=541B0E3B.9000201@xsilon.com \
--to=martin.townsend@xsilon.com \
--cc=alex.aring@gmail.com \
--cc=linux-wpan@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.