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.