<div dir="ltr"><div>I am glad I didn't try to make a smaller test case ;-)<br><br></div>I am not sure what the justification for the 1280 MTU is, it wasn't a choice I made. Even if we bump that up a bit, we're going to run into 1500 eventually. Is it possible to send the messages in fragments?<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 28, 2014 at 4:54 AM, Henning Rogge <span dir="ltr"><<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello:<br>
40 bytes (IP header) + 8 bytes (UDP)<br>
+ 4 bytes (OLSR packet header)<br>
+ 4 bytes (OLSR message header) + 60*20 bytes (20 bytes per neighbor)<br>
+ 4-16 bytes (up to 4 groups of neighbors)<br>
= 1260 - 1272 bytes<br>
<br>
a few additional bytes for IP header options and we break the limit.<br>
<br>
TC is a little bit smaller by a constant value, but still 20 bytes per neighbor.<br>
<br>
HNA is no problem (just 16 bytes per HNA, no neighbors)<br>
<br>
<br>
I think we found our potential problem.<br>
<br>
Henning Rogge<br>
<br>
<br>
On Fri, Mar 28, 2014 at 12:47 PM, Russell Senior<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a>> wrote:<br>
> When the central node has 59 neighbors, it works. When it has 60 neighbors,<br>
> it doesn't. We actually have 67 that we'd like to work today, with more new<br>
> nodes in the near future.<br>
><br>
><br>
> On Fri, Mar 28, 2014 at 4:42 AM, Henning Rogge <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>> wrote:<br>
>><br>
>> How many leaf nodes do you have?<br>
>><br>
>> Number of routes is not that important.<br>
>><br>
>> Henning Rogge<br>
>><br>
>> On Fri, Mar 28, 2014 at 12:41 PM, Russell Senior<br>
>> <<a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a>> wrote:<br>
>> > The MTU on the OpenVPN tunnel is 1280. That explanation does sound<br>
>> > quite<br>
>> > plausible.<br>
>> ><br>
>> ><br>
>> > On Fri, Mar 28, 2014 at 4:37 AM, Henning Rogge <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>> wrote:<br>
>> >><br>
>> >> It was worth the idea, it could have been a race condition between the<br>
>> >> message flooding and the OpenVPN multicast handling.<br>
>> >><br>
>> >> I also think that "message fragmentation" is an issue here...<br>
>> >><br>
>> >> 180 routes means that neither your Hello nor your TC does fit in a<br>
>> >> single UDP packet... which means the TCs/Hellos have to be fragmented<br>
>> >> by Olsrd, which is a codepath that is not well tested because it<br>
>> >> normally is not necessary.<br>
>> >><br>
>> >> Thats mosts likely the reason why IPv4 is working, the messages do not<br>
>> >> become fragmented.<br>
>> >><br>
>> >> Henning Rogge<br>
>> >><br>
>> >> On Fri, Mar 28, 2014 at 12:28 PM, Russell Senior<br>
>> >> <<a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a>> wrote:<br>
>> >> > Clarification:<br>
>> >> ><br>
>> >> > Mode "ether" does not explain the route collapse with too many nodes<br>
>> >> > participating.<br>
>> >> ><br>
>> >> > Mode "ether" does seem to explain the lack of individual routes on<br>
>> >> > the<br>
>> >> > "leaf" nodes.<br>
>> >> ><br>
>> >> ><br>
>> >> > On Fri, Mar 28, 2014 at 4:26 AM, Russell Senior<br>
>> >> > <<a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> It could be, but it isn't ;-)<br>
>> >> >><br>
>> >> >> Even with Mode "ether" commented out, I'm still seeing the same<br>
>> >> >> route<br>
>> >> >> collapse behavior when too many devices are on.<br>
>> >> >><br>
>> >> >> Commenting it out did improve the route propagation to the "leaf"<br>
>> >> >> nodes<br>
>> >> >> though.<br>
>> >> >><br>
>> >> >><br>
>> >> >> On Fri, Mar 28, 2014 at 4:23 AM, Henning Rogge <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>><br>
>> >> >> wrote:<br>
>> >> >>><br>
>> >> >>> Hi,<br>
>> >> >>><br>
>> >> >>> mode "ether" should only be used by a group of OLSRd that run on<br>
>> >> >>> the<br>
>> >> >>> same ethernet switch... which means everyone can see everyone else.<br>
>> >> >>><br>
>> >> >>> It suppress some forwarding of incoming OLSR messages because it<br>
>> >> >>> assumes that everyone on this interface has already seen the<br>
>> >> >>> message<br>
>> >> >>> anyways.<br>
>> >> >>><br>
>> >> >>> If the "hub" had "mode ether" activated it could be a good<br>
>> >> >>> explanation<br>
>> >> >>> what happened.<br>
>> >> >>><br>
>> >> >>> Henning<br>
>> >> >>><br>
>> >> >>> On Fri, Mar 28, 2014 at 12:01 PM, Russell Senior<br>
>> >> >>> <<a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a>> wrote:<br>
>> >> >>> > I should have done this earlier, but here are my olsrd.conf<br>
>> >> >>> > files.<br>
>> >> >>> > On<br>
>> >> >>> > the<br>
>> >> >>> > server:<br>
>> >> >>> ><br>
>> >> >>> > ===================================================<br>
>> >> >>> > IpVersion 6<br>
>> >> >>> ><br>
>> >> >>> > #Hna4<br>
>> >> >>> > #{<br>
>> >> >>> > #}<br>
>> >> >>> ><br>
>> >> >>> > Hna6<br>
>> >> >>> > {<br>
>> >> >>> > 0:: 0<br>
>> >> >>> > }<br>
>> >> >>> ><br>
>> >> >>> > LinkQualityFishEye 0<br>
>> >> >>> ><br>
>> >> >>> > LoadPlugin "olsrd_txtinfo.so.0.1"<br>
>> >> >>> > {<br>
>> >> >>> > PlParam "port" "7862"<br>
>> >> >>> > }<br>
>> >> >>> ><br>
>> >> >>> > #############################################<br>
>> >> >>> > ### OLSRD default interface configuration ###<br>
>> >> >>> > #############################################<br>
>> >> >>> > # the default interface section can have the same values as the<br>
>> >> >>> > following<br>
>> >> >>> > # interface configuration. It will allow you so set common<br>
>> >> >>> > options<br>
>> >> >>> > for<br>
>> >> >>> > all<br>
>> >> >>> > # interfaces.<br>
>> >> >>> ><br>
>> >> >>> > InterfaceDefaults {<br>
>> >> >>> > # Ip4Broadcast 255.255.255.255<br>
>> >> >>> > }<br>
>> >> >>> ><br>
>> >> >>> > Interface "ptp" "ptp-udp" "vpn" "iris"<br>
>> >> >>> > {<br>
>> >> >>> > # Mode "ether"<br>
>> >> >>> > }<br>
>> >> >>> > =====================================================<br>
>> >> >>> ><br>
>> >> >>> > I am pretty sure that Hna4 { } part had been there uncommented<br>
>> >> >>> > for a<br>
>> >> >>> > while.<br>
>> >> >>> > The Mode "ether" was uncommented too. When I commented them out,<br>
>> >> >>> > as<br>
>> >> >>> > above,<br>
>> >> >>> > and restart I see the individual routes on the client, as you<br>
>> >> >>> > would<br>
>> >> >>> > expect.<br>
>> >> >>> > I had noticed the "route aggregation" and been a little<br>
>> >> >>> > surprised,<br>
>> >> >>> > but<br>
>> >> >>> > having just moved to a newer version, I wasn't too suspicious.<br>
>> >> >>> ><br>
>> >> >>> > On the clients:<br>
>> >> >>> ><br>
>> >> >>> > =====================================================<br>
>> >> >>> ><br>
>> >> >>> > IpVersion 6<br>
>> >> >>> ><br>
>> >> >>> > LinkQualityFishEye 0<br>
>> >> >>> ><br>
>> >> >>> > Hna6<br>
>> >> >>> > {<br>
>> >> >>> > 2001:470:e962:xxyy:: 64<br>
>> >> >>> > }<br>
>> >> >>> ><br>
>> >> >>> > LoadPlugin "olsrd_txtinfo.so.0.1"<br>
>> >> >>> > {<br>
>> >> >>> > PlParam "port" "7862"<br>
>> >> >>> > }<br>
>> >> >>> ><br>
>> >> >>> > Interface "br-pub" "ptp"<br>
>> >> >>> > {<br>
>> >> >>> > }<br>
>> >> >>> > =====================================================<br>
>> >> >>> ><br>
>> >> >>> > When it's working, I see 177 olsrd routes (the 180 figure<br>
>> >> >>> > included<br>
>> >> >>> > some<br>
>> >> >>> > header/footer lines, apparently) on the server and 176 on the<br>
>> >> >>> > client.<br>
>> >> >>> > But<br>
>> >> >>> > if I add another node, the routes all collapse still. It is<br>
>> >> >>> > confusing<br>
>> >> >>> > though. Sometimes, I only see two routes, as below, apparently<br>
>> >> >>> > when<br>
>> >> >>> > Mode<br>
>> >> >>> > "ether" is in force. It's confusing because sometimes I was<br>
>> >> >>> > seeing<br>
>> >> >>> > the<br>
>> >> >>> > more<br>
>> >> >>> > complete client routing table even with Mode "ether".<br>
>> >> >>> ><br>
>> >> >>> > Table: Routes<br>
>> >> >>> > Destination Gateway IP Metric ETX Interface<br>
>> >> >>> > ::/0 2001:470:e962::407 1 1.000 ptp<br>
>> >> >>> > 2001:470:e962::407/128 2001:470:e962::407 1 1.000<br>
>> >> >>> > ptp<br>
>> >> >>> ><br>
>> >> >>> > I am turning Mode "ether" off again, and I seem to get a complete<br>
>> >> >>> > set<br>
>> >> >>> > of<br>
>> >> >>> > routes (one less than the server) on the clients.<br>
>> >> >>> ><br>
>> >> >>> > Again, though, if I add one more node, the routes on both the<br>
>> >> >>> > server<br>
>> >> >>> > and<br>
>> >> >>> > clients collapse. The clients go to zero. The server has routes<br>
>> >> >>> > to<br>
>> >> >>> > one or<br>
>> >> >>> > sometimes two clients, which vary a little bit.<br>
>> >> >>> ><br>
>> >> >>> ><br>
>> >> >>> ><br>
>> >> >>> ><br>
>> >> >>> > On Fri, Mar 28, 2014 at 3:09 AM, Henning Rogge <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>><br>
>> >> >>> > wrote:<br>
>> >> >>> >><br>
>> >> >>> >> Each leaf should have a /128 route for each other leaf...<br>
>> >> >>> >><br>
>> >> >>> >> Olsrd does NOT do any route aggregation.<br>
>> >> >>> >><br>
>> >> >>> >> Can you show me a routing table of a leaf and the txtinfo output<br>
>> >> >>> >> when<br>
>> >> >>> >> everything is fine?<br>
>> >> >>> >><br>
>> >> >>> >> Henning<br>
>> >> >>> >><br>
>> >> >>> >> On Fri, Mar 28, 2014 at 11:06 AM, Russell Senior<br>
>> >> >>> >> <<a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a>> wrote:<br>
>> >> >>> >> > FWIW, the ipv6 routing tables on the "leaf" nodes are quite<br>
>> >> >>> >> > short,<br>
>> >> >>> >> > with<br>
>> >> >>> >> > mostly just a default route pointing at the central server,<br>
>> >> >>> >> > when<br>
>> >> >>> >> > olsrd<br>
>> >> >>> >> > is<br>
>> >> >>> >> > working. When the central server has the route collapse, the<br>
>> >> >>> >> > default<br>
>> >> >>> >> > route<br>
>> >> >>> >> > on the "leaf" nodes disappears.<br>
>> >> >>> >> ><br>
>> >> >>> >> > I am thinking about memory exhaustion, maybe something his<br>
>> >> >>> >> > helpfully<br>
>> >> >>> >> > killing<br>
>> >> >>> >> > it off when the size becomes "too large" ... /me goes to look<br>
>> >> >>> >> > for<br>
>> >> >>> >> > evidence<br>
>> >> >>> >> > of that.<br>
>> >> >>> >> ><br>
>> >> >>> >> ><br>
>> >> >>> >> > On Fri, Mar 28, 2014 at 3:03 AM, Russell Senior<br>
>> >> >>> >> > <<a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a>><br>
>> >> >>> >> > wrote:<br>
>> >> >>> >> >><br>
>> >> >>> >> >> The are single hop from the central server, which is the<br>
>> >> >>> >> >> table<br>
>> >> >>> >> >> I've<br>
>> >> >>> >> >> been<br>
>> >> >>> >> >> posting.<br>
>> >> >>> >> >><br>
>> >> >>> >> >><br>
>> >> >>> >> >> On Fri, Mar 28, 2014 at 3:01 AM, Henning Rogge<br>
>> >> >>> >> >> <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>><br>
>> >> >>> >> >> wrote:<br>
>> >> >>> >> >>><br>
>> >> >>> >> >>> What?<br>
>> >> >>> >> >>><br>
>> >> >>> >> >>> but your routing tables only contains "ETX 1.0" paths...<br>
>> >> >>> >> >>> which<br>
>> >> >>> >> >>> means<br>
>> >> >>> >> >>> they are single hop!<br>
>> >> >>> >> >>><br>
>> >> >>> >> >>> Henning<br>
>> >> >>> >> >>><br>
>> >> >>> >> >>> On Fri, Mar 28, 2014 at 11:00 AM, Russell Senior<br>
>> >> >>> >> >>> <<a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a>> wrote:<br>
>> >> >>> >> >>> > Without the ipv6 olsrd, the nodes can't route to each<br>
>> >> >>> >> >>> > other,<br>
>> >> >>> >> >>> > it<br>
>> >> >>> >> >>> > seems.<br>
>> >> >>> >> >>> > I<br>
>> >> >>> >> >>> > picked two I had turned off, and tried ping6'ing between<br>
>> >> >>> >> >>> > them<br>
>> >> >>> >> >>> > and<br>
>> >> >>> >> >>> > got<br>
>> >> >>> >> >>> > 100%<br>
>> >> >>> >> >>> > packet loss.<br>
>> >> >>> >> >>> ><br>
>> >> >>> >> >>> ><br>
>> >> >>> >> >>> > On Fri, Mar 28, 2014 at 2:54 AM, Henning Rogge<br>
>> >> >>> >> >>> > <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>><br>
>> >> >>> >> >>> > wrote:<br>
>> >> >>> >> >>> >><br>
>> >> >>> >> >>> >> Hi,<br>
>> >> >>> >> >>> >><br>
>> >> >>> >> >>> >> as far as I can see each "leaf" node can see each other<br>
>> >> >>> >> >>> >> leaf<br>
>> >> >>> >> >>> >> node<br>
>> >> >>> >> >>> >> over<br>
>> >> >>> >> >>> >> the OpenVPN, right?<br>
>> >> >>> >> >>> >><br>
>> >> >>> >> >>> >> So you are only using Olsrd to distribute HNAs?<br>
>> >> >>> >> >>> >><br>
>> >> >>> >> >>> >> Henning Rogge<br>
>> >> >>> >> >>> >><br>
>> >> >>> >> >>> >> On Fri, Mar 28, 2014 at 10:48 AM, Russell Senior<br>
>> >> >>> >> >>> >> <<a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a>> wrote:<br>
>> >> >>> >> >>> >> > The central server, ::407, is running OpenVPN in server<br>
>> >> >>> >> >>> >> > mode.<br>
>> >> >>> >> >>> >> > The<br>
>> >> >>> >> >>> >> > "leaf"<br>
>> >> >>> >> >>> >> > nodes all connect to it via OpenVPN client mode with a<br>
>> >> >>> >> >>> >> > tap<br>
>> >> >>> >> >>> >> > interface.<br>
>> >> >>> >> >>> >> > We<br>
>> >> >>> >> >>> >> > statically provision the IPv6 addresses on the vpn.<br>
>> >> >>> >> >>> >> ><br>
>> >> >>> >> >>> >> > And yes, the OpenVPN links are still active. We are<br>
>> >> >>> >> >>> >> > running<br>
>> >> >>> >> >>> >> > an<br>
>> >> >>> >> >>> >> > IPv4<br>
>> >> >>> >> >>> >> > instance of olsrd (same version) in parallel and those<br>
>> >> >>> >> >>> >> > routes<br>
>> >> >>> >> >>> >> > (to<br>
>> >> >>> >> >>> >> > the<br>
>> >> >>> >> >>> >> > very<br>
>> >> >>> >> >>> >> > same devices) are not affected.<br>
>> >> >>> >> >>> >> ><br>
>> >> >>> >> >>> >> > We see the problem when particular (though varying)<br>
>> >> >>> >> >>> >> > nodes<br>
>> >> >>> >> >>> >> > olsrd<br>
>> >> >>> >> >>> >> > ipv6<br>
>> >> >>> >> >>> >> > instances are started/stopped. Sometimes the nodes are<br>
>> >> >>> >> >>> >> > running<br>
>> >> >>> >> >>> >> > 0.6.6.1,<br>
>> >> >>> >> >>> >> > and<br>
>> >> >>> >> >>> >> > sometimes 0.6.4. It doesn't seem to be specific. The<br>
>> >> >>> >> >>> >> > central<br>
>> >> >>> >> >>> >> > server is<br>
>> >> >>> >> >>> >> > running 0.6.6.1 now, but we saw the same thing earlier<br>
>> >> >>> >> >>> >> > (which<br>
>> >> >>> >> >>> >> > is<br>
>> >> >>> >> >>> >> > why<br>
>> >> >>> >> >>> >> > I<br>
>> >> >>> >> >>> >> > upgraded) on 0.6.4.<br>
>> >> >>> >> >>> >> ><br>
>> >> >>> >> >>> >> > One other potential clue (it doesn't make very much<br>
>> >> >>> >> >>> >> > sense,<br>
>> >> >>> >> >>> >> > because I<br>
>> >> >>> >> >>> >> > know<br>
>> >> >>> >> >>> >> > there are much bigger networks than ours), I've never<br>
>> >> >>> >> >>> >> > seen<br>
>> >> >>> >> >>> >> > more<br>
>> >> >>> >> >>> >> > than<br>
>> >> >>> >> >>> >> > 186<br>
>> >> >>> >> >>> >> > ipv6 routes on ::407. We seem to see the problem when<br>
>> >> >>> >> >>> >> > we<br>
>> >> >>> >> >>> >> > try<br>
>> >> >>> >> >>> >> > to<br>
>> >> >>> >> >>> >> > exceed<br>
>> >> >>> >> >>> >> > that. I'm going to try to confirm that.<br>
>> >> >>> >> >>> >> ><br>
>> >> >>> >> >>> >> ><br>
>> >> >>> >> >>> >> > On Fri, Mar 28, 2014 at 2:34 AM, Henning Rogge<br>
>> >> >>> >> >>> >> > <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>><br>
>> >> >>> >> >>> >> > wrote:<br>
>> >> >>> >> >>> >> >><br>
>> >> >>> >> >>> >> >> Hi,<br>
>> >> >>> >> >>> >> >><br>
>> >> >>> >> >>> >> >> I must admit that I am not convinced that its an Olsrd<br>
>> >> >>> >> >>> >> >> bug<br>
>> >> >>> >> >>> >> >> what<br>
>> >> >>> >> >>> >> >> we<br>
>> >> >>> >> >>> >> >> are<br>
>> >> >>> >> >>> >> >> seeing...<br>
>> >> >>> >> >>> >> >><br>
>> >> >>> >> >>> >> >> If I see it correctly Olsrd is running over the VPN<br>
>> >> >>> >> >>> >> >> interface<br>
>> >> >>> >> >>> >> >> connection (interface name "vpn"), right?<br>
>> >> >>> >> >>> >> >><br>
>> >> >>> >> >>> >> >> Is the VPN connection between the nodes still active<br>
>> >> >>> >> >>> >> >> during<br>
>> >> >>> >> >>> >> >> the<br>
>> >> >>> >> >>> >> >> route<br>
>> >> >>> >> >>> >> >> loss? Most of the nodes seem to have direct<br>
>> >> >>> >> >>> >> >> connections<br>
>> >> >>> >> >>> >> >> and<br>
>> >> >>> >> >>> >> >> the<br>
>> >> >>> >> >>> >> >> "30<br>
>> >> >>> >> >>> >> >> seconds until recovery" sounds like an ETX value<br>
>> >> >>> >> >>> >> >> slowly<br>
>> >> >>> >> >>> >> >> going<br>
>> >> >>> >> >>> >> >> down<br>
>> >> >>> >> >>> >> >> and<br>
>> >> >>> >> >>> >> >> then dropping the link.<br>
>> >> >>> >> >>> >> >><br>
>> >> >>> >> >>> >> >> Henning<br>
>> >> >>> >> >>> >> >><br>
>> >> >>> >> >>> >> >> On Fri, Mar 28, 2014 at 10:11 AM, Saverio Proto<br>
>> >> >>> >> >>> >> >> <<a href="mailto:zioproto@gmail.com">zioproto@gmail.com</a>><br>
>> >> >>> >> >>> >> >> wrote:<br>
>> >> >>> >> >>> >> >> > Hello Russel,<br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > looking at this:<br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > <a href="https://personaltelco.net/~russell/olsrd/olsrd-routes-before.txt" target="_blank">https://personaltelco.net/~russell/olsrd/olsrd-routes-before.txt</a><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > <a href="https://personaltelco.net/~russell/olsrd/olsrd-routes-during.txt" target="_blank">https://personaltelco.net/~russell/olsrd/olsrd-routes-during.txt</a><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > <a href="https://personaltelco.net/~russell/olsrd/olsrd-routes-after.txt" target="_blank">https://personaltelco.net/~russell/olsrd/olsrd-routes-after.txt</a><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > it looks like IPv6 routes are removed from the olsrd<br>
>> >> >>> >> >>> >> >> > database.<br>
>> >> >>> >> >>> >> >> > So<br>
>> >> >>> >> >>> >> >> > I<br>
>> >> >>> >> >>> >> >> > is<br>
>> >> >>> >> >>> >> >> > actually the olsrd daemon involved.<br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > do you know if there is a previous stable version of<br>
>> >> >>> >> >>> >> >> > olsrd<br>
>> >> >>> >> >>> >> >> > where<br>
>> >> >>> >> >>> >> >> > this<br>
>> >> >>> >> >>> >> >> > bug/behaviour is not present ?<br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > In my opinion the fastest way to track the bug is to<br>
>> >> >>> >> >>> >> >> > try<br>
>> >> >>> >> >>> >> >> > different<br>
>> >> >>> >> >>> >> >> > versions of olsrd with "git bisect" method.<br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > The first step is to tell us if there is a version<br>
>> >> >>> >> >>> >> >> > of<br>
>> >> >>> >> >>> >> >> > olsrd<br>
>> >> >>> >> >>> >> >> > that<br>
>> >> >>> >> >>> >> >> > is<br>
>> >> >>> >> >>> >> >> > not affected by this problem.<br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > thanks<br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > I cc: olsrd-dev<br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > Saverio<br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > 2014-03-27 10:37 GMT+01:00 Russell Senior<br>
>> >> >>> >> >>> >> >> > <<a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a>>:<br>
>> >> >>> >> >>> >> >> >>>>>>> "Henning" == Henning Rogge<br>
>> >> >>> >> >>> >> >> >>>>>>> <<a href="mailto:henning.rogge@fkie.fraunhofer.de">henning.rogge@fkie.fraunhofer.de</a>><br>
>> >> >>> >> >>> >> >> >>>>>>> writes:<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> Henning> On 03/26/2014 07:41 PM, Russell Senior<br>
>> >> >>> >> >>> >> >> >> wrote:<br>
>> >> >>> >> >>> >> >> >>>> Anybody get a chance to look at the strace? I<br>
>> >> >>> >> >>> >> >> >>>> see<br>
>> >> >>> >> >>> >> >> >>>> a:<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> Henning> strace and packet dumps are much too<br>
>> >> >>> >> >>> >> >> >> lowlevel<br>
>> >> >>> >> >>> >> >> >> to<br>
>> >> >>> >> >>> >> >> >> directly<br>
>> >> >>> >> >>> >> >> >> Henning> hunt problems like this. Thats why<br>
>> >> >>> >> >>> >> >> >> Saverios<br>
>> >> >>> >> >>> >> >> >> question<br>
>> >> >>> >> >>> >> >> >> about<br>
>> >> >>> >> >>> >> >> >> Henning> txtinfo good, because it gives you a much<br>
>> >> >>> >> >>> >> >> >> more<br>
>> >> >>> >> >>> >> >> >> high-level<br>
>> >> >>> >> >>> >> >> >> Henning> view on what is going on.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> I had not installed the modules previously, so that<br>
>> >> >>> >> >>> >> >> >> interface<br>
>> >> >>> >> >>> >> >> >> wasn't<br>
>> >> >>> >> >>> >> >> >> immediately available. It is now.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> [...]<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> Henning> Okay, lets get back to the high-level<br>
>> >> >>> >> >>> >> >> >> view.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> Henning> To interpret the events you described we<br>
>> >> >>> >> >>> >> >> >> need<br>
>> >> >>> >> >>> >> >> >> a<br>
>> >> >>> >> >>> >> >> >> list<br>
>> >> >>> >> >>> >> >> >> of<br>
>> >> >>> >> >>> >> >> >> Henning> nodes, with their interface IPs and the<br>
>> >> >>> >> >>> >> >> >> connectivity<br>
>> >> >>> >> >>> >> >> >> between<br>
>> >> >>> >> >>> >> >> >> Henning> them.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> Here is the list of neighbors of<br>
>> >> >>> >> >>> >> >> >> 2001:470:e962::407.<br>
>> >> >>> >> >>> >> >> >> The<br>
>> >> >>> >> >>> >> >> >> addresses<br>
>> >> >>> >> >>> >> >> >> listed are on the public wifi. The OpenVPN<br>
>> >> >>> >> >>> >> >> >> addresses<br>
>> >> >>> >> >>> >> >> >> of<br>
>> >> >>> >> >>> >> >> >> each<br>
>> >> >>> >> >>> >> >> >> node<br>
>> >> >>> >> >>> >> >> >> are<br>
>> >> >>> >> >>> >> >> >> a permutation, e.g. if the public wifi addr is<br>
>> >> >>> >> >>> >> >> >> 2001:470:e962:wxyz::1,<br>
>> >> >>> >> >>> >> >> >> then the OpenVPN address of the node is<br>
>> >> >>> >> >>> >> >> >> 2001:470:e962::wxyz.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> None of the nodes connect directly, everything goes<br>
>> >> >>> >> >>> >> >> >> through<br>
>> >> >>> >> >>> >> >> >> ::407.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> From curl -6 http://localhost:$port/neighbors<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> <a href="https://personaltelco.net/~russell/olsrd/olsrd-neighbors.txt" target="_blank">https://personaltelco.net/~russell/olsrd/olsrd-neighbors.txt</a><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> Henning> I am also a bit worried about your usage<br>
>> >> >>> >> >>> >> >> >> of<br>
>> >> >>> >> >>> >> >> >> bridges<br>
>> >> >>> >> >>> >> >> >> Henning> connected to mesh interfaces. Normally<br>
>> >> >>> >> >>> >> >> >> you<br>
>> >> >>> >> >>> >> >> >> should<br>
>> >> >>> >> >>> >> >> >> no<br>
>> >> >>> >> >>> >> >> >> bridge<br>
>> >> >>> >> >>> >> >> >> Henning> any interface that OLSR uses for meshing.<br>
>> >> >>> >> >>> >> >> >> Mixing<br>
>> >> >>> >> >>> >> >> >> routing<br>
>> >> >>> >> >>> >> >> >> Henning> (L3) and bridging (L2) can go wrong in<br>
>> >> >>> >> >>> >> >> >> very<br>
>> >> >>> >> >>> >> >> >> creative<br>
>> >> >>> >> >>> >> >> >> ways.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> I don't understand how the bridges could be a<br>
>> >> >>> >> >>> >> >> >> problem<br>
>> >> >>> >> >>> >> >> >> in<br>
>> >> >>> >> >>> >> >> >> this<br>
>> >> >>> >> >>> >> >> >> case.<br>
>> >> >>> >> >>> >> >> >> This is a hub and spoke topology. One openvpn<br>
>> >> >>> >> >>> >> >> >> server<br>
>> >> >>> >> >>> >> >> >> in<br>
>> >> >>> >> >>> >> >> >> the<br>
>> >> >>> >> >>> >> >> >> middle,<br>
>> >> >>> >> >>> >> >> >> nodes at the edges. None of the nodes interconnect<br>
>> >> >>> >> >>> >> >> >> otherwise.<br>
>> >> >>> >> >>> >> >> >> Olsr<br>
>> >> >>> >> >>> >> >> >> is broadcast on the wifi in case there are any<br>
>> >> >>> >> >>> >> >> >> olsrd<br>
>> >> >>> >> >>> >> >> >> devices<br>
>> >> >>> >> >>> >> >> >> nearby,<br>
>> >> >>> >> >>> >> >> >> but, again, there is no overlap in the wifi<br>
>> >> >>> >> >>> >> >> >> coverage<br>
>> >> >>> >> >>> >> >> >> (and<br>
>> >> >>> >> >>> >> >> >> if<br>
>> >> >>> >> >>> >> >> >> there<br>
>> >> >>> >> >>> >> >> >> were physically, they are on different SSIDs and<br>
>> >> >>> >> >>> >> >> >> wouldn't<br>
>> >> >>> >> >>> >> >> >> overlap<br>
>> >> >>> >> >>> >> >> >> logically).<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> Can you explain more about what in particularly<br>
>> >> >>> >> >>> >> >> >> would<br>
>> >> >>> >> >>> >> >> >> make<br>
>> >> >>> >> >>> >> >> >> you<br>
>> >> >>> >> >>> >> >> >> worry?<br>
>> >> >>> >> >>> >> >> >> This configuration has been stable for us on ipv4<br>
>> >> >>> >> >>> >> >> >> for<br>
>> >> >>> >> >>> >> >> >> years<br>
>> >> >>> >> >>> >> >> >> and<br>
>> >> >>> >> >>> >> >> >> also<br>
>> >> >>> >> >>> >> >> >> on ipv6 until very recently, since late 2012 at<br>
>> >> >>> >> >>> >> >> >> least.<br>
>> >> >>> >> >>> >> >> >> So, I<br>
>> >> >>> >> >>> >> >> >> suspect<br>
>> >> >>> >> >>> >> >> >> a bug. Somewhere.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> Henning> Txtinfo output would be good (especially<br>
>> >> >>> >> >>> >> >> >> /route)<br>
>> >> >>> >> >>> >> >> >> would<br>
>> >> >>> >> >>> >> >> >> be<br>
>> >> >>> >> >>> >> >> >> Henning> good to see... before the problem, during<br>
>> >> >>> >> >>> >> >> >> the<br>
>> >> >>> >> >>> >> >> >> problem<br>
>> >> >>> >> >>> >> >> >> and<br>
>> >> >>> >> >>> >> >> >> Henning> after the recovery.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> I'm using curl -6 http://localhost:$port/routes to<br>
>> >> >>> >> >>> >> >> >> get<br>
>> >> >>> >> >>> >> >> >> the<br>
>> >> >>> >> >>> >> >> >> following<br>
>> >> >>> >> >>> >> >> >> data, before, during and after turning on an ipv6<br>
>> >> >>> >> >>> >> >> >> olsrd<br>
>> >> >>> >> >>> >> >> >> on a<br>
>> >> >>> >> >>> >> >> >> particular node (2001:470:e962:11c1::1).<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> <a href="https://personaltelco.net/~russell/olsrd/olsrd-routes-before.txt" target="_blank">https://personaltelco.net/~russell/olsrd/olsrd-routes-before.txt</a><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> <a href="https://personaltelco.net/~russell/olsrd/olsrd-routes-during.txt" target="_blank">https://personaltelco.net/~russell/olsrd/olsrd-routes-during.txt</a><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> <a href="https://personaltelco.net/~russell/olsrd/olsrd-routes-after.txt" target="_blank">https://personaltelco.net/~russell/olsrd/olsrd-routes-after.txt</a><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> Henning> It would also help if you can reduce the<br>
>> >> >>> >> >>> >> >> >> number<br>
>> >> >>> >> >>> >> >> >> of<br>
>> >> >>> >> >>> >> >> >> nodes<br>
>> >> >>> >> >>> >> >> >> Henning> while still replicating the problem to a<br>
>> >> >>> >> >>> >> >> >> minimum.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> I don't have that level of control, unfortunately.<br>
>> >> >>> >> >>> >> >> >> When<br>
>> >> >>> >> >>> >> >> >> I<br>
>> >> >>> >> >>> >> >> >> notice<br>
>> >> >>> >> >>> >> >> >> that<br>
>> >> >>> >> >>> >> >> >> the ipv6 routes have collapsed, I pick a likely<br>
>> >> >>> >> >>> >> >> >> seeming<br>
>> >> >>> >> >>> >> >> >> node<br>
>> >> >>> >> >>> >> >> >> (maybe<br>
>> >> >>> >> >>> >> >> >> because it had been plugged in recently) and turn<br>
>> >> >>> >> >>> >> >> >> off<br>
>> >> >>> >> >>> >> >> >> ipv6<br>
>> >> >>> >> >>> >> >> >> olsrd,<br>
>> >> >>> >> >>> >> >> >> and<br>
>> >> >>> >> >>> >> >> >> over 30-60 seconds, magically the routes all come<br>
>> >> >>> >> >>> >> >> >> back.<br>
>> >> >>> >> >>> >> >> >> My<br>
>> >> >>> >> >>> >> >> >> luck<br>
>> >> >>> >> >>> >> >> >> in<br>
>> >> >>> >> >>> >> >> >> guessing the right node to turn off is a little bit<br>
>> >> >>> >> >>> >> >> >> "too<br>
>> >> >>> >> >>> >> >> >> good",<br>
>> >> >>> >> >>> >> >> >> if<br>
>> >> >>> >> >>> >> >> >> you<br>
>> >> >>> >> >>> >> >> >> know what I mean, so that I am not sure there is<br>
>> >> >>> >> >>> >> >> >> anything<br>
>> >> >>> >> >>> >> >> >> particularly<br>
>> >> >>> >> >>> >> >> >> unique about the node I choose. But, nevertheless,<br>
>> >> >>> >> >>> >> >> >> turning<br>
>> >> >>> >> >>> >> >> >> it<br>
>> >> >>> >> >>> >> >> >> off<br>
>> >> >>> >> >>> >> >> >> seems to help, generally.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> FWIW, I'm including olsrd versions here. The<br>
>> >> >>> >> >>> >> >> >> central<br>
>> >> >>> >> >>> >> >> >> machine<br>
>> >> >>> >> >>> >> >> >> ::407<br>
>> >> >>> >> >>> >> >> >> is<br>
>> >> >>> >> >>> >> >> >> running 0.6.6.1, compiled from the tarball. The<br>
>> >> >>> >> >>> >> >> >> nodes<br>
>> >> >>> >> >>> >> >> >> have<br>
>> >> >>> >> >>> >> >> >> the<br>
>> >> >>> >> >>> >> >> >> following versions, all built from openwrt routing<br>
>> >> >>> >> >>> >> >> >> feed<br>
>> >> >>> >> >>> >> >> >> sources.<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> <a href="https://personaltelco.net/~russell/olsrd/olsrd-versions-by-node.txt" target="_blank">https://personaltelco.net/~russell/olsrd/olsrd-versions-by-node.txt</a><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> Here is a table listing the frequency of each<br>
>> >> >>> >> >>> >> >> >> openwrt<br>
>> >> >>> >> >>> >> >> >> version:<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> 1 0.6.3-3<br>
>> >> >>> >> >>> >> >> >> 33 0.6.4-1<br>
>> >> >>> >> >>> >> >> >> 1 0.6.5.1-1<br>
>> >> >>> >> >>> >> >> >> 1 0.6.5.1-2<br>
>> >> >>> >> >>> >> >> >> 7 0.6.5.2-1<br>
>> >> >>> >> >>> >> >> >> 1 0.6.5.3-1<br>
>> >> >>> >> >>> >> >> >> 2 0.6.5.4-1<br>
>> >> >>> >> >>> >> >> >> 2 0.6.6-2<br>
>> >> >>> >> >>> >> >> >> 7 0.6.6-3<br>
>> >> >>> >> >>> >> >> >> 11 0.6.6.1-1<br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> --<br>
>> >> >>> >> >>> >> >> >> Russell Senior, President<br>
>> >> >>> >> >>> >> >> >> <a href="mailto:russell@personaltelco.net">russell@personaltelco.net</a><br>
>> >> >>> >> >>> >> >> >><br>
>> >> >>> >> >>> >> >> >> --<br>
>> >> >>> >> >>> >> >> >> Olsr-users mailing list<br>
>> >> >>> >> >>> >> >> >> <a href="mailto:Olsr-users@lists.olsr.org">Olsr-users@lists.olsr.org</a><br>
>> >> >>> >> >>> >> >> >> <a href="https://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
>> >> >>> >> >>> >> >> ><br>
>> >> >>> >> >>> >> >> > --<br>
>> >> >>> >> >>> >> >> > Olsr-dev mailing list<br>
>> >> >>> >> >>> >> >> > <a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>
>> >> >>> >> >>> >> >> > <a href="https://lists.olsr.org/mailman/listinfo/olsr-dev" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-dev</a><br>
>> >> >>> >> >>> >> ><br>
>> >> >>> >> >>> >> ><br>
>> >> >>> >> >>> ><br>
>> >> >>> >> >>> ><br>
>> >> >>> >> >><br>
>> >> >>> >> >><br>
>> >> >>> >> ><br>
>> >> >>> ><br>
>> >> >>> ><br>
>> >> >><br>
>> >> >><br>
>> >> ><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>