search

CharlieTLe / qurinet

Data sets and scripts related to Qurinet, a wireless mesh network testbed located at the Quail Ridge Natural Reserve.
2 stars 3 forks source link

Monitor Link Changes #13

Open DineshUCD opened 8 years ago

DineshUCD commented 8 years ago

Task: Augment link stability by preventing rapid changes in link for a route.

Status Issue Description
Open Issue 1 All the adhoc interfaces are on the 10.0.0.0/16 subnet but some are on different radio channels and are de facto unreachable from one another. I don't believe OLSR is aware of this and you may need to split the subnet into smaller subnets on a per radio channel basis.
Open Issue 2 I'm not entirely sure that OLSR was configured correctly to be aware that the two radios are the same node (again I only have a surface understanding of how it works). Basically it doesn't know that 10.0.X.2, 10.0.X.3, and 10.X.1.1 are the same device and that reaching one gets you the others. This should be handled by the MID messages but I can't see where the main address is set in the configuration file.

I'm just kind of guessing that this is the problem with the rapid route switching but I want to make sure that you double check this is configured properly. I've attached the configuration file from site 1 which is still configured as to how OLSR was run in the past. I give no assurances it is correct. This also has the use of "LinkQualityMult" which was used to "poison" the wireless routes between routers that had an ethernet link, though I don't think this is how we actually want to manage this, see answer 2.

More Information: When one runs "ip route", one views the the path that data follows in order to travel across multiple networks from its source to its destination.

root@101:/# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        *               255.255.0.0     U     0      0        0 adhoc0
10.0.0.0        *               255.255.0.0     U     0      0        0 adhoc1
10.0.102.2      10.0.102.3      255.255.255.255 UGH   2      0        0 adhoc1
10.0.102.3      10.0.102.3      255.255.255.255 UGH   2      0        0 adhoc1
10.101.0.0      *               255.255.0.0     U     0      0        0 br0
10.102.0.0      10.0.102.3      255.255.0.0     UG    2      0        0 adhoc1
10.102.1.1      10.0.102.3      255.255.255.255 UGH   2      0        0 adhoc1
root@101:/# ip route
10.0.0.0/16 dev adhoc0  proto kernel  scope link  src 10.0.101.2 
10.0.0.0/16 dev adhoc1  proto kernel  scope link  src 10.0.101.3 
10.0.102.2 via 10.0.102.3 dev adhoc1  metric 2 onlink 
10.0.102.3 via 10.0.102.3 dev adhoc1  metric 2 onlink 
10.101.0.0/16 dev br0  proto kernel  scope link  src 10.101.1.1 
10.102.0.0/16 via 10.0.102.3 dev adhoc1  metric 2 onlink 
10.102.1.1 via 10.0.102.3 dev adhoc1  metric 2 onlink 
root@101:/#

Note that any destination which is reachable through a gateway appears in the routing table output with the keyword via. Hence, Todd is concerned with what is going on with routes such as 10.102.0.0/16 via 10.0.102.3 dev adhoc1 metric 2 onlink. Both Todd and I noticed that the device (interface) to the gateway fluctuates very rapidly. This is causing some issues in connectivity. We need to find a solution such that the links to a specific node do not change often from adhoc1 (ending in .3) to adhoc0 (ending in .2) and vice versa. He proposed the solution of changing the two radios to different subnets. Would this affect the BSSID? I know in the OLSR configuration file that the link set has a field L_time which tells when a link expires, and am wondering if that could be the issue.

CharlieTLe commented 8 years ago

How's the progress of this issue going?