stale border router does not get replaced

[benpicco]

Description

When playing around with border routers I noticed some strange behavior: An offline border router is retained for an unknown time. Even resetting a node does not get it to use the new border router as the old border router information is still being advertised by neighboring nodes.

I am not sure if this is to spec as the border router live time is indeed exceptionally high. But this seems more like a bug as it makes roaming nodes impossible. Even worse, a roaming node could 'pollute' other nodes with an unreachable border router, making them ignore a border router that is reachable.

I think the solution could be to check if a border router is reachable before considering border router information valid or to drop existing border router information if a 'fresh' border router becomes available.

This makes me wonder, is is possible to protect against rogue border routers?

Steps to reproduce the issue

• set up a border router, e.g. a raspberry pi with an ieee802.15.4 radio following this guide
• flash a RIOT node with the gnrc_networking example and observe that the border router is being used

2019-09-12 13:23:07,524 - INFO #  nib abr
2019-09-12 13:23:07,527 - INFO # fd00:1:2:3:a:b:c:d v0 expires 65534min

• shut down the Raspberry Pi or move the RIOT node out of range.
• set up a second border router. If you have more RIOT nodes than RasPis, flash the gnrc_border_router example and run

make -C dist/tools/uhcpd
make -C dist/tools/ethos
sudo dist/tools/ethos/start_network.sh /dev/ttyACMx tap0 2001:db8::/64

The RIOT border Router should now announce it's prefix.

Expected results

After some time, the new border router should be used as the old border router is not reachable anymore.

2019-09-12 14:54:00,467 - INFO #  nib abr
2019-09-12 14:54:00,470 - INFO # 2001:db8::7b7d:362c:c959:65a v0 expires 10000min

Actual results

The old border router will be used for the next ~45 days

2019-09-12 14:54:00,467 - INFO #  nib abr
2019-09-12 14:54:00,470 - INFO # fd00:1:2:3:a:b:c:d v0 expires 65444min

some more information:

2019-09-12 15:05:53,443 - INFO #  nib neigh
2019-09-12 15:05:53,450 - INFO # fe80::d0af:c1b:2054:58f dev #7 lladdr D2:AF:0C:1B:20:54:05:8F router STALE GC
2019-09-12 15:06:11,958 - INFO #  nib route
2019-09-12 15:06:11,960 - INFO # fd00:1:2:3::/64 dev #7
2019-09-12 15:06:11,964 - INFO # default* via fe80::d0af:c1b:2054:58f dev #7
2019-09-12 15:06:20,582 - INFO #  nib prefix
2019-09-12 15:06:20,587 - INFO # fd00:1:2:3::/64 dev #7  expires 80101sec deprecates 8101sec
[a few hours later]
2019-09-12 17:57:56,199 - INFO #  nib prefix
2019-09-12 17:57:56,206 - INFO # fd00:1:2:3::/64 dev #7  expires 69802sec deprecates 4292769sec

Versions

RIOT master

[benpicco]

I also tried with sudo ./start_network.sh /dev/ttyACM0 tap0 fd00:1:2:3::/64 to see if the other BR takes over if they are in the same prefix.

Iface  6  HWaddr: 06:5A  Channel: 26  Page: 0  NID: 0x23
          Long HWaddr: 79:7D:36:2C:C9:59:06:5A 
           TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA Retries: 4 
          AUTOACK  ACK_REQ  CSMA  L2-PDU:102 MTU:1280  HL:64  RTR  
          RTR_ADV  6LO  IPHC  
          Source address length: 8
          Link type: wireless
          inet6 addr: fe80::7b7d:362c:c959:65a  scope: local  VAL
          inet6 addr: fd00:1:2:3:7b7d:362c:c959:65a  scope: global  VAL
          inet6 group: ff02::2
          inet6 group: ff02::1
          inet6 group: ff02::1:ff59:65a

But no:

> 2019-09-13 19:37:16,791 - INFO #  nib abr
2019-09-13 19:37:16,794 - INFO # fd00:1:2:3:a:b:c:d v0 expires 10000min

[miri64]

FYI everyone, I know about this issue, I talked with @benpicco offline about it, but I have to do some research myself before I can give a qualified answer 😅