Ok, I went out and patched the pppd software exactly according to crisk's
suggestions, and I even reordered the lcp options so that they will be
sent in the exact order win2000 sends them. Unfortunately, none of this
worked - same result, even though I compared the packet sent by Linux and
win2000 - they look almost identical. If anyone wants the patched ppp for
testing, please send me mail.
My current conclusion is, unless I made a mistake with the patch(it's
quite possible), that the problem is not with the ppp options. It might be
a bug in the IP stack of the orckit modem which causes it to ignore the
pptp packets sent by Linux...
Thanks,
Lior
On Mon, 29 Jan 2001, crisk wrote:
>
> On the ADSL note, I've read in today's Yediot Achronot that
> "Microsoft and Orckit fixed the serious problems with Orckit's ADSL
> equipment and Windows ME." They say a fix is available on Microsoft's
> site... this might be relevant.
>
> You guys mightwant to bug Orckit to fix the firmware on their lousy
> modems, too. There's nothing wrong with the LCP options that pppd sends,
> except that the Orckit modem might not understand 'asyncmap' (hey,
> it's not on RFC1661, but nobody bothered either reading the IETF pppext
> drafts or implementing standard unknown option rejection). I have
> parsed this information from the captures (Windows vs. Linux) that mulix
> sent me:
>
> The options in the first LCP (id 0) packet sent by a Windows dialer
> (ordered as they appear in the packet):
>
> - Magic-Number (32-bit number)
> - Protocol-Field-Compression on
> - Address-and-Control-Field-Compression on
> - Callback value 6 (meaning CBCP will determine callback)
> - Multilink-MRRU (Max-Recieved-Reconstructed-Unit), value 0x064e (1614)
> - Multilink-Endpoint-Descriminator (with a class 1 [locally
> assigned] address 22 bytes long)
>
> The linux pppd first LCP (id 1, unlike Windows' id 0):
> (the lousy Orckit modem never replies to this LCP message)
>
> - Asyncmap 0x00000000
> - Magic-Number (32-bit number)
> - Protocol-Field-Compression on
> - Address-and-Control-Field-Compression on
>
> If I had to fix this, I'd first set the id of the first LCP packet pppd
> sends to zero. This is exactly the kind of stupid bugs people would make
> and never test for, and it takes about 2 seconds to rig pppd to use 0
> (ie change line 708 in fsm.c from "f->reqid = ++f->id" to "f->reqid =
> f->id++" or something like that)
> If this fails, I'd get rid of the asyncmap as well ('pppd -am' should do
> this). And if -that- failed, I'd add multilink, and finally, callback.
>
> It seems odd to me that nobody fixed the pppd yet. I don't have ADSL,
> but a good friend of mine does, and obviously not a few people on this
> list. Surely there must be some protocolguru with interest of fixing
> this.. reverting to Windows is not an option.
>
> On Sun, 28 Jan 2001, mulix wrote:
>
> > Hi Lior,
> >
> > attached to this email is an updated version of the ADSL howto, covering
> > what we know about the problem you ran into.In short, there are several
> > kinds of orckit ADSL modems, one of whom works with Linux in the default
> > configuration (pptp with the trivial patch) and one of whom requires a
> > patched pptp and a patched pppd to (maybe) work.
> >
> > > Lior David wrote:
> > >
> > > Hello,
> > > I have a problem connecting to the ADSL service from Linux. I have
> > > tried everything I know and I simply can't get it to work. Maybe some
> > > of the ADSL experts here will have an idea...
> >
> > --
> > mulix
> >
> > linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
>
> ._
> [EMAIL PROTECTED] ._/-======\\\ _
> |_.---------`-------^-----------------._
>
> Sexually tilted quote from STAR WARS:
> 7. You've got something jammed in here real good.
>
>
>
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
