On Fri, May 02, 2014 at 08:14:40PM +0000, Peter J. Philipp wrote:
> On Fri, May 02, 2014 at 09:14:16PM +0200, thors...@bonck.net wrote:
> > > maybe you could try to put pppoe0 on rl0, untag vlan10 on switch port
> > > where rl0 is connected and tag other vlans on the same port ...
> >
> > Sadly, that is not possible for me.
> > rl0 is directly connected to a Ubiquiti NanoStation M, which is setup as
> > a blackbox transparent bridge by my ISP.
> > vlan id 10 is also required by my ISP for all PPP/PPPoE stuff.
> > I could put a tagging switch in between rl0 and the bridge as a last
> > resort, but for right now I am still looking for a reason why 5.4 works
> > and 5.5 seems to answer to a wrong MAC.
> >
> > Looking through the changes from 5.4 I found "Stop defining
> > SIOC{S,G}ETVLAN as SIOC{S,G}IFGENERIC. Lets vlan(4) handle
> > pppoe(4)-specific ioctls and vice versa without smashing the stack of
> > the caller". Is it possible my problem is somehow connected to that?
>
> Hello,
>
> I'd probably do a tcpdump -v -n -e -s 200 -X -i rl0 as well.. perhaps you
> can see somewhere where the aa:aa:aa:aa:aa:aa is coming from. Perhaps there
> is an offset logic error somewhere as the pppoe driver reads the PADO source
> address from the mbuf etherheader which was prepended. If you can't make
> out any AAAAAAAAAAAA's in the frame then that's further suspicous.
After some staring at the dumped frames, I can describe the problem more
detailed.
Assume listed devices to have following macs:
rl0 11:22:33:44:55:66
PPPoE server aa:bb:cc:dd:ee:ff
rl0 broadcasts PADI to ff:ff:ff:ff:ff:ff.
PPPoE servers mac sends a PADO to rl0 mac.
rl0 sends a PADR to mac aa:bb:55:66:aa:bb.
timeout happens, since no device with aa:bb:55:66:aa:bb exists in the
network.
Now change rl0 mac to 11:22:33:44:77:88:
PADI,PADO phase unchanged.
rl0 sends a PADR to mac aa:bb:77:88:aa:bb.
I only have a very basic understanding of C and basically no
understanding of the OpenBSD kernel.
The PADR should be assembled around line 703 in src/sys/net/if_pppoe.c
but I could not find any clues where this mix up happens.
Best Regards,
Thorsten
