Bartlomiej F. Tajchman <bart27@merigold.nospam.pl> wrote: > Pascal Hambourg pisze: >> >> Remove default-mru from your options file. > I removed it and started pppoe with minimal configuration: Please DON'T change configurations unless someone suggested the change. Restore the original options, sans the default-mru of course. > options: > debug > plugin rp-pppoe.so It's highly unlikely you are attempting kernel mode PPPoE, as desirable as that might be. <snip> > Connection still doesn't work: > Connect: ppp0 <--> /dev/pts/3 > sent [LCP ConfReq id=0x1 <mru 1492> <auth chap MS-v2> <magic 0xd512cef1>] > rcvd [LCP ConfReq id=0x1 <mru 1480> <magic 0x12614217> <callback CBCP>] > sent [LCP ConfRej id=0x1 <callback CBCP>] > sent [LCP ConfReq id=0x1 <mru 1492> <auth chap MS-v2> <magic 0xd512cef1>] > etc. As PH has observed, the LCP messages sent to the peer are either corrupted or lost in transit. Since they are sent through pppoe-server it seems likely that pppoe-server is part of the problem. > I haven't ConfAck and it doesn't try to send password/user. I tried it > with PAP/CHAP/MS-CHAP-v2 - the same (no) effect. You didn't mention the pppoe-server bug PH pointed out. That must be fixed. Even if it's not part of the current problem it will cause another problem later. A pristine rp-pppoe-3.8 doesn't have the bug. -- Clifford Kite /* 97.3% of all statistics are made up. */

Clifford Kite <kite@not.available.tld> wrote: > So I guess pppoe must ignore session frames that don't contain the peer > MAC from the -e option as the AC MAC. I hadn't thought of that. And now that I read it I wish I hadn't thought of it. Session frames from the peer should contain the local MAC as the AC MAC, said local MAC being supplied by pppoe-server during discovery. Does pppoe use the local MAC from the -e option as the AC MAC in frames it sends? It appears to me that it should but I can't be sure. -- Clifford Kite