pppoe(4) PPPOE_SERVER test

[Matthew Mondor]

Hello,

I tried the following test here, but which unfortunately doesn't seem
to work. On both sides of the bridge0 (tap0 or tap1), client PADI can
be seen, but I can see no server response whatsoever, with a netbsd-5
system and kernel built using the PPPOE_SERVER option:

# Bridge the new test 192.168.2.0 network to the local 192.168.1.13 address
route add -net 192.168.2.0 -netmask 255.255.255.0 192.168.1.13

# Create two tap(4) devices
ifconfig tap0 create
ifconfig tap1 create
ifconfig tap0 up
ifconfig tap1 up

# Make sure that our two tap(4) devices have a different ethernet
# address, then bridge them:
ifconfig bridge0 create
brconfig bridge0 add tap0
brconfig bridge0 add tap1
ifconfig bridge0 up

# Setup the server-side pppoe0 interface
ifconfig pppoe0 create
ifconfig pppoe0 link0
pppoectl -e tap0 pppoe0
pppoectl pppoe0 hisauthproto=pap hisauthname='***@bar.baz' hisauthsecret='quux' myauthproto=none
ifconfig pppoe0 192.168.2.1 192.168.2.13

# Now setup client-side pppoe1 interface
ifconfig pppoe1 create
pppoectl -e tap1 pppoe1
pppoectl pppoe1 myauthproto=pap myauthname='***@bar.baz' myauthsecret='quux' hisauthproto=none
ifconfig pppoe1 0.0.0.0 0.0.0.1 netmask 0xffffffff

# Finally activate the server side, then the client side,
# after setting up tcpdump instances on both tap(4) sides.
ifconfig pppoe0 up
ifconfig pppoe1 up

Anyone know if I'm missing something, or if that's due to a known
issue? I'm trying the PPPOE_SERVER support for the first time, after
having read http://www.netbsd.org/docs/network/pppoe/#pppoe-server and
the pppoe(4) manual page.

Thanks,

[Matthew Mondor]

On Sat, 20 Nov 2010 11:15:41 -0500

Post by Matthew Mondor
Anyone know if I'm missing something, or if that's due to a known
issue? I'm trying the PPPOE_SERVER support for the first time, after
having read http://www.netbsd.org/docs/network/pppoe/#pppoe-server and
the pppoe(4) manual page.

When using nm(1) on the /netbsd kernel image, I noticed that some
symbols appear to be missing which would normally be defined when
PPPOE_SERVER, despite config -x /netbsd showing "options PPPOE_SERVER"
and the image having been built again after cleaning the compile
directory. This could explain my problems, although I unfortunately
don't yet understand why the PPPOE_SERVER conditional code doesn't get
built.

[Hubert Feyrer]

Post by Matthew Mondor
When using nm(1) on the /netbsd kernel image, I noticed that some
symbols appear to be missing which would normally be defined when
PPPOE_SERVER, despite config -x /netbsd showing "options PPPOE_SERVER"
and the image having been built again after cleaning the compile
directory. This could explain my problems, although I unfortunately
don't yet understand why the PPPOE_SERVER conditional code doesn't get
built.

I.e. a clean rebuild worked for you?
I never saw those problems when I wrote the documentation that you
referred to (after fiddling with it, too). What I didn't have was agr(4)
in the game, and I wonder if you can try without that if it still does act
up.

Good luck!


- Hubert (PPPOE_SERVER-clueless, mostly ;)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthew Mondor]

On Sat, 20 Nov 2010 23:12:33 +0100 (CET)

Post by Hubert Feyrer
I.e. a clean rebuild worked for you?
I never saw those problems when I wrote the documentation that you
referred to (after fiddling with it, too). What I didn't have was agr(4)
in the game, and I wonder if you can try without that if it still does act
up.

I initially believed that despite having the PPPOE_SERVER option my
kernel didn't have the server code built as nm(1) was missing symbols,
but this appears to be due to inlining. I verified that the
PPPOE_SERVER code was really being built, and also see some
server-specific strings in my image, so the support is definitely in.

So somehow the server mode doesn't seem to respond at all, yet it could
possibly be a tap(4) or bridge(4) related issue indeed, but I've not
yet found what the problem could be, checking their code. I previously
used successfully tap(4) and bridge(4) in another context, where the
tap interface was bridged to an actual ethernet one, then driven by
custom test network stack software (not involving pppoe(4) at all).
This was however my first try at a tap(4)<->tap(4) bridge.

I'll have to try using two actual ethernet interfaces when I can. Then
at least I'll narrow down a bit where the problem could be. I should
also try another tap(4)<-bridge(4)->tap(4) test with other things than
pppoe(4), like a listening daemon on one end and a client on the
other...

Thanks,