PPPOE-RELAY(8)

๐Ÿ“ฆ
version 4.0 ยท 3 versions
, in alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking

๐Ÿ’– PPPOE-RELAY ๐Ÿ’–

okay bestie, welcome to the pppoe-relay(8) glow-up ๐Ÿซถ this one lives in the System Manager's Manual and it's the user-space PPPoE relay agent for Linux. she's giving infrastructure royalty, no cap. ๐Ÿ‘‘


โœจ NAME โœจ

pppoe-relay โ€” user-space PPPoE relay agent. that's her. that's the whole vibe. ๐ŸŽ€


๐ŸŒธ SYNOPSIS ๐ŸŒธ

pppoe-relay [options]

literally just run her with options, bestie. that's it. ๐Ÿ’…


๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

so pppoe-relay is a user-space relay agent for PPPoE (that's Point-to-Point Protocol over Ethernet, iykyk) for Linux. ๐Ÿง

she does not work alone โ€” she works in concert with the pppoe client and the pppoe-server server. it's a whole trio situation, main character energy across the board. โœจ

and if you wanna know the actual mechanics of how she does her thing? scroll down to the OPERATION section, babe, it's all there. ๐Ÿ‘‡


๐Ÿ’… OPTIONS ๐Ÿ’…

  • -S interface โ€” adds the Ethernet interface interface to the list of interfaces managed by pppoe-relay. only PPPoE servers may be connected to this interface. servers only, bestie, don't get messy. ๐Ÿ–ฅ๏ธ
  • -C interface โ€” adds the Ethernet interface interface to the list of interfaces managed by pppoe-relay. only PPPoE clients may be connected to this interface. clients only, we keep it exclusive. ๐Ÿ’ป
  • -B interface โ€” adds the Ethernet interface interface to the list of interfaces managed by pppoe-relay. both PPPoE clients and servers may be connected to this interface. it's giving "everyone's welcome," periodt. ๐ŸŽ‰
  • -n num โ€” allows at most num concurrent PPPoE sessions. if you don't specify it, the default is 5000. and num can range from 1 to 65534. don't try to be extra with it. ๐Ÿ™ˆ
  • -i timeout โ€” specifies the session idle timeout. if both peers in a session are idle for more than timeout seconds, the session gets terminated. and if timeout is specified as zero, sessions will never be terminated because of idleness. she'll wait forever, that's loyalty fr fr. ๐Ÿ˜ญ
heads up though โ€” the idle-session expiry routine is never run more frequently than every 30 seconds, so the timeout is approximate. not exact, just vibes. the default value for timeout is 600 seconds (that's 10 minutes for the non-math girlies ๐Ÿงฎ).
  • -F โ€” the -F option causes pppoe-relay not to fork into the background; instead, she remains in the foreground. she stays right here with you. ๐Ÿซถ
  • -h โ€” the -h option prints a brief usage message and exits. quick lil hello then she's gone. ๐Ÿ‘‹

๐Ÿ”ฅ OPERATION ๐Ÿ”ฅ

okay so here's where it gets juicy. ๐Ÿ“

pppoe-relay listens for incoming PPPoE PADI frames on all interfaces specified with -B or -C options. when a PADI frame shows up, pppoe-relay adds a Relay-Session-ID tag and broadcasts the PADI on all interfaces specified with -B or -S options โ€” except the interface on which the frame arrived, obviously, we're not sending it back to where it came from. ๐Ÿ™…โ™€๏ธ

any PADO frames received get relayed back to the client which sent the PADI (assuming they contain valid Relay-Session-ID tags โ€” gotta have the tag, no tag no relay ๐Ÿ’€). likewise, PADR frames from clients are relayed back to the matching access concentrator. matchmaker, matchmaker. ๐Ÿ’˜

when a PADS frame is received, pppoe-relay enters the two peers' MAC addresses and session-ID's into a hash table. and here's the spicy part: the session-ID seen by the access concentrator may be different from that seen by the client, because pppoe-relay must renumber sessions to avoid the possibility of duplicate session-ID's. she's out here doing admin work nobody asked about. ๐Ÿ‘‘

whenever either peer sends a session frame, pppoe-relay looks up the session entry in the hash table and relays the frame to the correct peer. like a group chat moderator but efficient. ๐Ÿ“ฌ

when a PADT frame is received, pppoe-relay relays it to the peer and deletes the session entry from her hash table. bye boo ๐Ÿ‘‹

now. the messy part. ๐Ÿ˜ญ if a client and server crash (or frames are lost), PADT frames may never be sent, and pppoe-relay's hash table can fill up with stale sessions. therefore, a session-cleaning routine runs periodically, and removes old sessions from the hash table. a session is considered "old" if no traffic has been seen within timeout seconds. and when a session is deleted because of a timeout, a PADT frame is sent to each peer to make certain that they are aware the session has been killed. dramatic? maybe. necessary? absolutely. ๐Ÿ’…


๐ŸŒˆ EXAMPLE INVOCATIONS ๐ŸŒˆ

pppoe-relay -C eth0 -S eth1

the example above relays frames between PPPoE clients on the eth0 network and PPPoE servers on the eth1 network. clean, simple, iconic. โœจ

pppoe-relay -B eth0 -B eth1

this example is a transparent relay โ€” frames are relayed between any mix of clients and servers on the eth0 and eth1 networks. no rules, just vibes. ๐Ÿฆ‹

pppoe-relay -S eth0 -C eth1 -C eth2 -C eth3

this example relays frames between servers on the eth0 network and clients on the eth1, eth2 and eth3 networks. one server, three client networks, she's handling all of it. multi-tasking queen. ๐Ÿ‘‘


๐Ÿ‘‘ AUTHORS ๐Ÿ‘‘

pppoe-relay was written by Dianne Skoll <dianne@skoll.ca>. legend behavior, honestly. ๐Ÿ’–

the pppoe home page is https://dianne.skoll.ca/projects/rp-pppoe/ โ€” go visit, she deserves the clicks. ๐ŸŒ


๐ŸŽ€ SEE ALSO ๐ŸŽ€

pppd(8), pppoe(8), pppoe-sniff(8), pppoe-server(8)


and that's the whole page bestie!! ๐Ÿซถ this one came from the 4th Berkeley Distribution, dated 26 January 2001 โ€” yes she's vintage, yes she still eats. ๐Ÿ’…โœจ mwah, go relay some frames. ๐ŸŒธ