* handling multiple MAC instances (multiple address filters)
@ 2017-07-12 17:10 Alexander Aring
2017-07-12 20:00 ` Michael Richardson
0 siblings, 1 reply; 6+ messages in thread
From: Alexander Aring @ 2017-07-12 17:10 UTC (permalink / raw)
To: linux-wpan; +Cc: mcr
Hi,
Michael requested to handle different pan's per 6lowpan interface,
because pan's are like VLANs etc. :-)
I told that for destination pan this is possible, but source pan's are
difficult, because most hardware has only _one_ address filters.
My idea was to going into promiscuous mode and let Linux filter all the
stuff when multiple address filters are required.
Then the discussed stopped after I took a shower and realized we lost
ack handling when going into promiscuous mode... The transceiver will
simple ack every frame which it's received then if we don't stop ack
handling.
This was the last state of the idea.
Now, after I looked because RX_SAFE_MODE into af86rf2xx datasheets
again. I think we could try to do the following:
- The same idea like above, transceiver will go into promiscuous mode if
we create multiple interfaces (MAC instances) on one phy, which allows
to run on different source PAN on each interface.
Explain slotted mode: In slotted mode we can send an ack or not over
toggle a pin (at86rf2xxx). The sequence number will be used which is
actually inside the framebuffer. The good thing is: We don't need to do
spi stuff and skb alloc for doing that (which takes long time).
How it would look like is:
- RX done irq comes
- Grab buffer information
- Doing fast a source address lookup and check if we have a mac
interface currently running which has the address and ack is
requested.
- If so trigger pin to send ack.
- If not do nothing and drop (because we are not meant)
Don't know if we can still keep all the timing stuff, but we don't need
to fiddle on our own to alloc skb and not do spi traffic for send ack
frame out. Could maybe work :-/
---
Another question is: Is running multiple interfaces on one PHY the thing
what we "need". I think yes, because the 802.15.4 spec describe only one
source PAN to operate on. Another idea would be to override src pan
setting per sendmsg(2), but it sounds weird that a wpan interface will
receive frames from two different pans and _all_ socket connection need
to filter source pans per recvmsg(2) then.
What you can simple do is to run multiple wpan interface on one PHY
(even monitor, if you want... because Linux need to filter everything)
what you want do to then is up to you and part of user space, maybe?
- Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: handling multiple MAC instances (multiple address filters)
2017-07-12 17:10 handling multiple MAC instances (multiple address filters) Alexander Aring
@ 2017-07-12 20:00 ` Michael Richardson
2017-07-13 14:41 ` Alexander Aring
0 siblings, 1 reply; 6+ messages in thread
From: Michael Richardson @ 2017-07-12 20:00 UTC (permalink / raw)
To: Alexander Aring; +Cc: linux-wpan
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
Alexander Aring <alex.aring@gmail.com> wrote:
> Then the discussed stopped after I took a shower and realized we lost
> ack handling when going into promiscuous mode... The transceiver will
> simple ack every frame which it's received then if we don't stop ack
> handling.
The issue is that with the filters off, we will ack packets aimed at other
nodes.
> Now, after I looked because RX_SAFE_MODE into af86rf2xx datasheets
> again. I think we could try to do the following:
So don't get too hung up on the limitations of the af86. It could be that
it is impossible with that device, but that another device will make it
possible.
> - RX done irq comes - Grab buffer information - Doing fast a source
> address lookup and check if we have a mac interface currently running
> which has the address and ack is requested. - If so trigger pin to
> send ack. - If not do nothing and drop (because we are not meant)
This sounds very cool.
> Another question is: Is running multiple interfaces on one PHY the
> thing what we "need". I think yes, because the 802.15.4 spec describe
> only one source PAN to operate on. Another idea would be to override
I'd really like to be able to operate on multiple PANs at the same time.
I think that 6LBRs will need this.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: handling multiple MAC instances (multiple address filters)
2017-07-12 20:00 ` Michael Richardson
@ 2017-07-13 14:41 ` Alexander Aring
2017-07-14 10:21 ` Michael Richardson
0 siblings, 1 reply; 6+ messages in thread
From: Alexander Aring @ 2017-07-13 14:41 UTC (permalink / raw)
To: Michael Richardson; +Cc: linux-wpan
On Wed, Jul 12, 2017 at 04:00:01PM -0400, Michael Richardson wrote:
>
> Alexander Aring <alex.aring@gmail.com> wrote:
> > Then the discussed stopped after I took a shower and realized we lost
> > ack handling when going into promiscuous mode... The transceiver will
> > simple ack every frame which it's received then if we don't stop ack
> > handling.
>
> The issue is that with the filters off, we will ack packets aimed at other
> nodes.
>
ok.
> > Now, after I looked because RX_SAFE_MODE into af86rf2xx datasheets
> > again. I think we could try to do the following:
>
> So don't get too hung up on the limitations of the af86. It could be that
> it is impossible with that device, but that another device will make it
> possible.
>
We need to talk about this point, see below.
> > - RX done irq comes - Grab buffer information - Doing fast a source
> > address lookup and check if we have a mac interface currently running
> > which has the address and ack is requested. - If so trigger pin to
> > send ack. - If not do nothing and drop (because we are not meant)
>
> This sounds very cool.
>
ok.
> > Another question is: Is running multiple interfaces on one PHY the
> > thing what we "need". I think yes, because the 802.15.4 spec describe
> > only one source PAN to operate on. Another idea would be to override
>
> I'd really like to be able to operate on multiple PANs at the same time.
> I think that 6LBRs will need this.
>
The 802.15.4 SPEC defines "macPANId" where stands:
"The 16-bit identifier of the PAN on which the device is operating. If this value
is 0xffff, the device is not associated."
So this is for me "we can only have a non-changing _source_ PAN". But
you could run more than one 802.15.4 MAC instances on one 802.15.4 PHY.
Which allows to run multiple wpan interfaces with different source PANs.
Now according to 6LoWPAN interface generation you can specify on which
destination pan you want to operate, or even per sendmsg(2). If not
specified it will use intra-pan communication destination pan == source
pan.
In short: You cannot handle multiple pan support on the same interface,
you need create other interfaces to run on other pans then. Is that what
you are looking for? I know unstrung need to have support to deal with
multiple interfaces then...
- Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: handling multiple MAC instances (multiple address filters)
2017-07-13 14:41 ` Alexander Aring
@ 2017-07-14 10:21 ` Michael Richardson
2017-07-16 9:08 ` Alexander Aring
0 siblings, 1 reply; 6+ messages in thread
From: Michael Richardson @ 2017-07-14 10:21 UTC (permalink / raw)
To: Alexander Aring; +Cc: linux-wpan
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
Alexander Aring <alex.aring@gmail.com> wrote:
> So this is for me "we can only have a non-changing _source_ PAN". But
> you could run more than one 802.15.4 MAC instances on one 802.15.4 PHY.
> Which allows to run multiple wpan interfaces with different source PANs.
I'm not parsing the difference.
> In short: You cannot handle multiple pan support on the same interface,
> you need create other interfaces to run on other pans then. Is that what
> you are looking for? I know unstrung need to have support to deal with
> multiple interfaces then...
What does "same interface" mean here?
Differrent hardware is needed, or just different lowpanX interfaces?
--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: handling multiple MAC instances (multiple address filters)
2017-07-14 10:21 ` Michael Richardson
@ 2017-07-16 9:08 ` Alexander Aring
2017-07-16 17:09 ` Alexander Aring
0 siblings, 1 reply; 6+ messages in thread
From: Alexander Aring @ 2017-07-16 9:08 UTC (permalink / raw)
To: Michael Richardson; +Cc: linux-wpan
On Fri, Jul 14, 2017 at 12:21:52PM +0200, Michael Richardson wrote:
>
> Alexander Aring <alex.aring@gmail.com> wrote:
> > So this is for me "we can only have a non-changing _source_ PAN". But
> > you could run more than one 802.15.4 MAC instances on one 802.15.4 PHY.
> > Which allows to run multiple wpan interfaces with different source PANs.
>
> I'm not parsing the difference.
>
ok.
> > In short: You cannot handle multiple pan support on the same interface,
> > you need create other interfaces to run on other pans then. Is that what
> > you are looking for? I know unstrung need to have support to deal with
> > multiple interfaces then...
>
> What does "same interface" mean here?
> Differrent hardware is needed, or just different lowpanX interfaces?
>
just different lowpanX interfaces.
____PHY0____
| ... |
wpan0 ... wpanX <---- can have different source pan settings,
| | destination can also be different over
| | af802154 socket communication.
| | (it's for setting the source pan)
| ,,, |
lowpan0 ... lowpanX <---- can have different destination pan as
``default destination pan''. _Maybe_ you
could change overwrite default destination
pan by CMSG attribute.
At least we need CMSG attribute I think,
because 0xffff pan which is broadcast pan.
We should only allow "unicast" pans in
lowpanX generation as destination.
(it's for setting the destination pan)
You could insert some routes to route over
different pans via internal lowpanX
interfaces, if you want that.
What doesn't work and what I don't want to plan is one wpan interfaces
and different lowpan interfaces on top of it, which operates on different
source pans (on lowpan interface layer). The reason is that IEEE 802.15.4
can have only one source PAN for one MAC instance (which is part of wpan
interface and not lowpan).
If somebody has another idea to deal with different pan settings I would
like to hear that, then I can think about it.
- Alex
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: handling multiple MAC instances (multiple address filters)
2017-07-16 9:08 ` Alexander Aring
@ 2017-07-16 17:09 ` Alexander Aring
0 siblings, 0 replies; 6+ messages in thread
From: Alexander Aring @ 2017-07-16 17:09 UTC (permalink / raw)
To: Michael Richardson; +Cc: linux-wpan
Hi,
took a shower again and detected issues.
On Sun, Jul 16, 2017 at 11:08:06AM +0200, Alexander Aring wrote:
> On Fri, Jul 14, 2017 at 12:21:52PM +0200, Michael Richardson wrote:
> >
> > Alexander Aring <alex.aring@gmail.com> wrote:
> > > So this is for me "we can only have a non-changing _source_ PAN". But
> > > you could run more than one 802.15.4 MAC instances on one 802.15.4 PHY.
> > > Which allows to run multiple wpan interfaces with different source PANs.
> >
> > I'm not parsing the difference.
> >
>
> ok.
>
> > > In short: You cannot handle multiple pan support on the same interface,
> > > you need create other interfaces to run on other pans then. Is that what
> > > you are looking for? I know unstrung need to have support to deal with
> > > multiple interfaces then...
> >
> > What does "same interface" mean here?
> > Differrent hardware is needed, or just different lowpanX interfaces?
> >
>
> just different lowpanX interfaces.
>
> ____PHY0____
> | ... |
> wpan0 ... wpanX <---- can have different source pan settings,
> | | destination can also be different over
> | | af802154 socket communication.
> | | (it's for setting the source pan)
> | ,,, |
> lowpan0 ... lowpanX <---- can have different destination pan as
> ``default destination pan''. _Maybe_ you
> could change overwrite default destination
> pan by CMSG attribute.
I think we cannot change the destination pan while interface running, so
handle only one different destination pan per interface and while it's
up.
The reason is simple: There is no address option for the destination pan
per neighbor cache - there is only one for short address and for this
reason we need always need to know on which pan the neighbor operates.
When doing ifdown on ipv6 capable interface - neighbor cache will be
flushed so we can change destination pan then.
Maybe 6lo working group will write something about handle destination
pan right. Don't know - maybe extract the info from received mac header?
But this sounds weird - because we don't do that for short address,
maybe there will be some PAN address option field come for ndisc
handling.
I mean we cannot handle anyway multiple destination pans on one
interface, because we save the short address only per neighbor and it's
not unique without the right pan. I don't see right now that this can
be working. :-/
So forget to change destination pan per CMSG attribute or per runtime
(interface is up).
> At least we need CMSG attribute I think,
> because 0xffff pan which is broadcast pan.
> We should only allow "unicast" pans in
> lowpanX generation as destination.
yea, forget to handle 0xffff ever - I don't know how this can be useful, see
above.
- Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-07-16 17:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-12 17:10 handling multiple MAC instances (multiple address filters) Alexander Aring
2017-07-12 20:00 ` Michael Richardson
2017-07-13 14:41 ` Alexander Aring
2017-07-14 10:21 ` Michael Richardson
2017-07-16 9:08 ` Alexander Aring
2017-07-16 17:09 ` Alexander Aring
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox