handling multiple MAC instances (multiple address filters)

* 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