PC in LAN cannot access Thread node but OTBR can about ot-br-posix HOT 17 CLOSED

It seems that OTBR didn't advertise on-link PIO in its RA when ISP doesn't provide a GUA prefix. Normally it should.

It'll be helpful if you can provide the logs of otbr-agent from syslog. cat /var/log/syslog | grep otbr-agent.

from ot-br-posix.

@superwhd ,

Thanks for your reply.

According to you, what should I do to enable the PC to access the Thread node?

from ot-br-posix.

@dsyx , can you provide the logs as requested in #2117 (comment) ?

from ot-br-posix.

Hi @jwhui ,

Sure.

otbr-agent_20231205.zip

from ot-br-posix.

From your logs, I saw:

Dec 05 14:56:18 otbr-4b otbr-agent[63438]: 00:10:17.940 [I] RoutingManager: Received RA from fe80:0:0:0:f22f:74ff:feb6:3e10 on infra netif 2
Dec 05 14:56:18 otbr-4b otbr-agent[63438]: 00:10:17.940 [I] RoutingManager: - RA Header - default route - lifetime:600
Dec 05 14:56:18 otbr-4b otbr-agent[63438]: 00:10:17.940 [I] RoutingManager: - PIO 240e:3b6:4a1:e4b0::/64 (valid:600, preferred:600)

This means your OTBR received an IPv6 PIO from ISP router and it'll expire after 10 minutes. However your log's latest time was at Dec 05 15:05:29 so the PIO hasn't expired yet. It's normal that your OTBR didn't advertise an on-link PIO in such a case.

Could you confirm the log is collected from your mentioned environment where ISP doesn't provide an IPv6 prefix?

from ot-br-posix.

Hi @superwhd ,

Sorry, I uploaded logs that don't match. The following is the environment and logs:

dev@otbr-4b:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d8:3a:dd:42:6d:e0 brd ff:ff:ff:ff:ff:ff
    inet 10.10.0.60/16 brd 10.10.255.255 scope global dynamic noprefixroute eth0
       valid_lft 86108sec preferred_lft 75308sec
    inet6 fdcc:cccc:ccaa:aaaa:da3a:ddff:fe42:6de0/64 scope global dynamic mngtmpaddr 
       valid_lft 1770sec preferred_lft 1770sec
    inet6 fe80::da3a:ddff:fe42:6de0/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether d8:3a:dd:42:6d:e1 brd ff:ff:ff:ff:ff:ff
4: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet6 fd1e:8c09:b3d8:f6c5:0:ff:fe00:fc38/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fdea:927c:c7d3:1:6946:6f02:932d:c8a3/64 scope global nodad 
       valid_lft forever preferred_lft forever
    inet6 fd1e:8c09:b3d8:f6c5:0:ff:fe00:fc11/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd1e:8c09:b3d8:f6c5:0:ff:fe00:fc10/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd1e:8c09:b3d8:f6c5:0:ff:fe00:3400/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd1e:8c09:b3d8:f6c5:9513:5ec5:c0cf:81fa/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fe80::4083:68a3:90d6:88d9/64 scope link nodad 
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:54:cb:c1:4a brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

dev@otbr-4b:~ $ ip -6 route
::1 dev lo proto kernel metric 256 pref medium
fd1e:8c09:b3d8:f6c5::/64 dev wpan0 proto kernel metric 256 pref medium
fdcc:cccc:ccaa:aaaa::/64 dev eth0 proto kernel metric 256 expires 1795sec pref medium
fdea:927c:c7d3:1::/64 dev wpan0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev wpan0 proto kernel metric 256 pref medium

otbr-agent_2023-12-06.zip

It looks like OTBR issued RA: fdcc:cccc:ccaa:aaaa::/64

Thanks

from ot-br-posix.

@dsyx It seems OTBR was sending RA in the expected way. You may need to check your PC received the RAs advertised by OTBR.

If your PC received the RA, please check if your PC generated an IPv6 on-link address on its LAN interface. If it doesn't have an IPv6 address, probably you need to configure your PC to enable adding IPv6 addresses on receiving PIO. I'm not sure if Windows has such an option.

from ot-br-posix.

Hi @superwhd ,

So is this the default behavior of OTBR? If the ISP issues the RA, the OTBR does not issue the RA; if the ISP does not issue the RA, the OTBR issues the RA.

Is it possible to set it up so that when the ISP issues RA, the OTBR also issues RA? After all, I don't think they conflict.

Please correct me if there is something wrong with my idea.

Thanks

from ot-br-posix.

OTBR always sends RA when border routing is properly configured and enabled, but the RA header and the RA options may be different:

• OTBR always includes RIO (Route Information Option) in RAs to advertise routes to OMR prefix.
• OTBR includes PIO (Prefix Information Option) in RAs when there's no router on infra link advertising a usable prefix. See SNAC draft for more details. When there's already a usable on-link prefix, OTBR won't add its local on-link prefix as PIO in RA.

Is it possible to set it up so that when the ISP issues RA, the OTBR also issues RA? After all, I don't think they conflict.

I think that's causing unnecessary multicast payloads on the infra link so it's not preferred. AFAIK there's no standard way to configure OTBR to do so. Could you explain why you want to achieve this?

from ot-br-posix.

I ran into a scenario where an ISP would issue an RA to advertise a globally available prefix, but the ISP would sometimes stop issuing RAs. In this case, the computers in the network will be unable to communicate with the nodes in the Thread.

So I think having the OTBR keep sending a LAN available RA can solve this problem.

from ot-br-posix.

Even if the ISP stops sending RAs, OTBR should automatically start to advertise its on-link prefix when the GUA prefix expires. This won't cause connectivity issue for more than seconds.

from ot-br-posix.

But my current experimental phenomenon shows that after the ISP stops sending RA, the device can no longer communicate until it receives the next RA sent by the ISP.

Are my build parameters incorrect?

from ot-br-posix.

In the environment of #2117 (comment), were your PC able to communicate with Thread? If not, I think your PC didn't accept OTBR's RA as said in #2117 (comment).

from ot-br-posix.

In this case, the PC communicates normally with Thread.

from ot-br-posix.

But my current experimental phenomenon shows that after the ISP stops sending RA, the device can no longer communicate until it receives the next RA sent by the ISP.

Could you reproduce this scenario and share the logs?

Are my build parameters incorrect?

Except that you have a space in BACKBONE_ROUTER I don't see anomalies. Also Backbone Router feature shouldn't affect this.

from ot-br-posix.

The spaces in BACKBONE_ROUTER are due to copy-paste and don't actually exist.

Could you reproduce this scenario and share the logs?

Since there is no fixed pattern for ISP to issue and stop RAs, it may take me some time to reproduce this phenomenon.

Thanks

from ot-br-posix.

Closing stale issue.

from ot-br-posix.