pppoe-server: -n to use vendor specific tag as remote*N*umber.

[jkroonza]

RFC 2516 discourages it's use but it looks like at least some switches adds a port-configured circuit-id throught this. This does not seem to be well defined but at least CISCO and the S3900 series switches from fs.com has stuff about this in the documentation, which leads me to believe it's common practise.

[jkroonza]

https://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/iproute/17-1-1/b-iri-xe-17-1-asr920/b-iri-xe-17-1-asr920_chapter_011.pdf

https://img-en.fs.com/file/user_manual/s3900-series-switches-web-management-user-manual.pdf

Refers. Both documents are indicating that this tag is used to "carry subscriber and line identification information". As such on larger deployments it's potentially useful to use this as remotenumber to pppd rather than the MAC address (which can still be obtained via the MACREMOTE environment variable in pppd scripts when using the pppoe plugin).

This is a first draft at what this code could look like.

[dfskoll]

OK, but the PPPoE spec says this:

      0x0105 Vendor-Specific

      This TAG is used to pass vendor proprietary information.  The
      first four octets of the TAG_VALUE contain the vendor id and the
      remainder is unspecified.  The high-order octet of the vendor id
      is 0 and the low-order 3 octets are the SMI Network Management
      Private Enterprise Code of the Vendor in network byte order, as
      defined in the Assigned Numbers RFC

So should we not be checking for Cisco's vendor ID in there somewhere? Their Private Enterprise Number is 9, so the first four octets of the vendor-specific tag should be 0x00 0x00 0x00 0x09 if Cisco is playing by the rules, with the rest of the payload containing ... what, exactly? Does Cisco support multiple different types of vendor-specific tags? We need to find out exactly what is transmitted over the wire and how to interpret it, and 10 minutes of casual Googling hasn't led me anywhere useful.

[dfskoll]

Why do we null-terminate? Is there any standard saying a circuit ID can't be a bunch of arbitrary bytes?

[jkroonza]

precisely because we have no idea what's in there and we need it to be a string. Regardless, this is DEFINITELY not ready for merge, and looking for input and insight exactly like this.

[dfskoll]

It seems to me this could be the wire format of the tag:

http://ruwanindikaprasanna.blogspot.com/2007/05/pppoe-circuit-id-tagging-feature-in.html

We therefore need to do more work than simply copying the tag contents as the circuit ID. And we probably need a packet capture from a Cisco router with the option enabled to see exactly how they're formatting the tag.

[jkroonza]

It seems to me this could be the wire format of the tag:

http://ruwanindikaprasanna.blogspot.com/2007/05/pppoe-circuit-id-tagging-feature-in.html

We therefore need to do more work than simply copying the tag contents as the circuit ID. And we probably need a packet capture from a Cisco router with the option enabled to see exactly how they're formatting the tag.

Thanks, good find. I did not bump into that last night. I'm thinking I need to get a few raw PADI and PADR packets sniffed that contains these tags, and lets see what we find in them.

[jkroonza]

https://github.com/opencord/pppoeagent - seems to implement pppoe IA (which is exactly what this is intended for). Something might be learned from there too. I'm finding the code exceptionally hard to untangle though. But you're 100% right, there is more work to be done than what I've done here.

Might be best to get hold of the TR-101 spec, it's a shame the link on the page you referenced is broken.

Found this: https://www.ieee802.org/1/files/public/docs2006/liaison-dslf-tr-101-1006.pdf

Looks like pages 52 through

Edit: Updated latest spec: https://www.broadband-forum.org/pdfs/tr-101-2-0-0.pdf (latest version of the spec) page 56, not seeing modifications.

https://en.wikipedia.org/wiki/Point-to-Point_Protocol_over_Ethernet#cite_note-27

Which references TR200, https://www.broadband-forum.org/pdfs/tr-200-1-0-1.pdf

The OLT and the multiple-subscriber ONU MUST be able to perform the PPPoE Intermediate Agent function, as specified in Section 3.9.2/TR-101.

Based on above, it looks like we should filter for:

payload[0..4] == 0x00000DE9

And then we end up with a few more TLV values, specifically the tags:

0x1 => Agent Circuit ID value
0x2 => Agent Remote ID value

(Looks like the format is identical to Option 82 from DHCP, so we could compare RFC 3046).

https://datatracker.ietf.org/doc/html/rfc3046#section-3.2

Edit: So what I personally want is the remote id, is there a way to provide the agent circuit id (looks like typically a port number identification string eg "Relay-identifier atm 3/0:100.33" if I look at TR-101 v2 spec. If there is a way to pass this to pppd as the "port spec" to pass to radius that would be great, but I don't see that we can rely on radius being used, and I'm unsure what pppd will do if we pass this as "ttyname". Not that important to me, so not going to dig into this further. I do recall when Openserve was terminating PPP and communicating with use over radius rather than via PPPoEoL2TP they put this into some or another Radius option, but we discarded it back then anyway using only the Calling-Station-Id value anyway (Agent Remote ID).

It looks like it's only vendor-specific vendor = 0x000DE9 that the spec indicates must be replaced, so by implication -n option is also indicating the we can trust that this happens, and we need to filter for this specific vendor id. I'll adjust accordingly, I'd still like to get hold of a sniff for some of these frames first to be able to validate my code against.

[jkroonza]

Update PR is equally untested, but an eyeball review would be appreciated. I've figured out how to action a relevant test against my S3900 switches in the DC, but given the potential impact if something goes wrong at this time of year I'll hold off on the test until I can arrange a "potential downtime" window. Looks like I might need to reboot the switches to activate the IA mechanism but I'll read more in-depth at a later stage. Doesn't look like any of our FNO uses IA, but we'll give it a huge push in the new year.

I've updated the code to allow the user to set which of the two sub-tags she would prefer to have copied into remoteNumber. I'm further making the assumption that both of these will be human readable strings (I've seen implied statements to this effect but can't prove it).

[dfskoll]

OK, at first glance this looks fine. I'd like it to be tested before I merge, though.

Thanks!

[jkroonza]

OK, at first glance this looks fine. I'd like it to be tested before I merge, though.

Absolutely! Can't merge untested code. Thus why it's still Draft.