Closed stevew817 closed 1 year ago
Can you paste the otbr-agent
log? Thanks.
@stevew817 This is a missing feature. This requires converting the router advertisement to Thread network data. I agree this is very useful but I think it requires some time to add it.
@bukepo It's been a while since I last looked at OTBR, but wasn't this implemented in wpantund already?
@gjc13 This might be of interest too?
Jun 11 13:12:13 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:13 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:13 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [NOTE]-PLAT----: ADD [U] 2001:<private>:<private>:5801::1
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [WARN]-PLAT----: unexpected address type (6).
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [WARN]-PLAT----: unexpected address type (8).
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [INFO]-CORE----: Notifier: StateChanged (0x00000001) [Ip6+]
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [NOTE]-PLAT----: ADD [U] 2001:<private>:<private>:5801::1
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [WARN]-PLAT----: unexpected address type (6).
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [WARN]-PLAT----: unexpected address type (8).
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processTransmit: OK
Yes, but it seems it didn't detect what kind of prefix is added. We'll add the feature soon.
@bukepo I'm circling back to this issue here. Is there any update re. adding support for auto-assigning delegated prefixes?
Upon re-reading your comments and the linked PR, I think we might've been talking about different things. Your PR was about doing RA across the router, but my issue is rather with DHCPv6-PD.
The current otbr
dhcpcd.conf specifically requests a prefix to be delegated to the wpan0 interface. As far as I'm aware, this feature is still broken, since the DHCP-assigned prefix gets overridden by otbr-agent (which gets started after DHCP assignment). At least that's the behaviour I'm seeing on the latest ot-br-posix on raspbian.
What's the point of requesting a prefix to be delegated to wpan0 in this way, if that prefix isn't going to be on-mesh? If ot-br isn't going to do this, then what is the preferred way of handling PD?
HI, I am interested to know about this too. If i have dhcpv6 server and and if that offers the prefix-delegation, will that be used in the sensor network? I see always OTBR picks its own ULA prefix not form DHCPv6-PD @jwhui @bukepo
HI, I am interested to know about this too. If i have dhcpv6 server and and if that offers the prefix-delegation, will that be used in the sensor network? I see always OTBR picks its own ULA prefix not form DHCPv6-PD @jwhui @bukepo
@ssenthu , while OpenThread does not currently integrate with DHCPv6 Prefix Delegation, we are currently working to support this.
Closing stale issue.
Describe the bug When a GUA IPv6 prefix is delegated to the wpan0 interface through DHCPv6-PD, the expectation is that this prefix is automatically added to the on-mesh prefix, and that nodes on the mesh learn their GUA from this prefix. This does not seem to happen. The wpan0 interface gains a GUA address (::1 from the assigned prefix), but does not configure the Thread network to let nodes configure their own GUA address from the assigned prefix, and does not add a route for internet connectivity either.
To Reproduce
Steps:
Expected behavior When the border router gets assigned a globally routable prefix through DHCPv6, it adds that prefix to the mesh and adds it as a route, such that nodes on the mesh gain native IPv6 connectivity.
Console/log output On raspberry:
ifconfig wpan0
ot-ctl ipaddr
ot-ctl prefix
ot-ctl state
From dhcpcd log:
CLI
ipaddr
on attached second thread node: