[LARTC] Failover to modem assistance req

[LARTC] Failover to modem assistance req

[gypsy]

I have installed Julian Anastasov's patch to the 2.4.20 kernel.  I have
a 256/256 SDSL connection using eth1 and a 56K dialup connection on
ppp0.  It is the ppp0 that is killing me because I can't figure out what
the gateway and broadcast addresses are.  Well, I think I have them
correct but I get a NETWORK IS UNREACHABLE when I run my 'nano.sh'
script...

My objective is to have the modem connection take over when the DSL
fails.  The DSL fails as the result of temperature and humidity
fluctuations that cause a disconnect :(

When ppp0 connects, /etc/ppp/ip-up.local records the Local IP and the
Server IP assigned by 'awk'ing the output of 'ifconfig ppp0'.  At this
point, I have a PPP connection (DSL is not functional, but 'ping -c1
yahoo.com' works), so I run the following script.  I 'cat' the assigned
IP values into 'nano.sh' (see next).  Here is the output of nano.sh:

> + IFI=eth0
> + IPI\x192.168.223.254
> + NMI$
> + IFE1=eth1
> + IFE2=ppp0
> + IPE1\x168.103.240.89
> ++ cat /etc/firewall/localIP
> + IPE2e.148.108.213
> + NWE1\x168.103.240.88
> ++ cat /etc/firewall/remoteIP
> + NWE2c.152.12.7
> + NME1)
> + NME22
> + BRD1\x168.103.240.255
> ++ cat /etc/firewall/localIP
> + BRD2e.148.108.213
> + GWE1\x168.103.240.94
> ++ cat /etc/firewall/remoteIP
> + GWE2c.152.12.7
> + ip link set eth0 up
> + ip addr add 192.168.223.254/24 brd + dev eth0
> RTNETLINK answers: File exists
> + ip rule add prio 50 table main
> + ip route del default table main
> RTNETLINK answers: No such process
> + ip link set eth1 up
> + ip addr flush dev eth1
> + ip addr add 168.103.240.89/29 brd 168.103.240.255 dev eth1
> + ip link set ppp0 up
> + ip addr flush dev ppp0
> Nothing to flush.
> + ip addr add 65.148.108.213/32 brd 65.148.108.213 dev ppp0
> + ip rule add prio 201 from 168.103.240.88/29 table 201
> + ip route add default via 168.103.240.94 dev eth1 src 168.103.240.89 proto static table 201
> + ip route append prohibit default table 201 metric 1 proto static
> RTNETLINK answers: File exists
> + ip rule add prio 202 from 63.152.12.7/32 table 202
> + ip route add default via 63.152.12.7 dev ppp0 src 65.148.108.213 proto static table 202
> RTNETLINK answers: Network is unreachable
> + ip route append prohibit default table 202 metric 1 proto static
> RTNETLINK answers: File exists
> + ip rule add prio 222 table 222
> + ip route add default table 222 proto static
> RTNETLINK answers: No such device
[--snip--]

What am I doing wrong?

Also, if posible, I'd like to add the 50K from the modem so I get 256 +
50 = 306K in.  (Can I use 'ip route add default equalize nexthop via'?)

Any pointers greatfully accepted!  

gypsy
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Failover to modem assistance req

[Paul Evans]

On May 11, 2003 20:46 pm, gypsy wrote:
> My objective is to have the modem connection take over when the DSL
> fails.  The DSL fails as the result of temperature and humidity
> fluctuations that cause a disconnect :(

I had one flakey modem for a few days. I set rp-PPPoE to:

CONNECT_TIMEOUT=0

from the default of 30. This makes it keep trying the connection infinitely 
until it wins. I know this works because I attached a script to ip-up.local 
to email us whenever the link went up which included that fact, plus the 
grepped syslog info and the new ip(s).

I put that timeout=0 in all adsl connections now. Since I have my router 
script set to run from ip-up.local, things get 'fixed' if another link comes 
up anyhow.

It won't help the temp/humid prob, but it will bring it up as soon as possible 
(at the expense of filling the log file with a bunch of failed attempts).

The above notion has been succesfull in overcoming both a flakey modem in one 
case and an equally flakey cable in another.

This is only with pppoe of course, if you have a normal ether connection over 
xdsl I don't have a fix for it, except to hang something from (I think 
Julian's) dead gw patch. Or, you could do that anyhow I guess.

Another thing you could do that's kind of klugy, is to just ping gw, sleep x 
until it fails and then bring up the dialup line and change the routing 
tables and incorporate that kind of logic into ip-up until the xdsl comes 
back and you can swx gw's.

Just one thought anyhow.

Oh, and re the temp/humid, you could graph the stuff over a week or so and 
pick an alarm level and have something email/phone you when it's going bad. 
You can get temp from sensorsd and match it to the problem. No simple/quick 
way of getting humidity values without some wx h/w, but wouldn't be *that 
expensive.

-- 
Regards, Paul Evans




_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/