Very Computer

Question:

Is it possible to make the PPP device persist, even after losing a
connection?

The reason I'd like to do this, is that when the device goes away, all
firewall and routing rules for it are cleaned up by the kernel.  The
device completely disappears.  If the device later comes back, it will
have lost all of its rules.

Also, having the device stay around would make it easy to avoid
problems trying to chase down ppp0, ppp1, ppp2, etc. during
complicated situations (for example, running a tunnel over a PPPoE DSL
connection, which will require two PPP devices).

Regular Ethernet devices (eth0, eth1, eth2, etc.) are able to survive
a loss of connection, and still maintain their configuration.  They
just have their RUNNING flags bit cleared (as visible with
"ifconfig").  Unplug your Ethernet cable right now, and see.  When the
connection comes back, the RUNNING flags bit is set again.  All of
this without having to redo any firewall or routing rules.  In
addition, the counters for statistics are not cleared for the
interface.

It would seem to greatly simplify the problems people are having now,
with reliable PPPoE connections, if ppp0 devices could simply have the
same "permanent" status that is given to an eth0 device.  The RUNNING
bit could be used from userspace to determine whether or not the
underlying link is connected or disconnected.

Has anybody else considered this, and if so, what was the outcome of
previous discussions?  Searching Google didn't seem to find anything
obviously about this.

Thanks!

Josh

Quote:> Question:

> Is it possible to make the PPP device persist, even after losing a
> connection?

Yes, it is possible.

Look at the "persist" option. You might also want the "demand" option,
to only dial out when there is outbound traffic.

Quote:> The reason I'd like to do this, is that when the device goes away, all
> firewall and routing rules for it are cleaned up by the kernel. ?The
> device completely disappears. ?If the device later comes back, it will
> have lost all of its rules.

That's easily fixed. Put your ppp-specific firewalling rules in /etc/
ppp/ip-up, and the firewall-teardown rules in /etc/ppp/ip-down

When your PPP session obtains an IP address, it can build the
firewalling rules necessary to protect that address, through the /etc/
ppp/ip-up script. When your PPP session loses its IP address, it can
build and execute the necessary firewall-teardown rules through the /
etc/ppp/ip-down script.

That's how I used to protect my dialup line, and it is how I still
protect my ADSL connection.

Take a look at http://slackworld.berlios.de/04/essence-1.html for
details.

Quote:> Also, having the device stay around would make it easy to avoid
> problems trying to chase down ppp0, ppp1, ppp2, etc. during
> complicated situations (for example, running a tunnel over a PPPoE DSL
> connection, which will require two PPP devices).

Again, see that webpage. There are some tips on simplifying that sort
of problem.

[snip]

HTH
--
Lew Pitcher

I load my netfilter rules before ppp0 exists (also before any ethN are
up).  They don't go away when the connection drops and ppp0 is destroyed.

I do have an IP address-dependent subset of quasi-RPF rules, but I have
to flush the old ones before setting the new ones when ppp0 bounces.

So I'm wondering what you're talking about when you seem to be saying
rules magically disappear on their own.

Quote:

> [snip]

Quote:> Look at the "persist" option. You might also want the "demand" option,
> to only dial out when there is outbound traffic.

I am already using the "persist" option.  It doesn't solve the
underlying problem: the ppp0 device disappears.  It goes away, when
the line hangs up.  It's true that the PPP program will attempt to
immediately redial, when "persist" is given, but until that redial
succeeds, the ppp0 device will not exist.  When the connection is re-
established, the ppp0 device (or whatever PPP number is available now)
will be re-created.

I'd like to make the same device survive a disconnection, without
needing to be destroyed then re-created.  That would greatly simplify
many firewalling and routing scripts.

Quote:> That's easily fixed. Put your ppp-specific firewalling rules in /etc/
> ppp/ip-up, and the firewall-teardown rules in /etc/ppp/ip-down

That could be done, and in fact, that is what is currently done.  I
was hoping to go beyond this workaround, though, and have a more
permanent solution, which is common for eth0 devices.  Those devices
are long-lived and their configuration will remain, even if the wire
is unplugged then later plugged back in again.

Quote:> Take a look athttp://slackworld.berlios.de/04/essence-1.htmlfor
> details.

Thanks, that seemed to only apply to kernel 2.4 though.

Josh

Quote:> I load my netfilter rules before ppp0 exists (also before any ethN are
> up). ?They don't go away when the connection drops and ppp0 is destroyed.

Interesting.  I didn't know that it would let you make rules that
apply to devices that don't exist.

Quote:> I do have an IP address-dependent subset of quasi-RPF rules, but I have
> to flush the old ones before setting the new ones when ppp0 bounces.

That would make sense, that you would have to change the firewalling
rules to take into account new IP addresses.  In this case, though, I
have a static IP address.

Quote:> So I'm wondering what you're talking about when you seem to be saying
> rules magically disappear on their own.

This has been my experience.  Linux cleans up the networking stack
pretty well, when a device disappears: the routing table is cleaned,
and the iptables rules are cleaned for those rules containing the
device.  Has the policy changed, now, to keep iptables rules still
alive, even when they refer to devices that no longer exist?  How does
the kernel handle this situation, does it simply ignore the rule or
drop the packet?

Josh

It's not new.  I've been a DSL customer since about 2003.  I've never
had to worry about rules vanishing with ppp0.

FWIW I set my rules (or rather, Fedora does it for me) before networking
starts.  For me, networking also means creating 802.1q interfaces, so I
have several interfaces that don't exist when netfilter gets loaded with
rules.  That's the way you *want* it to be.  There should never be a gap
between the time an interface comes up and the time packets get
filtered.  The only way to guarantee that is to load the rules beforehand.

