After being offline for 2.5 weeks at home, I finally took the decision to investigate the issue myself, because I don’t think that Tele2 can be trusted about this.
So, I googled for a while, started to understand the details of PPPoE (RFC 2516), and discovered that the error I was encountering (Windows reports it as error 676, which seems to be its official name ;) is actually quite common. The symptoms are that the Access Concentrator replies to your PADI (PPPoE Active Discovery Initiation) packet with a PADO (PPPoE Active Discovery Offer) packet, but doesn’t reply to your PADR (PPPoE Active Discovery Request) with a PADS (PPPoE Active Discovery Session-confirmation), so the session can’t be established.
A bad design of PPPoE, and probably a bad implementation of the Access Concentrator, is the source for major problem : PPPoE sessions can die without being noticed, for example if your DSL connexion is abruptly reset (bad line, etc). When you try to reconnect, the authentication server refuses to open a new session, because you already have a session open.
Now, how do you solve that ? Normally, Joe Random can just call its hotline, say he encounters the infamous 676 error, and the friendly guy on the other side of the phone will manually close the session, so Joe can connect again. But with Tele2, this doesn’t work. If you phone Tele2’s hotline and report a 676 error, you can get the following answers :
- We have some large scale problems, and are aware of the issue. We are working on it, it will be fixed in 1-2 days (two weeks later, still not fixed, of course).
- The problem is known, and impacts all you area. The tech guys are working on it.
- This is caused by an incompatibility between your modem (I didn’t buy it, Tele2 provides it) and the DSLAM. (I got this answer today, and got quite angry because they could really have told me this earlier, so I could have borrowed a friend’s modem).
There are solutions to close the session from the client side, using a PADT (The PPPoE Active Discovery Terminate) packet. But it’s tricky, because you have to determine the AC’s MAC address (easy) and the ghost session’s ID (harder). To determine your session’s ID, you can just sniff the ethernet interface which connects your computer to the modem, and wait until you receive a packet from your old session on it (e.g a random UDP probe from a computer you don’t know). They, you can look at the PPPoE headers, and retrieve the AC’s MAC and the Session ID, and forge a PADT packet with them.
On Windows, KillPPPoE does just this automatically.
On Linux, you have to do it partially by hand.
- Capture the packets using tcpdump (tcpdump -Unvvi eth0 -w file.cap pppoed or pppoes).
- Open the capture file using ethereal, and find a packet from your old session.
No. Time Source Destination Protocol Info
11 49.125813 221.208.208.89 83.177.207.102 UDP Source port: 36545 Destination port: 1027
Frame 11 (507 bytes on wire, 96 bytes captured)
Arrival Time: Jul 12, 2006 18:00:18.950672000
Time delta from previous packet: 6.698021000 seconds
Time since reference or first frame: 49.125813000 seconds
Frame Number: 11
Packet Length: 507 bytes
Capture Length: 96 bytes
Protocols in frame: eth:pppoes:ppp:ip:udp:data
Coloring Rule Name: UDP
Coloring Rule String: udp
Ethernet II, Src: ThomsonT_62:c4:f1 (00:90:d0:62:c4:f1), Dst: DellComp_15:dc:61 (00:c0:4f:15:dc:61)
Destination: DellComp_15:dc:61 (00:c0:4f:15:dc:61)
Address: DellComp_15:dc:61 (00:c0:4f:15:dc:61)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address
Source: ThomsonT_62:c4:f1 (00:90:d0:62:c4:f1)
Address: ThomsonT_62:c4:f1 (00:90:d0:62:c4:f1)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address
Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
0001 .... = Version: 1
.... 0001 = Type: 1
Code: Session Data (0x00)
Session ID: 0x0019
Payload Length: 487
Point-to-Point Protocol
Internet Protocol, Src: 221.208.208.89 (221.208.208.89), Dst: 83.177.207.102 (83.177.207.102)
User Datagram Protocol, Src Port: 36545 (36545), Dst Port: 1027 (1027)
Data (46 bytes)
- Call pppoe with the -k option to terminate the session (pppoe -k -e 25:00:90:d0:62:c4:f1). Note that the session ID must be passed in decimal, not hexadecimal.
- You can observe the PADT packet being sent, and the PADT reply from the AC.
Open issue : How long would it have taken to solve the issue if I hadn’t dig it like that ?
Update: Loic Pefferkorn wrote pppoesk to automate the process. See related “journal” on LinuxFR.org.
