net/network_layer/fib: corrected handling of all 0 addresses

[BytesGalore]

The FIB did not handled all 0 addresses correctly.
When a default GW IPv6 address :: has been added to the FIB it could not be removed by fib_remove_entry() or updated by fib_update_entry() since it has not been discovered as an exact matching address.

This PR adds a check if the searched entry is an all 0 address and adjusts the determination if we have an exact match, so all 0 addresses can be removed and updated correctly.

[cgundogan]

@BytesGalore could you please rebase this one?

[BytesGalore]

@cgundogan sure, done :)

[cgundogan]

BTW, I noticed that you don't make any real use of prefix_len. Am I mistaken? It just sits at 0 until it gets assigned some value and then glides into nirvana.. Everywhere else you could've checked for 0 directly?

[BytesGalore]

prefix_size? If yes, I use it to determine if the found prefix is the best LPM [1] :)

[1] https://github.com/BytesGalore/RIOT/blob/fib_support_all_zero_addr/sys/net/network_layer/fib/fib.c#L139

[cgundogan]

@BytesGalore yes but, prefix_size is always 0 at this position. I cannot spot a location where it gets updated prior to the check?

[BytesGalore]

ok, here [1] Its updated with match_size that is filled with the number of matching bytes until the first non-trailing 0 byte in universal_address_compare(...) :)

[1] https://github.com/BytesGalore/RIOT/blob/fib_support_all_zero_addr/sys/net/network_layer/fib/fib.c#L160

[cgundogan]

And prior to this assignment you could exchange all occurences of prefix_size with a 0 constant? And after this assignment prefix_size isn't used anywhere else?

[cgundogan]

I don't understand the function of prefix_size😦

[BytesGalore]

ok, when we search a fitting entry we start to iterate all FIB entries [1]
If we find a matching one here [2], we see if the matching entry is a full match or if have found a prefix [3].
If its a prefix only we have to look if we can find a better one.
So we remember the current found one [4], store the found prefix_size and reset the matching size [5].
Then we loop again and see if we find a better prefix for the destination [2] (with the original match_size ).
In this subsequent iteration we can see if a found prefix is better if match_size > prefix_size [6]

I hope this helps :)

[1] https://github.com/BytesGalore/RIOT/blob/fib_support_all_zero_addr/sys/net/network_layer/fib/fib.c#L112
[2] https://github.com/BytesGalore/RIOT/blob/fib_support_all_zero_addr/sys/net/network_layer/fib/fib.c#L141
[3] https://github.com/BytesGalore/RIOT/blob/fib_support_all_zero_addr/sys/net/network_layer/fib/fib.c#L144
[4] https://github.com/BytesGalore/RIOT/blob/fib_support_all_zero_addr/sys/net/network_layer/fib/fib.c#L154
[5] https://github.com/BytesGalore/RIOT/blob/fib_support_all_zero_addr/sys/net/network_layer/fib/fib.c#L161
[6] https://github.com/BytesGalore/RIOT/blob/fib_support_all_zero_addr/sys/net/network_layer/fib/fib.c#L153

[cgundogan]

ah the there is an outer loop! Excuse me, Sir! this changes everything (:

[cgundogan]

I tested and can confirm: this works for the :: ip address => ACK. Merge when Travis builds and shows green (somewhen in the far future..)

[BytesGalore]

nice, thx for testing

[cgundogan]

Travis, why you no build..
@authmillenon Do you even ACK?

With your consent, I want to get this merged as soon as travis has a smiling face.

[cgundogan]

I am not sure if this is related to this bug, but I seem to cannot add the default route to a fib table which has >= 1 entries. On a fib table with zero entries, adding the default route is a success.

[cgundogan]

My ACK still holds. I am not sure if the strange behavior reported in my last comment is related to this PR. If yes, a follow-up PR can fix it. GO