On 09/30/2014 02:55 PM, Alexander Aring wrote:
On Tue, Sep 30, 2014 at 02:40:59PM +0530, Varka Bhadram wrote:
Hi Alex,
On 09/30/2014 02:23 PM, Alexander Aring wrote:
Hi Varka,
On Tue, Sep 30, 2014 at 02:16:46PM +0530, Varka Bhadram wrote:
Alex,
On 09/30/2014 02:09 PM, Alexander Aring wrote:
On Tue, Sep 30, 2014 at 09:34:29AM +0100, Simon Vincent wrote:
I can confirm that this fixes the problem. I will create some patches when I
get a chance.
Thanks
This should make trouble on phy's which have no address filter...
I didnt get what do you mean by this..?
The mac802154 address filter sets PACKET_BROADCAST, PACKET_HOST and
PACKET_OTHERHOST. When you have an address filter on PHY, then
PACKET_OTHERHOST should never happen (on good phy's).
So you always set PACKET_HOST xor PACKET_BROADCAST.
Enabling address filtering is in drivers hand..
no, drivers doesn't parse anything. Address filtering "CAN" done on phy.
But afterwards we set PACKET_FOO in mac802154 this is another address filtering.
Dropping frames when PACKET_OTHERHOST is part of next layer like (IPv6/6LoWPAN).
For enabling filtering, driver has to update one of the radio chip register.
Few hardware devices may not be handling the address filtering (SOftMAC devices).
So we need take care of this at Software layers.
Yes that's what we do mac802154 set PACKET_FOO and next layer will drop
if it's OTHERHOST.
ok
But when IPv6 Layer look on PACKET_BROADCAST then this is also another
bug...
I did a grep:
grep -r "PACKET_BROADCAST" net/IPv6
matches on:
net/ipv6/mcast.c: skb->pkt_type != PACKET_BROADCAST)
6LoWPAN layer always override the mac802154 parse value to PACKET_HOST.
Now I want to check if IPv6 Layer ever evaluate this value to
PACKET_BROADCAST and yes it seems so. So there is some other bug which
nobody detected.
Ok?
6LoWPAN layer override the mac802154 parse value to PACKET_HOST, but that you only
fixed yesterday. Now we need not to worry about override.
Of course we need to worry about that, it's not fixed mainline. :-)
Yes.. Simon told that he will generate the patches..
Here we need to consider one point. IPv6 layer deals with MUTICAST addresses, there is no
broadcast address at this pint.
In 802.15.4 the MULTICAST in our case is BROADCAST. We don't have any MULTICAST
feature. Only logical MULTICAST over BROADCAST. If you want to see a L2 Layer with
multicast support and address filtering on L2 see [0] as ethernet example.
OK..
MAC802154 deals with BROADCAST addresses...?
yes.
What is the bug that you are talking about..?
Don't know I didn't hit the bug and doesn't care about that. Point is
"that skb->pkt_type != PACKET_BROADCAST" is dead code in IPv6 and 6LoWPAN
because we always setting it to PACKET_HOST.
May be IEEE-802.11 packets send to IPv6 Layer. In that case Its not dead code.
--
Regards,
Varka Bhadram.
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
