From: Alexander Aring <alex.aring@gmail.com>
To: Martin Townsend <martin.townsend@xsilon.com>
Cc: linux-wpan@vger.kernel.org
Subject: Re: Promiscuous patches
Date: Thu, 18 Sep 2014 14:44:30 +0200 [thread overview]
Message-ID: <20140918124430.GA8268@omega> (raw)
In-Reply-To: <20140918123024.GB6777@omega>
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
next prev parent reply other threads:[~2014-09-18 12:44 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 [this message]
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
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=20140918124430.GA8268@omega \
--to=alex.aring@gmail.com \
--cc=linux-wpan@vger.kernel.org \
--cc=martin.townsend@xsilon.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox