Bug#265183: sarge-rc1 on ASUS laptop L8400-B - pppoe/ADSL networking troubles and other minor stuff
Package: installation-reports Severity: normal INSTALL REPORT Debian-installer-version: sarge rc1 rel 7Aug04, d/l from a mirror off debian.org uname -a: Linux travel 2.4.26-1-386 #1 Thu Jul 22 12:46:23 JST 2004 i686 GNU/Linux Date: Thu Aug 12 04:52:41 IDT 2004 Method: booted using the current sid boot.img, then it recognized a memory stick I had prepared with the sarge-i386-netinst.iso on it Network install then fetched stuff from the Israeli HTTP mirror (but see below for tweaks needed to have it work!) Machine: ASUS L8400-B, BIOS rev 0103 Processor: P/III Memory: 128Mb Root Device: /dev/hda Root Size/partition table: major minor #blocks name rio rmerge rsect ruse wio wmerge wsect wuse running use aveq 8 0 249600 scsi/host1/bus0/target0/lun0/disc 25 1216 2482 3230 4 0 8 20 0 1880 3250 8 1 132705 scsi/host1/bus0/target0/lun0/part1 0 0 0 0 0 0 0 0 0 0 0 8 2 116632 scsi/host1/bus0/target0/lun0/part2 24 1213 2474 3220 4 0 8 20 0 1870 3240 3 0 11789568 ide/host0/bus0/target0/lun0/disc 41522 237454 1999578 744640 30313 341332 2412476 14840280 -1 4207000 11218840 3 14672048 ide/host0/bus0/target0/lun0/part1 0 0 0 0 0 0 0 0 0 0 0 3 2 1 ide/host0/bus0/target0/lun0/part2 0 0 0 0 0 0 0 0 0 0 0 3 51013008 ide/host0/bus0/target0/lun0/part5 0 0 0 0 0 0 0 0 0 0 0 3 6 15057 ide/host0/bus0/target0/lun0/part6 26 551 1154 840 8 1 18 20 0 650 860 3 71171768 ide/host0/bus0/target0/lun0/part7 2959 35147 76236 56490 4356 89363 187586 560360 0 59680 616850 3 8 377968 ide/host0/bus0/target0/lun0/part8 1793 8193 79888 31420 1272 15359 134072 72610 0 29950 104140 3 94535968 ide/host0/bus0/target0/lun0/part9 36738 193545 1842252 655770 24677 236609 2090800 14207290 0 439130 14863070 364 655364 hdb 0 0 0 0 0 0 0 0 -9 4348130 3816632 # /etc/fstab: static file system information. # # proc/proc procdefaults0 0 /dev/hda9 / ext3defaults,errors=remount-ro 0 1 /dev/hda6 /boot ext3defaults0 2 /dev/hda7 /varext3defaults0 2 /dev/hda8 noneswapsw 0 0 /dev/hdb/media/cdrom0 iso9660 ro,user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 /dev/sda1 /media/usb0 autorw,user,noauto 0 0 /dev/sda/media/usb1 autorw,user,noauto 0 0 Output of lspci and lspci -n: :00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) :00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) :00:06.0 Multimedia audio controller: Aureal Semiconductor AU8810 Vortex Digital Audio Processor (rev 03) :00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) :00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) :00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) :00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03) :00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) :00:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) :00:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) :01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/MX-MV (rev 11) :00:00.0 0600: 8086:7190 (rev 03) :00:01.0 0604: 8086:7191 (rev 03) :00:06.0 0401: 12eb:0003 (rev 03) :00:07.0 0601: 8086:7110 (rev 02) :00:07.1 0101: 8086:7111 (rev 01) :00:07.2 0c03: 8086:7112 (rev 01) :00:07.3 0680: 8086:7113 (rev 03) :00:08.0 0200: 10ec:8139 (rev 10) :00:0a.0 0607: 1180:0476 (rev 80) :00:0a.1 0607: 1180:0476 (rev 80) :01:00.0 0300: 5333:8c10 (rev 11) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [E] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] Comments/Problems: 1) Why I didn't boot from the stick directly. This being a university laptop I borrowed for a travel, I didn't want to get stuck if smth goes wrong during the flash bios upgrade. Hence I couldn't boot off the USB memory stick directly, but rather used the boot floppy. Once it booted, it recognized the plugged in USB drive like a charm. Maybe it would be better if d-i didn't ask for pressing enter if the USB drive is already in and recognized. 2) Weird partition size issues on the USB stick. The stick image (I used the quick method of dumping the USB stick image onto /dev/sda1) produced an interesting effe
Bug#265183: pppoe workaround of the post-reboot problem
The thing that happens as a by-product of pppoeconf that enables the pppoe to work later on is the loading of the pppoe module. So to have pppoe working after reboot, `modprobe pppoe' is needed before `pon dsl-provider'. I think pppoeconf should have done something differently with the files it generated so that the module loading would have been transparent to the user. FWIW, here's the /etc/ppp/peers/dsl-provider it had generated. See this also in connection with the routing quirk described in the original report (that had to be worked around with the assigning of a static address). Eduard: please feel free to fork #265183 to pppoeconf bugs (on the routing and the module loading issues), or just ask me to do so. (However, I'm going on vacation and will be offline for the next week, though, so I'll be unable to open the new bugs right away). # Configuration file for PPP, using PPP over Ethernet # to connect to a DSL provider. # # See the manual page pppd(8) for information on all the options. ## # Section 1 # # Stuff to configure... # MUST CHANGE: Uncomment the following line, replacing the [EMAIL PROTECTED] # by the DSL user name given to your by your DSL provider. # (There should be a matching entry in /etc/ppp/pap-secrets with the password.) #user [EMAIL PROTECTED] # Use the pppoe program to send the ppp packets over the Ethernet link # This line should work fine if this computer is the only one accessing # the Internet through this DSL connection. This is the right line to use # for most people. #pty "/usr/sbin/pppoe -I eth0 -T 80 -m 1452" # An even more conservative version of the previous line, if things # don't work using -m 1452... #pty "/usr/sbin/pppoe -I eth0 -T 80 -m 1412" # If the computer connected to the Internet using pppoe is not being used # by other computers as a gateway to the Internet, you can try the following # line instead, for a small gain in speed: #pty "/usr/sbin/pppoe -I eth0 -T 80" # The following two options should work fine for most DSL users. # Assumes that your IP address is allocated dynamically # by your DSL provider... noipdefault # Try to get the name server addresses from the ISP. usepeerdns # Use this connection as the default route. # Comment out if you already have the correct default route installed. defaultroute ## # Section 2 # # Uncomment if your DSL provider charges by minute connected # and you want to use demand-dialing. # # Disconnect after 300 seconds (5 minutes) of idle time. #demand #idle 300 ## # Section 3 # # You shouldn't need to change these options... hide-password lcp-echo-interval 20 lcp-echo-failure 3 # Override any connect script that may have been set in /etc/ppp/options. connect /bin/true noauth persist mtu 1492 # RFC 2516, paragraph 7 mandates that the following options MUST NOT be # requested and MUST be rejected if requested by the peer: # Address-and-Control-Field-Compression (ACFC) noaccomp # Asynchronous-Control-Character-Map (ACCM) default-asyncmap plugin rp-pppoe.so eth0 user "[CENSORED]" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265183: sound works with ALSA, but doesn't survive apm suspend
Following some wisdom I've google(TM)d out there, I tried installing ALSA on the laptop (see the original posting on the bug thread for the specs). Sound works out of the box, except that it doesn't survive apm suspend/resume (i.e. after it happens, no app can open /dev/dsp, gets a device busy error). However, from what I am reading in alsa-base bugs, e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266272 there are now apm suspend scripts packaged with the future versions (in unstable). So I guess if I just wait it'll propagate to testing and everything will be fine. V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#254068: base-config log should not be world readable
Package: base-config Version: 2.25 Severity: normal Tags: security I believe that the base-config logs should not be world readable. Some of the packages ask for passwords that are echoed back during the configuration (e.g. pppoeconf), albeit stored later in files not readable by the world. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.25-1-686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R Versions of packages base-config depends on: ii adduser 3.56 Add and remove users and groups ii apt 0.5.25 Advanced front-end for dpkg ii aptitude0.2.14-3 curses-based apt frontend ii bsdutils1:2.12-3 Basic utilities from 4.4BSD-Lite ii console-data2002.12.04dbs-40 Keymaps, fonts, charset maps, fall ii console-tools 1:0.2.3dbs-52Linux console and font utilities ii debconf 1.4.25 Debian configuration management sy ii debianutils 2.8.2Miscellaneous utilities specific t ii gettext-base0.14.1-2 GNU Internationalization utilities ii passwd 1:4.0.3-28.3 Change and administer password and -- debconf information: tzconfig/choose_country_zone_single: true base-config/menu/mta: tzconfig/select_zone: tzconfig/verify_choices: true tzconfig/choose_country_zone/BR: East * base-config/intro: apt-setup/security-updates: true apt-setup/another: false mirror/distribution: testing base-config/title: base-config/menu/finish: debian-installer/language: en * apt-setup/mirror: ftp.freenet.de base-config/start-display-manager: true base-config/menu/apt-setup: base-config/menu/keyboard: tzconfig/title: debian-installer/country: US apt-setup/directory: /pub/ftp.debian.org/debian/ * base-config/install-problem: * tzconfig/change_timezone: false * base-config/pkgsel: tasksel - quickly choose from predefined collections of software base-config/menu/hostname: apt-setup/cd/another: false apt-setup/non-free: false apt-setup/badedit: apt-setup/non-us: true mirror/suite: testing apt-setup/baddir: base-config/menu/pkgsel: base-config/menu/apt-get: base-config/menu/timezone: base-config/menu/intro: base-config/menu/passwd: apt-setup/hostname: ftp.freenet.de base-config/menu/pon: * base-config/login: * tzconfig/gmt: true apt-setup/title: mirror/http/proxy: apt-setup/contrib: true apt-setup/non-us-failed: base-config/main-menu: Set up users and passwords * tzconfig/geographic_area: Asia apt-setup/cd/dev: /dev/cdrom * apt-setup/country: Germany debian-installer/keymap: us apt-setup/badsource: base-config/use-ppp: false apt-setup/uri_type: ftp tzconfig/choose_country_zone/US: Eastern * base-config/get-hostname: ilmarinen apt-setup/not-mirror: tzconfig/choose_country_zone_multiple: tzconfig/choose_country_zone/CA: Eastern apt-setup/security-updates-failed: base-config/menu/shell: apt-setup/cd/bad: * base-config/invalid-hostname: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#254068: base-config log should not be world readable
> > I believe that the base-config logs should not be world readable. > > Some of the packages ask for passwords that are echoed back during > > the configuration (e.g. pppoeconf), albeit stored later in files > > not readable by the world. > > > THen this bug pertains to what you call pppoeconf (isn't this > pppconfig?) rather than base-config.imho. I thought someone might think so, but (imho as well) i still believe it's more of a non-package-related issue. As there is no policy saying things like "setup logs are world readable, so you MUST NOT echo passwords" for all the packages, the packages need not "know" about the base-config issues "wrapping" them. With the priority of debconf questions set at low, there are hundreds of questions asked. Are we going to review each and every of them to see if there's a security risk in logging the setup process? I think that, especially in the view of the absense of a policy in the likes of the above it is much more feasible to just make the logs unreadable by non-root (and actually I can't justify a setup in which it would be needed for a non-root to read them. They're only there for troubleshooting root's work, aren't they?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265183: alsa-base: APM suspend/resume breaks sound, AU8810 rev03 chip
Package: alsa-base Version: 1.0.5a-3 Severity: normal (Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265183 for the full machine specs) Transcript: $ aplay /usr/share/sounds/pop.wav Playing WAVE '/usr/share/sounds/pop.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono [the sound is heard] [Fn+Suspend is pressed, the laptop goes to sleep] [Fn is pressed, the laptop wakes up] [Same command is attempted, same output, but no sound is heard during the pause. alsamixer shows enabled volume levels for the relevant channels, so it looks like it's not a mixer restore problem. ^C is pressed to abord aplay] [The command is tried again, and it bails out as follows, w/o any sound] $ aplay /usr/share/sounds/pop.wav Playing WAVE '/usr/share/sounds/pop.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono ALSA lib pcm_hw.c:578:(snd_pcm_hw_drain) SNDRV_PCM_IOCTL_DRAIN failed: Input/output error lsmod output: Module Size Used byNot tainted ds 7048 2 af_packet 13608 1 (autoclean) apm10088 2 (autoclean) snd-au8810 40036 0 snd-pcm-oss39464 0 (unused) snd-mixer-oss 13848 0 [snd-pcm-oss] snd-pcm61124 0 [snd-au8810 snd-pcm-oss] snd-timer 14532 0 [snd-pcm] snd-page-alloc 6392 0 [snd-pcm] gameport1676 0 [snd-au8810] snd-mpu401-uart 3504 0 [snd-au8810] snd-rawmidi13504 0 [snd-mpu401-uart] snd-seq-device 4160 0 [snd-rawmidi] snd-ac97-codec 55580 0 [snd-au8810] snd33508 0 [snd-au8810 snd-pcm-oss snd-mixer-oss snd-pcm snd-timer snd-mpu401-uart snd-rawmidi snd-seq-device snd-ac97-codec] soundcore 3908 6 [snd] usb-uhci 23500 0 (unused) usbcore64064 1 [usb-uhci] ide-scsi 10512 0 scsi_mod 95736 1 [ide-scsi] 8139too15496 1 mii 2560 0 [8139too] crc32 2912 0 [8139too] yenta_socket 10912 2 pcmcia_core47648 0 [ds yenta_socket] agpgart46756 0 (unused) nls_cp437 4348 4 (autoclean) vfat 10956 2 (autoclean) fat33368 0 (autoclean) [vfat] ide-cd 32576 0 cdrom 29632 0 [ide-cd] rtc 7228 0 (autoclean) ext3 83468 3 (autoclean) jbd42880 3 (autoclean) [ext3] ide-detect 288 0 (autoclean) (unused) piix9120 1 (autoclean) ide-disk 17184 6 (autoclean) ide-core 112140 6 (autoclean) [ide-scsi ide-cd ide-detect piix ide-disk] unix 15688 32 (autoclean) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26-1-686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R Versions of packages alsa-base depends on: ii alsa-utils1.0.5-3Advanced Linux Sound Architecture ii debconf 1.4.30.5 Debian configuration management sy ii debianutils 2.8.4 Miscellaneous utilities specific t ii module-init-tools 3.1-pre5-7 tools for managing Linux kernel mo ii modutils 2.4.26-1 Linux module utilities ii psmisc21.5-1 Utilities that use the proc filesy -- debconf information: alsa-base/alsactl_store_on_shutdown: autosave always -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
> As said to the previous bug reporters, it is simply not my job to load > _kernel_ modules for some other package. It would just additional > complexity while there are other places where it must be fixed. I agree > that this bug looks very shameful for a fresh Debian release so it > should be release critical. Especially when there is such a simple fix. I agree with you about the bug#263224 importance. I believe though that pppoeconfig might need to at least give a hint about the need to have the module preloaded - right now the behaviour during pppoeconfig is inconsistent with the behaviour after the fresh boot when just pppoe is being run. I agree that it is out of the scope of pppoe or pppd. But, ideally, pppoeconfing aiming to be a 1-2-3 setup wizard type of program, I think it should do everything including modconf-ing the module in forever if necessary, or at least offering this interactively as an option. > PS: I won't clone 265183, there are already enough bug reports to the > pppoe module problem. But what about the routing loop problem I had mentioned in the original 265183 report? It is something pretty confusing for a new user. Kind regards, Vassilii P.S. Sorry for a long silence - I was on vacation abroad, away from my home which is where all my ADSL hardware lives. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
On Tuesday 21 September 2004 00:12, Marco d'Itri wrote: > On Sep 20, Eduard Bloch <[EMAIL PROTECTED]> wrote: > > Which loop? I do not know why your modem has an own IP, maybe it is a > > router and not a modem? Why does it give your local systems DHCP > > adresses? How are they related to whatever is connected there? Or maybe > > it is not a usual PPPoE modem but this other weird > > ip-route-over-fake-internal-network-with-dhcp-over-DSL system (*). > > He is using an alcatel speedtouch ethernet modem which encapsulates > PPP in PPTP, to allow using PPPoA. The modem has 10.0.0.138 and the host > should have another address in that range. > This page describes a similar but different (there is no ppp0, but eth0) > configuration: http://pptpclient.sourceforge.net/diagrams.phtml . > If the modem DHCP server is really providing a gateway then I > consider this a modem bug. Marco has pretty much summed it up. I fail to see though why the modem asking the host to consider the modem the default gateway is a bug. The routing table that is set up on the host once the modem has responded via DHCP correctly reflects the situation - the only way to the outside from the host at that time is via the modem. One can use the modem as a router (w/o starting pppoe at all) and reach the provider's WAN, although the traffic won't be routable outside. > > PS: (*) I am still looking for somebody to explain me how this > > "technology" works and can provide a reliable step-for-step howto to add > > support for it to pppoeconf. Or even patches. From time to time people > > asked me to add support for their "DHCP DSL" but for real support more > > > is needed. > > It's not hard. Look at this example configuration: > http://www.bytewise.at/knowhow/adsl-pptp/Konfiguration.html The only piece of info that you asked for that Marco hasn't addressed was the duplex LAN link - I was telling that the host is directly wired into the modem, i.e. there is no hub sitting between them, so the LAN connection MODEM <-> HOST is a full-duplex ethernet connection (as opposed to half-duplex). I think that to add to pppoeconf the support, the following needs to be done: 1) from the routing table, one must deduce that there is no direct route to the modem, hence the default route will be used 2) that default route has to be cloned into a direct route to the modem (better yet, make that a network route to the net specified by the network portion of the modem address) 3) after that, ppp has to be invoked with the replacedefaultroute option, and it will work I'll be happy to elaborate further if needed. V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
> > Marco has pretty much summed it up. I fail to see though why the modem asking > > the host to consider the modem the default gateway is a bug. The routing > Because the modem is not a gateway and will not work as such? [snip] > If the speedtouch DHCP server really provides a default route when it's > configured for PPTP tunnels (something which I doubt and I think should > be verified) It is a gateway and does work as such. Did I not write in my last e-mail that *without* starting pppoe one can reach the provider's WAN via the default route going via the speedtouch? As for the verification, doesn't the routing table I reported in the 1st mail in the thread suffice? I'll be happy to do any additional verifications if you want. > *maybe* pppoeconf could check if the local address is > 10.0.0.1 and 10.0.0.138 is the modem: > > if ping ... 10.0.0.138 && \ > wget --quiet --output-document=- http://10.0.0.138/welcome.htm \ > | grep -q '^ADSL Index'; then >echo yes > fi > > Then it would have to check if the PPTP server is enabled. Unfortunately, .138 is the firmware default of my modem, but a lot of folks reconfigure the address; I can also imagine other models using addresses other than .138. As pppoeconf already discovers the modem by its own means, so I don't think the hardwiring saves a lot of coding. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
> > It is a gateway and does work as such. Did I not write in my last e-mail > > that *without* starting pppoe one can reach the provider's WAN via the > > default route going via the speedtouch? > Then the modem is configured as a router and you don't need need PPTP > at all... Marco, you seem to have forgotten another portion of the info I had mentioned earlier in the thread (to another portion of the same mail I had referred in the text you've just quoted!). While my traffic is routed to the WAN, being a 10. address it is NOT routable outside of it. Therefore, to get to the global Internet space, I need to establish PPTP. (A bit OT: I can still be using the provider's WAN e.g. to use their DNS forwarders rather than going to the DNS via the PPTP tunnel, but that would require me to add routes also to the DNS servers on the provider's LAN. This complication is not worth the negligible benefit of using the DNS. Overall, for a clean solution I should have the modem negotiate with my computer using a routing protocol and tell it about the provider WAN IPs reachable via the ethernet link to the modem, but this option is not provided, at least not in the default SpeedTouch config. Anyhow, this is not relevant to the pppoeconfig discussion.) > > Unfortunately, .138 is the firmware default of my modem, but a lot of > > folks reconfigure the address; I can also imagine other models using > Their problem. Agreed, at least until a lot of folks complain :) > > addresses other than .138. As pppoeconf already discovers the modem > > by its own means, so I don't think the hardwiring saves a lot of coding. > It does not discover the IP address. It knows its Ethernet address, it's the same LAN, and I bet it can send a RARP request to obtain one. Anyhow, as I am not giving a script patch and you do, I think that a hack that does what is needed in the most common case is definitely better than nothing. V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265183: pppoe workaround of the post-reboot problem
> Then you are not using PPTP to your modem but to your ISP, your modem is > behaving correctly and you don't need pppoeconf at all, because there is > no way we can know the details of PPTP tunneling used by every provider. pppoe does run locally over the eth0, and the modem is correctly discovered as the concentrator on the local Ethernet network by the pppoeconf. Look at the 2 1st messages on the 265183 bug thread where the (working) interfaces and dsl-provider details are dumped. Please note that as long as the interfaces file was hacked to statically assign the local (host to modem) LAN address statically, pppoeconf did everything correctly afterwards. V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
