Thanks for the suggestion of plugging it into another machine to do a packet
dump.
There's a miss-match on the priority from what OpenBSD is reporting to what the
client sees on the other end. OpenBSD priority=0, client has priority=1.
OpenBSD:
21:01:37.959968 00:0d:b9:4f:74:98 Broadcast 8100 36: 802.1Q vid 2 pri 0
PPPoE-Discovery
code Initiation, version 1, type 1, id 0x0000, length 12
tag Service-Name, length 0
tag Host-Uniq, length 4 \215\205\320]
0000: ffff ffff ffff 000d b94f 7498 8100 2002 .........Ot... .
0010: 8863 1109 0000 000c 0101 0000 0103 0004 .c..............
0020: 8d85 d05d ...]
On the client (IMac)
21:01:40.169419 00:0d:b9:4f:74:98 (oui Unknown) > Broadcast, ethertype 802.1Q
(0x8100), length 60: vlan 2, p 1, ethertype PPPoE D, PPPoE PADI [Service-Name]
[Host-Uniq 0x8D85D05D]
0x0000: 1109 0000 000c 0101 0000 0103 0004 8d85 ................
0x0010: d05d 0000 0000 0000 0000 0000 0000 0000 .]..............
0x0020: 0000 0000 0000 0000 0000 ..........
This looks to be wrong? The client (directly connected imac) should not be
seeing a priority of 1? It's strange on the OpenBSD side it has a priority of
one on the packet dump unless it's modified further along? Also I'm not sure
where what looks to be padding comes from, if that is on the openbsd side or
the mac side?
This is my first time using OpenBSD but looking through the changelogs the
llprio set on the interface should be correctly setting the priority? The
tcpdump on the OpenBSD side looks to support that.
Re the modem, I have a ISP provided modem which is locked down like ISP's do so
I do not have access to set vlans on that manually. I have been using it in
bridge mode with DD-WRT for about 2 years and DD-WRT had the WAN port set to
vlan 2.
--
Adam Evans
On Sat, 9 Feb 2019, at 20:33, Stuart Henderson wrote:
> On 2019-02-09, Adam Evans <a...@agileand.me> wrote:
> > Hi, i'm trying to set up an OpenBSD router (6.4) on a PcEngines APU2D4 with
> > Intel i210AT nics however I am having difficulties with PPPoE. I can see
> > the discovery PADI packets going out using tcpdump but do not see any PADO
> > response so PPPoE times out and retries sending the PADI packets.
> >
> > More confusing is my Netgear R7000 running DD-WRT that I want to replace
> > with the APU handles PPPoE just fine and bizarrely the PADI packets look
> > the same however the packets from OpenBSD don't get a response but the
> > R7000 does.
> >
> > Using tcpdump the PADI message form OpenBSD looks like below:
> >
> > 15:21:47.340929 a0:63:91:47:81:07 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q vid
> > 2 pri 0 PPPoE-Discovery
> > code Initiation, version 1, type 1, id 0x0000, length 12
> > tag Service-Name, length 0
> > tag Host-Uniq, length 4 \210\352\235\232
> >
> > From the router running DD-WRT we can see the PADI packet followed by the
> > response PADO:
> >
> > 01:14:57.164338 a0:63:91:47:81:07 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
> > (0x8100), length 36: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI
> > [Service-Name] [Host-Uniq 0x55440000]
> >
> > 01:14:57.171736 78:da:6e:de:df:d4 > a0:63:91:47:81:07, ethertype 802.1Q
> > (0x8100), length 103: vlan 2, p 0, ethertype PPPoE D, PPPoE PADO
> > [Vendor-Specific "......AVC000030861999"] [Service-Name] [Host-Uniq
> > 0x55440000] [AC-Name "syd-gls-har-bras24"] [AC-Cookie "po.N?f'......D27"]
> >
> > To me, the PADI packets look the same, I even spoofed the MAC on the
> > OpenBSD box so it looks like the DD-WRT router although this shouldn't be
> > necessary I just wanted to verify.
>
> Can you get a more complete dump? (e.g. tcpdump -s1500 -X -e -i em0/eth0)
>
> Can you get a dump of the PADI from another machine plugged into em0 to check
> that it actually makes it onto the wire with the expected tag/prio??
>
> > em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1492
>
> I don't expect it to make a difference this early in the negotiation but
> em0 should be mtu 1500, you'll run into problems later with 1492.
>
> FWIW normally I do the vlan handling in the modem rather than on the router
> and pppoe setup is usually straightforward, though it should work either way.
>
>
