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..
Few hardware devices may not be handling the address filtering (SOftMAC devices).
So we need take care of this at Software layers.
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.
Here we need to consider one point. IPv6 layer deals with MUTICAST addresses, there is no
broadcast address at this pint.
MAC802154 deals with BROADCAST addresses...?
What is the bug that you are talking about..?
- Alex
--
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
