Re: Problem with PPPoE
On Tue, Jul 22, 2014 at 05:28:46PM -0300, Felipe Mesquita de Oliveira wrote: > > # ifconfig pppoe0 > pppoe0: flags=28855 > mtu 1492 > priority: 0 > dev: bge0 state: PADI sent > sid: 0x0 PADI retries: 7 PADR retries: 0 > sppp: phase establish authproto pap authname "x...@xxx.com.br" > groups: pppoe > status: no carrier > inet 0.0.0.0 --> 0.0.0.1 netmask 0x > > > I've seen some messages discussing this, like this one: > http://comments.gmane.org/gmane.os.openbsd.misc/212649 The problem in the link was related to PPPoE over VLAN using a rl(4) card as physical interface. It seems to be caused by the card being unable to do VLAN tag insertion/stripping in hardware. After changing to a em(4) card, the problem was simply gone for me. Since your pppoe0 uses bge(4) and no VLAN, it has to be caused by something else. Like others suggested, capture the PPPoE negotiation using tcpdump and look for oddities like wrong MACs. Best Regards, Thorsten
Re: hp proliant dl 320e gen 8 for openbsd 5.5 64 bit ?
On Thu, Aug 07, 2014 at 02:08:02PM +0530, Indunil Jayasooriya wrote: > We got this server with 2 x 1 TB hard disks. Because we want a mirrored > Hard drive with 1 TB. But We got it WITHOUT getting it mirrored. > > We can tell the Hardware vendor to mirror this 2 hard disks. > > My question is after mirroring, Will OpenBSD work or again will have to > change BIOS settings ? Have a look at softraid(4), which explains how to set up and install OpenBSD on a RAID 1 like device. Best Regards, Thorsten
Re: Problems with PPPoE, VLAN, 5.5 (amd64)
On Fri, May 02, 2014 at 08:14:40PM +, 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 '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:
rl011: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
Re: Problems with PPPoE, VLAN, 5.5 (amd64)
On Wed, May 07, 2014 at 02:11:09AM +, Stuart Henderson wrote:
> On 2014-05-02, Thorsten Bonck wrote:
> > On Fri, May 02, 2014 at 08:14:40PM +, 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 '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:
> >
> > rl011: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
> >
> >
>
> I have pppoe-over-vlan working fine on 5.5 here. (More specifically:
> multiple pppoe interfaces with pppoedev on a vlan, vlandev on a
> trunk, failover trunk over a pair of bnx - trunk/bnx both show
> VLAN_HWTAGGING in "ifconfig hwfeatures").
>
> Considering what may be different between your setup and mine,
> I'm wondering if it could be either 1) your use of lladdr to adjust
> the MAC address or 2) use of rl(4) which doesn't do hw tagging..
>
Thanks to your hint to VLAN_HWTAGGING, I setup another installation on a
machine that provides a em(4) nic which has this feature.
Now everything, including the lladdr, just works.
Thanks to everyone who helped so far!
Best Regards,
Thorsten
