OpenThread
[question] Switching with/without ethernet interface connected #11268
Replies: 2 comments 4 replies
-
Border routing is part of what it does. Service discovery will also happen on this interface. If you remove this option, When you have multiple potential infra (backbone) links available, I think you should consider specifying multiple Reference: https://github.com/openthread/ot-br-posix/blob/main/src/utils/infra_link_selector.cpp IIUC the problem you met is that your BR cannot ping a Thread device when your BR is not connected to WiFi or Ethernet? Per you mentioned that it auto selected an address on the Ethernet interface, it may indicate something is wrong in your Linux routing table. It'll be helpful if you provide following information. $ ip -6 route show table all
$ ip -6 rule
$ ip route get <Thread destination>
I think GitHub issues is the suggested place for such discussions. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, We are going to check about using multiple -B options and compare with our current solution to see the benefits/problems of this solution. (Currently we have a script that stop otbr-agent everytime a network switch is operated and start it using the "prefered interface" (interface that is connected / prefered interface if the two are connected)" It's good to know that otbr-agent is supposed to work as a thread device without -B, so that in theory it's possible to work without ethernet/wifi interfaces. Also, I don't know if it's important, but the 'wrong' IPv6 address that is affected to eth0 and used as 'source address' when we use otbr-agent without '-B' is possibly comming from another border router (as we run multiple border routers in the network!) Maybe next week I will check for IPv6 routes and confirm or not the previous line. Then I will post the result here. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I have reproduced the situation where:
This is the result of the commands and it's very interesting: The ping is failing like this: As we can see here, the source IPv6 is wrong! It takes the IPv6 of "ethernet" interface (see below) Interfaces: Some commands: If I run this command, the ping start to work: Ping: And the prefered route has changed: So at this point, the problem seems to be related to:
Did you know why it takes this route: Instead of this one: To access Is there a way to force it using wpan0 in any cases to access thread network ? Note that when we create the thread network, we don't use this command: In the past we had issues with this command, possibly because we had multiple iot hubs with same prefix (not completely sure). Is it related ? |
Beta Was this translation helpful? Give feedback.
-
|
Hello, This is just to say that I solved the main issue like this:
Full startup process: Also some documentation: I have tested different scenarios and it works well:
In all these scenarios we are now able to ping the devices in any situation. Now we only have one issue:
EDIT:
|
Beta Was this translation helpful? Give feedback.
-
|
I think the problem here is that it chose the ethernet address instead of wpan0 address. I used to think this behavior is wrong but after reading https://www.ietf.org/rfc/rfc3484.html#section-5, I think the behavior is correct regarding the RFC (though may not be desired regarding the use case). When comparing the addresses: It seems that the Mesh-Local addresses are not so useful on the host from apps' perspective. cc @bukepo |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I come back in this discussion about this problem: When the Linux host loose Ethernet/WiFi connection, the Thread devices are not accessible from the Linux host (Must be working in the case of a matter controller that also acts as border-router) We solved this with a prefix + route configuration. I would like to know if it is the best solution or if there is another solution ? I am asking this because in the specifications, it seems that the OMR Prefix is supposed to be "automatically" generated by thread and there are mechanisms where if we have multiple border routers, they should use the same prefix (they identify something like the best prefix), so if I understand, if another border router comes then I am not sure that the prefix that I configured, is the prefix that will be used. So my routing rule is potentially wrong in theses cases ? What do you think @superwhd ? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
We have a IOT gateway running on Yocto with ethernet and wifi interface working good since a long time with otbr-agent.
Except one case: When we have no ethernet/wifi connection.
The functional cases are:
Up to now we was starting otbr-agent like this:
But as otbr-agent have troubles when Ethernet AND WiFi interfaces are disconnected, we are thinking about removing the
-BoptionWe are not sure to really understand what is this option for:
We don't know if it's a good idea or not to:
Also we found something strange:
-Boption and we have no ethernet/wifi connection: we can ping a thread device from the IOT Gateway-Boption and we connect an ethernet cable, the ping start to fail because (probably) the IPv6 source address of the ping request is taken from Ethernet interface instead of wpan0,ipaddr on a thread CLI device:
The ping from the computer when ethernet is connected (without
-B):Logs when otbr-agent is started without
-BAND ethernet cable is connected:Logs when otbr-agent is started without
-BAND ethernet cable is disconnected:Also, is there a better place for this kind of questions ? Like a chat or something.
Beta Was this translation helpful? Give feedback.
All reactions