If you have a rule that matches on a non-existent interface, it's not
exactly ignored.  It's checked the same as always.  When it fails to
match, processing continues with the next rule.  You shouldn't have to
worry about rules failing to match on non-existent incoming interfaces,
at all, if you think about it.

Routing info is dropped when a device goes away, of course.  (Actually
routing is dropped even if the device is down but still exists.)  That
shouldn't really be a problem.  Setting the default route when ppp0
comes up should be a trivial config already included with every distro.
 It's the defaultroute option for pppd.

Why? there is nothing there. ppp is dead. As suggested, put your
firewall rules into ip-up and ip-down

Quote:>> That's easily fixed. Put your ppp-specific firewalling rules in /etc/
>> ppp/ip-up, and the firewall-teardown rules in /etc/ppp/ip-down
>That could be done, and in fact, that is what is currently done.  I
>was hoping to go beyond this workaround, though, and have a more
>permanent solution, which is common for eth0 devices.  Those devices

Sorry, that IS a permanant solution.

Quote:>are long-lived and their configuration will remain, even if the wire
>is unplugged then later plugged back in again.

No. If you tear down the ethernet driver ( unload the module) it will
also disappear. That is equivalent to what happens when the ppp link
disappears.

Quote:>> Take a look athttp://slackworld.berlios.de/04/essence-1.htmlfor
>> details.
>Thanks, that seemed to only apply to kernel 2.4 though.
>Josh

Quote:> No. If you tear down the ethernet driver ( unload the module) it will
> also disappear. That is equivalent to what happens when the ppp link
> disappears.

The PPP link disappearing is equivalent to the Ethernet cable being
unplugged, or the router at the other end being turned off.  In
neither case does your Ethernet module get unloaded.  The Ethernet
device will never disappear from the system entirely.  That's
precisely the point I'm trying to make: PPP is treated differently
from Ethernet.

Ethernet has a nice feature that PPP doesn't have, namely, the fact
that its device can stay instantiated within the kernel even though
there is no link present.  I was considering adding that feature to
PPP, to give it parity with Ethernet.

Josh

But ethernet is a real physical interface, there's a dedicated piece
of hardware and a device driver for said hardware. PPP is more of a
virtual network connection over some sort of physical transport. For
example, a serial port. To continue with your analogy, when PPP stops,
the serial port doesn't disappear, it's still present.

        Jerry

Quote:> But ethernet is a real physical interface, there's a dedicated piece
> of hardware and a device driver for said hardware. PPP is more of a
> virtual network connection over some sort of physical transport. For
> example, a serial port. To continue with your analogy, when PPP stops,
> the serial port doesn't disappear, it's still present.

That's true, but a serial port isn't a network device.  It doesn't
have to be configured with routing rules, firewalling rules, counters,
addresses, and so on.

I still think that having "permanent" PPP devices, would make it
easier to deal with various networking situations as they arise.
Ethernet is quite robust, in that the link can go down then up again,
as an upstream router gets unplugged (for example) and the system need
not reconfigure itself.  This could bring the same stability to PPP.

Josh

What some forget is ppp has an endpoint addr defined only when the
interface comes up, look at the ifconfig output.  Also, the connection
negotiation provides the nameserver addresses.  These three addresses
are invalid when the connection is down (gone).

Thus, ppp uses ip-up and ip-down scripts to manage the connection and
associated firewalls.

For example, I use:

#!/bin/bash
#
# /etc/ppp/ip-up
#
# Copyright (C) 2004,2005 Grant Coady
#
# environment vars:
# DEVICE
# IFNAME
# IPLOCAL
# IPREMOTE
# PEERNAME
# SPEED
# ORIG_UID
# PPPLOGNAME
# CONNECT_TIME
# BYTES_SENT
# BYTES_RCVD
# LINKNAME
# DNS1
# DNS2

printf "%s %-4s %15s %15s %15s %15s\n" $(date "+%F.%T") "up" \
                $IPLOCAL $IPREMOTE $DNS1 $DNS2 >> /var/log/rp-pppoe

# set default route
/sbin/route add default gw ${IPREMOTE} netmask 0.0.0.0 metric 1

# bring up firewall
echo "PPPoE up -- $(date "+%F.%T")" > /var/log/ip-up
/etc/rc.d/rc.firewall restart $IFNAME $IPLOCAL >> /var/log/ip-up
#
# kick ntp
/usr/sbin/ntpd
#

#!/bin/bash
#
# /etc/ppp/ip-down
#
# Copyright (C) 2004,2005 Grant Coady
#
# environment vars:
# DEVICE
# IFNAME
# IPLOCAL
# IPREMOTE
# PEERNAME
# SPEED
# ORIG_UID
# PPPLOGNAME
# CONNECT_TIME
# BYTES_SENT
# BYTES_RCVD
# LINKNAME
# DNS1
# DNS2

printf "%s %-4s %15s %15s %15s\n" $(date "+%F.%T") "down" \
                $CONNECT_TIME $BYTES_RCVD $BYTES_SENT >> /var/log/rp-pppoe

# kill ntp
killall ntpd
#
# kill firewall
echo "PPPoE down -- $(date "+%F.%T")" > /var/log/ip-down
/etc/rc.d/rc.firewall >> /var/log/ip-down
#

Grant.
--
http://bugsplatter.id.au

Actually the same can also be true for ethernet devices; consider a
laptop that gets suspended and moved to a different location and
plugged into a different network.
Then there's wireless, which emulates an ethernet device. The laptop
would normally be connecting to an entirely different network after a
resume when you're travelling.

        Jerry