ISP Upgrades v PPPoE

From DD-WRT Wiki

Jump to: navigation, search

[edit] ISP replaces Access Concentrators, causing router PPPoE to fail

We had been using PPPoE to access the 'net over DSL for a few years. This choice allowed us access to such features as remote access and printing by using the DD-WRT router to advertise its location via dynamic DNS.

The other day, our service went down and could not be restored. The ISP's technician replaced the DSL modem (the old one was deprecated anyway); but still, no PPPoE connection could be established. The tech pointed a finger at our DD-WRT router failing to request the connection. Convinced our router was fine, using my Linux laptop connected via ethernet to the router's WAN port, and making a Connect request over the wireless connection, I could see the router issuing a PPPoE PADI discovery packet (see RFC2516). So far so good...

Next, using a real "hub" (not a switch labeled as a hub as some vendors sell) inserted between the router and DSL modem, we could see the PADI discovery packet triggering a PADO offer packet from the ISP's Access Concentrator (AC). After a momentary sinking feeling, it became apparent that the ISP was violating section 5.2 of RFC2516 by failing to respond with a PADO packet containing the mandatory requested Service Name. RFC2516 section 5.2 reads:

  5.2 The PPPoE Active Discovery Offer (PADO) packet
  
  When the Access Concentrator receives a PADI that it can serve, it 
  replies by sending a PADO packet.  The DESTINATION_ADDR is the 
  unicast address of the Host that sent the PADI.  The CODE field is 
  set to 0x07 and the SESSION_ID MUST be set to 0x0000.
  
  The PADO packet MUST contain one AC-Name TAG containing the Access 
  Concentrator's name, a Service-Name TAG identical to the one in the 
  PADI, and any number of other Service-Name TAGs indicating other 
  services that the Access Concentrator offers.  If the Access 
  Concentrator can not serve the PADI it MUST NOT respond with a PADO.

Long story short, the ISP was in the process of replacing its aging Cisco Access Concentrators (AC) with units from Calix and AdTran. The AdTran ACs were either not configured correctly, or have a bug. Either way, the real problem was that the AdTran AC's PADO offer contained no Service Name. Being RFC-compliant, the DD-WRT code had no choice but to ignore the empty offer.

After lengthy discussions with the ISP (Windstream Communications), word came down from their engineering group refusing to address or correct the blatant violation of RFC2516. Their position is that it's possible to use their newer DSL modem to establish a PPPoE connection. However, this provides a non-routable 192.168.254.x IP address to the router. Amazingly, the DSL modem's configuration screen lists Service Name as "optional" -- yet another RFC violation...

Without a public, routable IP address, we could not restore and use the services we'd relied upon for a long time. The net result, well explained to the ISP was that we could no longer work remotely, causing lost time, higher expenses, etc because we now had to drive to the office to accomplish simple tasks we'd grown accustomed to doing from anywhere.

WORKAROUND

If you encounter this problem with your own ISP, a workaround is currently possible with V24preSP2 firmware; however, it requires exploiting an RFC2516 Section 5.1 violation which was missed in the DD-WRT code.

Personally, I hate RFC violations, especially exploiting one; but... an old saying states two wrongs don't make a right; but three lefts do... neither is correct or optimal; but when cornered...

Until the ISP corrects their implementation, in the router's Setup screen, using PPPoE, there is a field for Service Name. Simply remove the previously ISP-specified string. This solves the problem. Actually, it invokes a flaw in the DD-WRT code which thankfully violates Section 5.1 of RFC2516. Now, the router issues a PADI discovery packet with no Service Name . The AdTran AC responds with its no Service Name packet, and DD-WRT happily matches empty with empty and continues to establish the connection.

Sadly, if/when the ISP corrects this situation, our PPPoE connection will again fail requiring a correction of the router setup...

Thus spake the master programmer: "A well written program is its own heaven; a poorly-written program its own hell." -- The Tao of Programming