Re: [Babel-users] Babel instability in WLAN-SI

Hi! On Mon, Dec 14, 2015 at 11:39 AM, Juliusz Chroboczek wrote: > I'd like more evidence that this is needed. Estimating packet loss is > very slow (since we're computing a metric from what is just a discrete, > one-bit signal), so it slows down convergence.

Re: [Babel-users] Babel instability in WLAN-SI

Hello! On 14. 12. 2015 15:40, Juliusz Chroboczek wrote: > I look at node urban-1: Yes, this is probably due to the use of some Ubiquity L2 bridges. We will look into that. Jernej signature.asc Description: OpenPGP digital signature ___ Babel-users

Re: [Babel-users] Babel instability in WLAN-SI

Hello! Yes, Mitar is planning to display this information graphically as a small heatmap. Jernej On 14. 12. 2015 15:53, Juliusz Chroboczek wrote: > And while I have your ear, could you please display the reachability field > in hex? It's a bitmap, so it's difficult to read in decimal. >

Re: [Babel-users] Babel instability in WLAN-SI

And while I have your ear, could you please display the reachability field in hex? It's a bitmap, so it's difficult to read in decimal. ___ Babel-users mailing list Babel-users@lists.alioth.debian.org

Re: [Babel-users] Babel instability in WLAN-SI

> If I look at the nodewatcher database, I see that there's a number of > wireless links that were incorrectly detected as wired. For example, if > I look at node urban-1: > > https://nodes.wlan-si.net/node/abe997c1-5f28-4d5f-8335-b3af182b0de4/ > > I see that most of the links have a TX-cost of

Re: [Babel-users] Babel instability in WLAN-SI

> I remember a case in Vienna where an Olsr daemon was its own neighbor, > because (over a bridged connection) one of its 2.4 GHz neighbors > bridged everything to a 5 GHz interface the local node could hear. That's not the issue here -- a Babel node is allowed to be its own neighbour, and this

[Babel-users] Multiple interfaces [was: Bucket full, dropping packet]

> I have VPS running babel and tunneldigger which is part of Wlan Slovenia > network. If it helps I can give you [...] root access to this server Thanks a lot, Valent. It's interesting. When the network is stable, the traffic is normal, with the periodic full update taking 5 full-size packets.

Re: [Babel-users] Babel instability in WLAN-SI

Hello! We have now temporarily disabled the L2 bridge. On 14. 12. 2015 15:40, Juliusz Chroboczek wrote: > This is really bad, since on wired links babeld will disable link quality > estimation and cause the links to go down-up whenever two Hellos are lost > in a row. BTW, how should VPN links

Re: [Babel-users] Bucket full, dropping packet

>> Matthieu, do you understand why that is? Is there a way to optimise away >> conflict_solution in the easy case? > > I think so. Will fix it. The attached patch should solve the problem. As a conflict need a specific route, the first now loop iterates on specific routes only. If there is

Re: [Babel-users] Bucket full, dropping packet

> The attached patch should solve the problem. Nice, applied. > +if(!check_specific_first()) > +fprintf(stderr, "Invariant failed: specific routes first in RIB.\n"); #ifdef DEBUG, or if(debug_level >= 2) ? -- Juliusz ___ Babel-users

Re: [Babel-users] Bucket full, dropping packet

On Mon, Dec 14, 2015 at 8:15 PM, Dave Taht wrote: > Is there a reliable way of determining that an underlying interface is a > bridge? A local bridge/wifi? Sure... just look into the source of the brctl tool... it can give you a list of all bridge interfaces. A "wifi

Re: [Babel-users] Babel instability in WLAN-SI

> So luckily we do know which links are wireless and which are VPN, so > we could configure that in the Babel configuration. Cool. > About VPN, I think ideally, we would want a metric for VPN links which: > - take RTT into the account Already implemented, as you know. > - take packet loss into

Re: [Babel-users] Babel instability in WLAN-SI

Hi! So luckily we do know which links are wireless and which are VPN, so we could configure that in the Babel configuration. About VPN, I think ideally, we would want a metric for VPN links which: - take RTT into the account - take packet loss into the account - take available bandwidth vs. used

Re: [Babel-users] Bucket full, dropping packet

> #ifdef DEBUG, or if(debug_level >= 2) ? Well, I was not sure about this one. The problem with debug_level is that it produces too verbose output, it's not just "checks". I was rather thinking about having a test-mode version of babeld, which let the clean babeld-code as-is, and add some

Re: [Babel-users] Babel instability in WLAN-SI

> BTW, how should VPN links be handled in this case? They are currently > marked as wired, but they can also experience packet loss. Does this > mean that bad VPN links can also cause huge amounts of control traffic? It depends. How likely are they to lose two Hellos in a row? Babeld marks a