buglwIP - A Lightweight TCP/IP stack - Bugs: bug #54749, 6Lo netif chooses wrong hardware...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #54749: 6Lo netif chooses wrong hardware address as destination

Submitter:  Martine Lenders <authmillenon>
Submitted:  Fri 28 Sep 2018 08:51:44 AM UTC
   
 
Category:  Network drivers Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  2.1.1
lwIP version:  2.1.0

Wed 03 Oct 2018 12:48:16 PM UTC, comment #4: 

As I don't have real 802.15.4 hardware to test, I'll just push it.

Thanks for testing.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 28 Sep 2018 09:32:31 AM UTC, comment #3: 

Oh, and I only tested for IEEE 802.15.4, but not for BLE (simply because there is no glue-code for RIOT's BLE layer with lwIP yet). But as far as I can see, it should work.

Martine Lenders <authmillenon>
Fri 28 Sep 2018 09:30:50 AM UTC, comment #2: 


> Sadly, this is what happens when people don't test release candidates ;-)

Nods sadly.

BTW the integration of lwIP v2.1.0 you can be found here: https://github.com/RIOT-OS/RIOT/pull/10059

Martine Lenders <authmillenon>
Fri 28 Sep 2018 08:53:16 AM UTC, comment #1: 

Sadly, this is what happens when people don't test release candidates ;-)

Simon Goldschmidt <goldsimon>
Group administrator
Fri 28 Sep 2018 08:51:44 AM UTC, original submission:  

First of all, congratulation for the release!

Sadly, I found a bug within the 6LoWPAN/6Lo code af the release when trying to integrate it with RIOT :-( (find fix attached):

Since 3a8af61, when setting the destination address for a 6Lo device the network interface's hardware address is set instead of the previously fetched address from the neighbor cache.

Also mind that my fix technically isn't correct for IEEE 802.15.4, as mixed address formats (e.g. source 16-bit, destination EUI-64) are possible, but since nd6_get_next_hop_addr_or_queue() does not return any information about the hardware address length, there is no way of getting the actual length of the destination address (as far as I know). This is why I decided to just revert the regression introduced 3a8af61, but to add a comment so this might be fixed in the future.

Sorry that I didn't provide this fix during already for the release candidate. I noticed something was wrong when testing it, but as always, time is short and found it only now to properly pin-point the issue :-(.

Martine Lenders <authmillenon>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by authmillenon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-10-03 goldsimon StatusNone Fixed
        Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2018-09-28 goldsimon Planned ReleaseNone 2.1.1
    2018-09-28 authmillenon Attached File- Added 0001-lowpan6.c-Fix-IEEE-802.15.4-address-setting.patch, #45111

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code