Then used the RASPPPOE third party protocol driver on XP Pro to build an add-hoc Access Concentrator. -- and.. it works.. now I can test various ADSL modems.
The [ Incoming ] connections on XP are usually a single instance of a "listening" daemon per Ethernet interface. Connections "spawn" a new instance of an Incoming connection listed below the daemon with a status of (connected).
When a PPPoE client on the LAN sends out Ethernet PADI-nitiate packets to discover any access concentrator servers over Ethernet broadcast, the "listeners" send a uni-cast reply as a PADO-ffer packet with the servers Ethernet MAC address.. so that the PPPoE client can then uni-cast directly to an (A)ccess (C)oncentrator server and begin to setup a PPP session.
The PPP session then (Authenticates using CHAP) and bargains for privileges and concessions until the two reach an agreement on authentication, tunnel service parameters and TCP/IP addresses for each end of the tunnel.
Then the session spawns a Virtual TCP/IP Interface on both the client and server 'end-points' and assigns those the negotiated IP addresses.
Ethernet is not TCP/IP -- this is "waaay" below that on the OSI scale.. its the original bare bones and knuckles wire protocol of one of the oldest and first networks. ADSL basically "borrows" raw Ethernet.. so it can take stabs in the dark and make end to end connections on top of an ATM "circuit". An ATM circuit is really more or less like a USB or Serial connection, its bidirectional and carries signals back and forth.. with some ability to prioritize signals if you use VPI and VCI and PVCs.. which most people do not.
The whole setup and connection from ATM to Ethernet to PPP to TCP/IP was relatively easy. The hard part was recognizing that the ADSL ports on the DSLAM were "tagged" or enabled to be members of a default Ethernet VLAN, which was switched off.
The net effect was I could see "PADI(client).. PADO(server).. PADI(client).. PADO(server)" while using wireshark to monitor the XP ethernet port that was acting as the access concentrator server.
But the client never seemed to "see" the servers "PADOffer reply".. once the VLAN was "enabled" replies traveling from the ZyXEL Ethernet management port started getting back to the ADSL ports.. and the connection pretty much immediately locked on like a snapper turtle and wouldn't let go.
After that the Cisco or the ZyXEL seemed to be sending "keep-alive" echo and reply requests to monitor each side of the ATM connection.
[Concept-wise] it also took a moment to "think" about how ADSL works.
The ADSL modem and ADSL DSLAM (DSL A-ccess M-ultiplier) are essentially "standalone" ATM switches. Each has an Ethernet port (ingress/egress) point, both on the customer DSL modem side and on the DSLAM modem side. As far as the customer and provider are concerned the ADSL "cloud" they plug into is "magic".
The ADSL part just fires up and starts blasting "tones" over a dedicated circuit looking for a partner.
A customers phone line that is "provisioned" for DSL is always ready to respond to those tones which are mostly beyond the range of human hearing. And normal old-fashioned phones are fitted with a low-pass filter to make sure you can't hear them.. and make sure the low frequency human voices can't interfere with the higher frequency DSL tones.
Its all slightly similar to USB signaling except USB signals are much higher frequency and more complex. DSL technology was developed in the 1990's primarily for carrying digital television signals.. but that didn't work out so well.. so it got repurposed for carrying digital data. Initially the chips that encapsulated ATM communications were expensive.. but over nearly 30 years they have come down in cost quite a bit due to volume discounting.
Really old-fashioned acoustic modems worked in the much lower frequency voice range and could work sending audible (to humans) "tones" over the switched voice lines of ancient central offices.
They could also leverage the switch voice line "phone number" database for addressing both humans, fax machines and destinations listening for data connections (like bulletin boards or Internet service providers).
The thinking back then was there was no need for high data rates and the infrastructure was too costly to replace.. that changed over the years.. but also the aging and failing voice lines were poor conductors of reliable communications. The longer the wire the worse the ability to carry high speed or reliable signals.
In any event -- The connection from ADSL modem to ADSL switch (or DSLAM) had to be setup first. Its a "bridge" because it [bridges] two types of travel (or communications) in this case it [bridges] Ethernet networks so that they appear as (one) broadcast zone.
That is an Ethernet station on one end with a MAC address can [shout] (or broadcast) a message to all other stations on the entire broadcast zone.. including the ADSL switch (or DSLAM) side.
A PPPoE server called an [Access Concentrator] can then listen for and respond to a request for service and "Offer" its services to the ADSL connected Ethernet "client". -- they then begin a PPP setup conversation and turn that into a PPP "established session" over Ethernet.
PPP "bridges" TCP/IP connections.. and the PPP client on the ADSL modem "Creates" a TCP/IP virtual interface and assigns it the TCP/IP address the two PPPoE speakers agreed upon.
At this point the ADSL modem has become an end-point on the Internet and it can go on to perform NAT or Firewall protection and even act as a DHCP server to hand out additional or NAT'ted TCP/IP addresses to clients on its local private network.
Of course the ADSL modem could have simply acted as a [bridge] for Ethernet traffic and permitted or enabled a different computer connected to its Ethernet port (broadcast zone) to perform PPPoE all by itself and establish a similar set of features for the local customer side LAN.. but that's a minor design choice.
A simple Ping from the XP concentrator confirmed both ends of the connection were responding.
