We´re very happy with PPPoE into our cable modem
´cept the whole link isn´t reliable :))))
... for at least the reason that France Telecom (French-govt-protected
monopoly), God bless 'em, cripples their ADSL service by inserting 3 minute
blackouts, at the next hop at end their end of the ADSL, link throughout
the day, (ping to next hop dead) to protect their exorbitantly priced
leased-line service.
Usually after these blackouts, our FreeBSD PPPoE router just waits until
FT´s box responds again and all is. We cast yet-another curse on FT,
re-start our ssh and pcAnywhere sessions, truck along.
The other pb is that sometimes, PPPoE doesn´t come back, and we wonder
whether maybe, in these cases, it´s really PPPoE halting, as I´ve seen
others report in these lists. It´s the PPP from 4.3-Release .iso.
We of course need better reliability in the face of whatever PPP halts, so
we´re trying to come up with a script we could run to take down the link
(tun0, ppp) and then bring it up, and not having much success. We also
run ipf and ipnat, so here´s what our script looks like:
ipf -D
killall ppp
kill `cat /var/run/ipmon.pid`
kill `cat /var/run/tun0.pid`
/usr/sbin/ppp -quiet -ddial -nat -unit0 meidsl
ipf -E
ipf -Fa -f /etc/ipf-stats.rules
ipnat -CF -f /etc/ipnat.rules
/usr/sbin/ipmon -Dna /var/log/ipmon/iplog
~
Running the above with the line up, we see this on the screen:
warning: /dev/tun0: Device busy
0 entries flushed from NAT table
0 entries flushed from NAT list
Aug 20 12:51:13 gw0 /kernel: IP Filter: v3.4.19 unloaded
gw0# Aug 20 12:51:13 gw0 /kernel: IP Filter: v3.4.19 unloaded
Aug 20 12:51:13 gw0 /kernel: IP Filter: v3.4.19 initialized. Default =
pass all, Logging = enabled
Aug 20 12:51:13 gw0 /kernel: IP Filter: v3.4.19 initialized. Default =
pass all, Logging = enabled
Aug 20 12:51:13 gw0 ppp[1002]: Warning: /dev/tun0: Device busy
but the line doesn´t come up, until we run the same ppprest.sh script a
second time and get this on the screen:
No matching processes were found
cat: /var/run/tun0.pid: No such file or directory
cat: /var/run/tun0.pid: No such file or directory
usage: kill [-s signal_name] pid ...
kill -l [exit_status]
kill -signal_name pid ...
kill -signal_number pid ...
Aug 20 12:52:23 gw0 /kernel: IP Filter: v3.4.19 unloaded
Aug 20 12:52:23 gw0 /kernel: IP Filter: v3.4.19 unloaded
0 entries flushed from NAT table
0 entries flushed from NAT list
gw0# Aug 20 12:52:23 gw0 /kernel: IP Filter: v3.4.19 initialized. Default
= pass all, Logging = enabled
Aug 20 12:52:23 gw0 /kernel: IP Filter: v3.4.19 initialized. Default =
pass all, Logging = enabled
and the PPP link comes up again.
We´ve tried a lot of different sequences for the script, but nothing works
ON THE FIRST SCRIPT RUN, so we think we´re got wrong or missing commands.
Any suggestions?
Also, anybody have any ideas for a probe that will distinguish between when
the FT blackout is the pb (ie, don´t run PPP restart script) vs when PPPoE
is hung?
Len
http://MenAndMice.com/DNS-training
http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K
http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
