[OpenWrt-Devel] watchping

Saverio Proto zioproto at gmail.com
Mon Jul 6 16:49:45 EDT 2015


Hello Bruno,

yet another tool used in Ninux.org:

https://github.com/ninuxorg/misc_tools/tree/master/adsl_check

What you want to implement is a generic tool... that checks a network
condition and if this condition happens triggers an event.

Yes it would be a nice tool. However routing protocols implementations
have to provide some kind of API to make possible for the tool to make
some actions once a condition is met.

Saverio



2015-07-06 20:54 GMT+02:00 Bruno Randolf <br1 at thinktube.com>:
> Hi Juliusz and all,
>
> Exporting a route to a routing protocol was just one example of what
> could be done based on the fact that internet connectivity is available
> on an interface. There are other uses one could imagine:
>  - Activate a backup interface, say a 3G connection
>  - Announce a default GW or not (routing proto or DHCP).
>  - Check for firmware upgrades on a public server
>  - Start or reconfigure a service
>
> Second, a default route is not enough: what counts is wether inernet
> connectivity is available thru that route. Sometimes a router announces
> a default route but is not connected itself, or problems exist
> "upstream". In that sense it's probably like your "babel-pinger" but
> more generic.
>
> The mwan3 package seems do do a similar thing in a script. Do you think
> it could profit from a C-based ubus service? Would it make sense?
>
> bruno
>
>
>
> On 07/03/2015 09:19 PM, Juliusz Chroboczek wrote:
>> Hi Bruno,
>>
>>> Sometimes it's necessary to re-configure an OpenWRT system based on the
>>> fact wether Internet connectivity is available on a certain interface.
>> [...]
>>> One example where this is useful is: When Internet is available, we
>>> configure BATMAN to act as a gateway 'server', if not as a gateway
>>> 'client'.
>>
>> I think that a solution that relies on distribution scripts is inherently
>> brittle.  The routing daemon should be able to detect the current
>> configuration, in a distribution-independent manner, and automatically
>> adapt to the current situation.  This is what happens with babeld -- it is
>> able to automatically redistribute a kernel route (typically the default
>> route, but not necessarily) into the routing protocol.
>>
>> I know of three ways of automatically obtaining a default route, in
>> descending order of preference:
>>
>>   - if the other end of the Internet connection speaks RIP, RIPng or OSPF,
>>     we run Quagga on the gateway and redistribute into Babel;
>>
>>   - if DHCPv4 is reliable (it usually is), then we simply redistribute the
>>     DHCP-provided route into the routing protocol;
>>
>>   - if DHCPv4 is unreliable, we use the "babel-pinger" utility which
>>     pings a remote host and installs a route depending on its availability.
>>
>> Additionally, there is some very promising but still experimental work to
>> provide a fully general and highly integrated solution in the "hnetd-full"
>> package.
>>
>> -- Juliusz
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list