Bug 44319

Description of Request:

This is actually a summary of several rp3, kudzu, and wvdial problems, in
addition to some ongoing issues with the network initialization scripts. 
Most of these are architectural and interface issues that need to be
resolved.  I'll attempt to cover as much as I can as briefly as possible:

1) rp3/wvdial autodetection does not handle/inspect devices besides the
/dev/ttySx and /dev/ttySRx.  This leaves out several categories,
particularly USB modems on /dev/usb/ttyACMx.  We should have a PPP tool
that can autodetect any modem on any normal port, and also allow for the
manual entry of anything unusual to cover all situations (rp3-config does
have this currently).  Alternatively, kudzu (the hardware detection code)
should detect the modem and configure a non-conflicting device for each
modem (see [2]).  Worst case (an ISA non-detectable modem) the PPP tool
should allow for manual configuration (rp3-config does do this currently).

2) kudzu handles the detection of available serial ports now, and in 7.1
will detect a PCI modem.  However, it assigns a PCI modem to /dev/ttyS0,
which is a problematic choice as it is very possible that device is already
in use by another piece of hardware.  A better default would be /dev/ttyS5,
which is out of the range of any motherboard ports.  Kudzu should also do
some sort of check to see if a particular /dev device is already in use,
but that might be beyond the scope of what we can do at this point.

3) There is no way (other than scripting in setserial commands or relying
on kudzu) to configure the system's serial ports.  This should be a GUI and
text-based tool, separate but accessible from the PPP configuration and
dialing interface.  We should avoid the Microsoft mistake of confusing
people about the difference between a COM port and the serial hardware it
represents -- the serial configuration tool should show clearly which port
is represented by which ttyS.

4) The dial-on-demand function for rp3 has consistently caused problems,
particularly with the manual initialization of the interface (Failed to
Initialize Interface...).  Dial on Demand should not stop the user from
manually dialing the connection, and the timeout/hangup sequence should be
configurable from the PPP configuration tool and should work (last ditch,
run a kill on the wvdial/pppd processes and clean things up itself).

5) The difference between the DeBug mode in rp3-config and the rp3 dialer
itself causes confusion for our users.  It sometimes happens that the the
debug mode (which simply runs wvdial) will work, and the dialer (which
essentially runs "ifup pppX" -- pppd using wvdial as a chat replacement)
will not.  Further, the DeBug mode isn't all that useful, because there are
very few options that can be altered if the connection is not working.  The
PPP configuration and dialing tool should be part of the same whole, and
the testing sequence and error display should reflect the same
initialization process as the dialing tool (interface control tool?).

6) There is no way in the rp3-config tool to pass modem initialization
parameters (init strings) if necessary.  There should be a provision for
that, even if it is nothing more than "the string is here in this file,
have at it."

7) The init scripts (ifup-ppp, ip-up) do not deal well with the case where
other interfaces are present.  For example, when another ethernet interface
with a default gateway is present, the init scripts remove that gateway and
replace it with the one from the PPP connection.  This is okay, except that
the scripts don't put the route back when they are done, leaving the
ethernet interface without a default route once the PPP session is done. 
As far as the system is concerned, there should be no difference between a
PPP-based IP interface and an Ethernet-based IP interface, or any other
interface for that matter (with one exception, PPPoE <shudder>).

8) There is very little provision for the configuration or use of PPPoE,
which is growing in popularity with cable and DSL providers.  As a result,
all of the ease-of-use that rp3 has is thrown out the window when using a
PPPoE connection.  However, PPPoE is a special case, and the included tool
(roaring penguin) is pretty good.  It would require quite a bit of
work(IMHO) to include PPPoE in the normal networking scripts and
configuration, but it would be a distinctly useful thing.

9) The firewalling configuration tool(s) should take PPP interfaces into
account and allow them to be configured even when they are down.  For
example, iptables allows this "off-line interface configuration".  Again,
PPPoE is an awkward special case that may need a good deal of attention.