I will probably not have need for it now when I have fiber, but I though it might be an idea to start a topic about it to see how people would like to behave.
I have tried it with a 3G modem as secondary (fail-over) WAN connection and noted a few disappointing issues (and I tried to browse the source to see how things worked, but I'm not a programmer so I might have missed some points).
The primary issue is that fail-over seems to only switch WAN when the currently used WAN goes down. But I think most users would want to use the primary WAN whenever it is up, and only use the secondary when primary is down (because the secondary probably is slower, more expensive and/or might have traffic limits).
This means that the primary WAN connection would have to be regularly "probed" to find out when it goes up again. And this connects to the next issue.
A second issue is that the way the router detects WAN down seems to rely on the ethernet link status. Often the ethernet link is up but there is failed connection somewhere on the way to the internet (providers router down or something like that). So, there would be a need for a possibility to configure some kind of active probes (for example pinging an external host or pulling a page using wget or similar) to be able to assess the internet connection rather than the WAN ethernet link.
A third issue is that QoS probably would have to be set up with different max rates for the secondary WAN. If the secondary WAN has traffic limits maybe some traffic would have to be blocked too (for example if your 3G has limits like 5GB a month you wouldn't want your bittorrent client using up that traffic).
I was thinking about the best ways to solve these issues.
The first one does probably need some patching, but I think a clever patching (for example to support semaphore files in addition to the current logic) could make the other issues possible to solve using scripts.
For example the code could be written so when a file called wan_down is created it will switch to secondary WAN. When the wan_down sempahore disappear the router switches back to primary. (There might be some race conditions that have to be handled.)
That way "power users" could craft their own scripts for the probing, when the script detects that the primary WAN is down it creates the semaphore and keeps probing. When it detects that primary WAN is up again it just removes the semaphore.
The QoS configuration as well as changed iptables rules could probably be changed using scripts like the Merlin jffs features. A few if-statements in the scripts could be used to select different parts depending on what WAN interface is used (not sure if it currently is possible from a script to detect which interface is used, but I guess that it would be easy to solve using semaphore files too).
I have tried it with a 3G modem as secondary (fail-over) WAN connection and noted a few disappointing issues (and I tried to browse the source to see how things worked, but I'm not a programmer so I might have missed some points).
The primary issue is that fail-over seems to only switch WAN when the currently used WAN goes down. But I think most users would want to use the primary WAN whenever it is up, and only use the secondary when primary is down (because the secondary probably is slower, more expensive and/or might have traffic limits).
This means that the primary WAN connection would have to be regularly "probed" to find out when it goes up again. And this connects to the next issue.
A second issue is that the way the router detects WAN down seems to rely on the ethernet link status. Often the ethernet link is up but there is failed connection somewhere on the way to the internet (providers router down or something like that). So, there would be a need for a possibility to configure some kind of active probes (for example pinging an external host or pulling a page using wget or similar) to be able to assess the internet connection rather than the WAN ethernet link.
A third issue is that QoS probably would have to be set up with different max rates for the secondary WAN. If the secondary WAN has traffic limits maybe some traffic would have to be blocked too (for example if your 3G has limits like 5GB a month you wouldn't want your bittorrent client using up that traffic).
I was thinking about the best ways to solve these issues.
The first one does probably need some patching, but I think a clever patching (for example to support semaphore files in addition to the current logic) could make the other issues possible to solve using scripts.
For example the code could be written so when a file called wan_down is created it will switch to secondary WAN. When the wan_down sempahore disappear the router switches back to primary. (There might be some race conditions that have to be handled.)
That way "power users" could craft their own scripts for the probing, when the script detects that the primary WAN is down it creates the semaphore and keeps probing. When it detects that primary WAN is up again it just removes the semaphore.
The QoS configuration as well as changed iptables rules could probably be changed using scripts like the Merlin jffs features. A few if-statements in the scripts could be used to select different parts depending on what WAN interface is used (not sure if it currently is possible from a script to detect which interface is used, but I guess that it would be easy to solve using semaphore files too).