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.<\/p>\n
So, I googled for a while, started to understand the details of PPPoE (RFC 2516<\/a>), 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.<\/p>\n 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<\/strong>, 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.<\/p>\n 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 :<\/p>\n 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.<\/p>\n On Windows, KillPPPoE<\/a> does just this automatically.<\/p>\n On Linux, you have to do it partially by hand.<\/p>\n Open issue : How long would it have taken to solve the issue if I hadn’t dig it like that ?<\/strong><\/p>\n Update:<\/strong> Loic Pefferkorn wrote pppoesk<\/a> to automate the process. See related “journal” on LinuxFR.org<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"0","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-198","post","type-post","status-publish","format-standard","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/www.lucas-nussbaum.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/198","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.lucas-nussbaum.net\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.lucas-nussbaum.net\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.lucas-nussbaum.net\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.lucas-nussbaum.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=198"}],"version-history":[{"count":0,"href":"https:\/\/www.lucas-nussbaum.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/198\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.lucas-nussbaum.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=198"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.lucas-nussbaum.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=198"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.lucas-nussbaum.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=198"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n
No. Time Source Destination Protocol Info\r\n11 49.125813 221.208.208.89 83.177.207.102 UDP Source port: 36545 Destination port: 1027\r\n\r\nFrame 11 (507 bytes on wire, 96 bytes captured)\r\nArrival Time: Jul 12, 2006 18:00:18.950672000\r\nTime delta from previous packet: 6.698021000 seconds\r\nTime since reference or first frame: 49.125813000 seconds\r\nFrame Number: 11\r\nPacket Length: 507 bytes\r\nCapture Length: 96 bytes\r\nProtocols in frame: eth:pppoes:ppp:ip:udp:data\r\nColoring Rule Name: UDP\r\nColoring Rule String: udp\r\nEthernet II, Src: ThomsonT_62:c4:f1 (00:90:d0:62:c4:f1), Dst: DellComp_15:dc:61 (00:c0:4f:15:dc:61)\r\nDestination: DellComp_15:dc:61 (00:c0:4f:15:dc:61)\r\nAddress: DellComp_15:dc:61 (00:c0:4f:15:dc:61)\r\n.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame\r\n.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address\r\nSource: ThomsonT_62:c4:f1 (00:90:d0:62:c4:f1)\r\nAddress: ThomsonT_62:c4:f1 (00:90:d0:62:c4:f1)\r\n.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame\r\n.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address\r\nType: PPPoE Session (0x8864)\r\nPPP-over-Ethernet Session\r\n0001 .... = Version: 1\r\n.... 0001 = Type: 1\r\nCode: Session Data (0x00)\r\nSession ID: 0x0019\r\nPayload Length: 487\r\nPoint-to-Point Protocol\r\nInternet Protocol, Src: 221.208.208.89 (221.208.208.89), Dst: 83.177.207.102 (83.177.207.102)\r\nUser Datagram Protocol, Src Port: 36545 (36545), Dst Port: 1027 (1027)\r\nData (46 bytes)<\/pre>\n
\n