Re: ICMPv6 Redirects

[Varka Bhadram <varkabhadram@gmail.com>]

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.