Bug 9356

Summary:	Violates RFC2516 by not asking for Service Name in PPPoE config.
Product:	Mageia	Reporter:	Pierre Fortin <pf>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED OLD	QA Contact:
Severity:	normal
Priority:	Normal	CC:	jani.valimaa, mageia, mageia, stormi-mageia, thierry.vignaud
Version:	2	Keywords:	Triaged
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	drakx-net	CVE:
Status comment:

Description Pierre Fortin 2013-03-13 02:15:22 CET

Description of problem:
Setting up a PPPoE connection requires a Service Name.

RFC2516 states:
5.1 The PPPoE Active Discovery Initiation (PADI) packet

The Host sends the PADI packet with the DESTINATION_ADDR set to the
broadcast address. The CODE field is set to 0x09 and the SESSION_ID
MUST be set to 0x0000.

The PADI packet MUST contain exactly one TAG of TAG_TYPE Service-
Name, indicating the service the Host is requesting, and any number
of other TAG types. An entire PADI packet (including the PPPoE
header) MUST NOT exceed 1484 octets so as to leave sufficient room
for a relay agent to add a Relay-Session-Id TAG.

Without the ability to configure a Service Name (SN), I don't know if the PPPoE code is also lacking the Service Name support. However, establishing a PPPoE connection involves:
1. issue a PADI packet with desired SN
2. get a PADO (offer) response with Service Name(s) available from Access Concentrator(s) (AC).
3. Pick an AC offering SN and request connection via PADR
4. Get confirmation via PADS from AC.

Version-Release number of selected component (if applicable):

How reproducible:
Always.

Steps to Reproduce:
1. Configure PPPoE network interface.
2.
3.

Note that while most AC vendors are compliant, AdTran may not be as they allow the SN to be optional (violates RFC2516's "MUST"). The lack of SN in our PADI packet is ignored by AdTran which responds with non-SN PADO; yet, a PPPoE connection is established in violation of RFC2516.

This was compared to DD-WRT software in our router -- it correctly ignores the invalid PADO packet from the AC. Working with my ISP to get this error resolved in their new AdTran deployment.

I'd be happy to report this upstream if someone can point me to the correct maintainer...

Reproducible:

Steps to Reproduce:

Comment 1 Manuel Hiebel 2013-03-13 22:21:51 CET

I'd be happy to report this upstream if someone can point me to the correct maintainer...

upstream of  ppoe ? so is this something for us or not ?

Comment 2 Pierre Fortin 2013-03-13 22:27:49 CET

Sorry for offering to help if necessary...  Yes, it's Mageia2.

Comment 3 Manuel Hiebel 2013-03-13 22:42:59 CET

ok so likely something upstream (sorry I missed the quote in my previous comment)

Keywords: (none) => UPSTREAM
CC: (none) => mageia
Component: Installer => RPM Packages
Source RPM: drakconf-12.30-1.mga2 => drakx-net

Comment 4 Samuel Verschelde 2013-08-29 15:36:45 CEST

So, is there a problem in Mageia's drakconnect or in another tool? The description is not clear about that to me.

CC: (none) => stormi

Samuel Verschelde 2013-08-29 15:36:54 CEST

Keywords: UPSTREAM => NEEDINFO

Comment 5 Pierre Fortin 2013-09-01 15:14:18 CEST

Did PPPoE support get removed from drakconnect?

Found pppoe-setup and it too has no provision for specifying a Service Name.

Comment 6 Samuel Verschelde 2013-09-02 10:10:00 CEST

I don't think PPPoE support got removed from drakconnect, only your report wasn't clear about it being about drakconnect in the first place (no step by step instructions to see the bug).

So, pppoe-setup has the same behaviour as drakconnect, not asking for a Service Name. Unfortunately we have no dedicated maintainer for pppoe stuff and I don't know who to ask for advice. 

I'm adding some packagers in CC in case they could help.

Keywords: NEEDINFO => Triaged
CC: (none) => jani.valimaa, mageia, thierry.vignaud
Source RPM: drakx-net => rp-pppoe

Samuel Verschelde 2013-09-02 10:10:12 CEST

Source RPM: rp-pppoe => drakx-net

Comment 7 Manuel Hiebel 2013-10-22 12:18:27 CEST

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Comment 8 Manuel Hiebel 2013-11-23 16:15:14 CET

Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD