On 07/23/14 08:06, Thorsten Bonck wrote: > On Tue, Jul 22, 2014 at 05:28:46PM -0300, Felipe Mesquita de Oliveira wrote: >> >> # ifconfig pppoe0 >> pppoe0: flags=28855<UP,DEBUG,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,NOINET6> >> 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 0xffffffff >> >> >> 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 >
One could also tcpdump capture on the pppoe0 port with a laptop and quite possibly configuring a pppoe server on that laptop. The PPPOE RFC is 2516, and it states in section 5.1 "The Host sends the PADI packet with the DESTINATION_ADDR set to the broadcast address.", the broadcast address is FF:FF:FF:FF:FF:FF, if it deviates from that you'll likely not get a PADO (offer packet) as outlined in section 5.2. If it's fine but the PADO packet has the wrong destination MAC (than known on your host) then your PPPOE stack will likely not pick it up. And a timeout occurs. Good luck, -peter
