Date: Thu, 26 Jan 2006 11:49:08 -0800 From: Julian Elischer <julian@elischer.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netgraph ng_pppoe.c Message-ID: <43D927B4.9040602@elischer.org> In-Reply-To: <200601261306.k0QD6o4P070834@repoman.freebsd.org> References: <200601261306.k0QD6o4P070834@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff wrote: try not to change the behaviour of the LMI and PPPoE modules too much. the modules as they were, were certified by MCI as being complient with their PPPoE requirements. Some of the required behaviours were odd to me becasue they were not specified by the spec. (e.g. this behaviour) An interesting story.. I went to Dallas where their test lab was, with a laptop and the test box (actually 2 of them) (A whistle Interjet) and all the sources. When, in the first morning, they gave me a list of tests for which they wanted changes, (i.e. it failed,) I made the changes over the lunch hour on my laptop, and comiled up a new kernel and asked them to retest in the afternoon. They were amazed as they had never seen turnarund in less that 3 months (mainly from big companies). Needless to say, it passed with Flying colours in the second try, but according to the paperwork it passed with flying colours on the first try (from their perspective). Something else they had never seen. :-) >glebius 2006-01-26 13:06:50 UTC > > FreeBSD src repository > > Modified files: > sys/netgraph ng_pppoe.c > Log: > From the RFC2516 it is not clear, what is the correct behavior for a > PPPoE AC, servicing a specific Service-Name, when client sends a PADI > with an empty Service-Name. Should it reply with all available service > names or should it be silent? Our implementation had chosen the latter, > while some other had chosen the former (they say Linux and Cisco). Now > some PPPoE clients appear, that rely on the assumption that AC will > send all names in a PADO reply to a PADI with wildcard Service-Name. > These clients can't connect to FreeBSD AC. > > I have requested comments from authors of RFC2516 via email, but > received no reply. > > This change makes FreeBSD AC compatible with D-Link DI-614+ and > D-Link DI-624+ SOHO routers, and probably others. > > Big thanks to D-Link's Russian office, namely Victor Platov, for > assistance and support in investigation and testing of this change. > > Details: > o Split pppoe_match_svc() into three different functions serving > different purposes: > - pppoe_match_svc() - match non-empty Service-Name tag from PADI > against all available hooks in listening state. > - pppoe_find_svc() - check that given Service-Name is not yet > registered. > - pppoe_broadcast_padi() - send a copy of PADI packet with empty > Service-Name tag to all listening hooks. > o For NGM_PPPOE_LISTEN message use pppoe_find_svc(). > o In ng_pppoe_rcvdata() in a PADI case use pppoe_match_svc() for > a non-empty Service-Name tag, and pppoe_broadcast_padi() in > either case. > > A side effect from the above changes is that now pppoed(8) and mpd > will reply to a empty Service-Name PADI sending a PADO with two > Service-Name tags - an empty one and correct one. This is not fatal, > and will be corrected in pppoed(8) and mpd later. No need to update > node interface version. > > Supported by: D-Link > > Revision Changes Path > 1.77 +117 -43 src/sys/netgraph/ng_pppoe.c > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D927B4.9040602>