"no matching session" in ng_pppoe.c 184.108.40.206? (RELENG_6)
julian at elischer.org
Mon Dec 17 18:04:38 PST 2007
> On Sun, 09 Dec 2007 14:01:27 -0800
> Julian Elischer <julian at elischer.org> wrote:
>> cpghost wrote:
>>> On Sun, 09 Dec 2007 11:13:13 -0800
>>> Julian Elischer <julian at elischer.org> wrote:
>>>>> ----------- manually restarting ppp(1), then:
>>>>> 17:10:47.306928 00:00:24:c2:45:74 > ff:ff:ff:ff:ff:ff, ethertype
>>>>> PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1]
>>>>> 17:10:47.306939 00:00:24:c2:45:74 > ff:ff:ff:ff:ff:ff, ethertype
>>>>> PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1]
>>>> we still have 2 sessions instead of 1, but there is less confusion
>>>> so things sort themselves out.
>>> Just one more thing:
>>> If I remember correctly, sending two PADIs in quick succession
>>> was ppp's "normal" behaviour for *years* now (is it expected or
>>> required by the protocol? I don't know). I've always wondered
>>> why it was so. But that didn't cause any harm as it seemed one
>>> of the two PADO was picked up and eventually turned into a session.
>> btw try mpd as well.
> So... I'm running net/mpd5 on that router for a few days now, and
> it managed 3 forced disconnects in a row and no session chaos at
> all, while ppp(8) would probably have initiated a lot of parallel
> sessions again but no connection.
> So up until now (but perhaps it's too early to be sure?),
> net/mpd5 is fine, while ppp(8) is not.
> Btw, I've compared the sources of ppp(8) from 2007-09-24/25
> when it was still working, and 2007-11-30 when I've updated
> the router, and there's NO difference there at all. Whatever
> broke ppp(8), it was not ppp(8) but something else
> (I suspect ng_pppoe.c): maybe the code clean up exposed
> some hidden bug in ppp(8)?
> I hope ppp(8) will be fixed before 6.3-RELEASE; even though
> net/mpd5 is excellent and very snappy as well. ;-)
mpd is also using ng_pppoe of course.
More information about the freebsd-stable