Re: 2.6.8-rc2-mm1 breaks PPPoE for me (was: 2.6.8-rc2-mm1)

Matthias Andree [off-list ref] wrote:

On Wed, 28 Jul 2004, Andrew Morton wrote:

quoted

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc2/2.6.8-rc2-mm1/

...

quoted

gcc35-pppoe.c.patch
  gcc-3.5 fixes

Andrew,

I'm not sure if my problem is related to this patch, but in
2.6.8-rc2-mm1, PPPoE doesn't work for me, kernel compiled with gcc (GCC)
3.3.1 (SuSE Linux), a vanilla 2.6.7 is fine with the same compiler.

pppd[5685]: Plugin /usr/lib/pppd/2.4.1/pppoe.so loaded.
pppd[5685]: PPPoE Plugin Initialized
pppd[5685]: pppd 2.4.1 started by root, uid 0
pppd[5685]: Sending PADI
pppd[5685]: HOST_UNIQ successful match 
pppd[5685]: Failed to negotiate PPPoE connection: 25 Inappropriate ioctl for device
pppd[5685]: Exit.

A successful pppd session start, with 2.6.7, looks like this:

pppd[5070]: PPPoE Plugin Initialized
pppd[5070]: pppd 2.4.1 started by root, uid 0
pppd[5070]: Sending PADI
pppd[5070]: HOST_UNIQ successful match 
pppd[5070]: HOST_UNIQ successful match 
pppd[5070]: Got connection: 164b
pppd[5070]: Connecting PPPoE socket: 00:90:1a:XX:XX:XX 4b16 eth1 0x808a560
/sbin/hotplug[5166]: INTERFACE=ppp0
pppd[5070]: Using interface ppp0
pppd[5070]: Connect: ppp0 <--> eth1
pppd[5070]: Setting MTU to 1492.
pppd[5070]: Couldn't increase MRU to 1500
pppd[5070]: Setting MTU to 1492.
pppd[5070]: local  IP address 217.81.XXX.XXX
pppd[5070]: remote IP address 217.5.XXX.XXX
pppd[5070]: Script /etc/ppp/ip-up finished (pid 5180), status = 0x0

I'm a bit stumped by this - I'm not aware of any change which would have
caused the pppoe device to start returning -ENOTTY.

Is this still happening?  Are you sure the relevant modules are loaded? 
Could you capture an strace of pppd while it's happening?

On Mon, 02 Aug 2004, Andrew Morton wrote:

I'm a bit stumped by this - I'm not aware of any change which would have
caused the pppoe device to start returning -ENOTTY.

Is this still happening?  Are you sure the relevant modules are loaded? 
Could you capture an strace of pppd while it's happening?

It happens in 2.6.8-rc2-mm2, too.
The strace is inconclusive.

Setup description:
I am running pppd 2.4.1 (SuSE 8.2 RPM) with the PPPOE plugin tied to eth1:

PCI: Enabling device 0000:00:0b.0 (0004 -> 0005)
ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
0000:00:0b.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xd400. Vers LK1.1.19
eth1: Dropping NETIF_F_SG since no checksum feature.

I am starting pppd via DJB's daemontools
(http://cr.yp.to/daemontools.html), with this run file:

#! /bin/sh
exec strace -ff -F -o /tmp/dump-pppd /usr/sbin/pppd call pppoe

Starting pppd from a bash (in an xterm, only thing I've tried) works, I
get a connection.  Writing such a pppd command into inittab yields
ENOENT rather than ENOTTY and fails as well.

The strace looks unhelpful to me, the only occurrence of ENOTTY is:

readlink("/proc/self/fd/0", "/dev/null", 511) = 9
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffff700) = -1 ENOTTY (Inappropriate ioctl for device)

ltrace reveals this happens inside getlogin() - and pppd appears to fall
back to getpwuid.

I'd think this is unrelated for I have the same lines with a working
kernel as well.

Using rp-pppoe as pty (instead of the plugin) doesn't work either, the
PPP link is negotiated properly but my log is full of "martian address"
log entries as though it was receiving its own packets externally. How
strange. I wonder if this is an strace artifact...

No useful debugging information. I hope someone can reproduce this. :-(

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)