> > > Some ISPs still do authentication via SLIP. At least, here in
> > > Brazil.
> > SLIP only? Here in Holland, some providers still send a text
authentication
> > string for use with SLIP, but all recognize PPP headers once you've sent
> > them.
>
> I don't know very well about it. What I've seen is only
> text-authentication servers.
> So, that's arise a question: how you know an ISP authenticates by
> text or by PPP? Checking if the first block sent by the ISP is a PPP
> packet or text data? If it's PPP, just start the PPP layer or, if it's
> text, start the interactive logon?
No. Read the PPP (or was it in the HDLC?) docs thoroughly, and you will see
that a server can detect the peer using PPP by checking for one of the
following three byte sequences (although only the second is officially
correct):
7e ff 03 c0 21
7e ff 7d 23 c0 21
7e 7d df 7d 23 c0 21
By the way, it is in the HDLC docs (rfc1662), appendix B.
So, as the client it comes down to that you should start sending
Conf_Requests (on a timeout basis of about 4 seconds) and the peer will
respond with its own Conf_Request. After about 10 retry timeouts (Max_Retry
timeout-) there is clearly no PPP support.
> > If you need to fill in your IP-address yourself, it's a SLIP connection.
If
> > you don't, it's PPP.
>
> Yeah. But I don't know ISP that allow you to fill in your IP
> address. :)
Yes... Strange, actually. Maybe the ISP sends an IP packet to the peer right
after the connection, and the source IP address has to derived from that???
> I agree. But it's useful for PPP control packets (LCP, CCP, IPCP,
> etc), UDP and ICMP packets. You can gain some speed if you disable the
> checksum for TCP packets, but I doubt if it's worth...
It's not worth it. The PPP FCS is only generated over the local peer-to-peer
link. The TCP checksum is calculated over the originating packet.
And as for LCP packets, the use of FCS (and all other basic settings like
the HDLC escape code settings) is required for those, if I'm correct... Read
the RFC about it, it should be there somewhere...
> Make separate stacks for each lower-level protocols, so you don't
> "inflate" the code. But you can run only one "stack" (SLIP or PPP or
> anything else) each time (you must shutdown one to start another).
Yes, I understand. However, as long as it isn't nessecary, I will leave it
like it is...
> > You still receive 'challenges' after you have connected (in case someone
> > 'takes over' your connection... yeah right!). And if you don't answer
them,
> > you get disconnected. No, PAP is much much much much simpler.
>
> Bah... Just to make your connection slower...
> Do you know any ISP that accepts only CHAP?
AFAIK the PAP is the basic protocol. It is not required, but highly
recommended. The docs say that if the demanded protocol (CHAP) is NAKed,
then the next Auth. Protocol on a stack should be used. So it definately
implies all servers should implement PAP. Once again, read the PPP docs
about this, I am not 100% sure.
> > > > Header Compression
> > > It's worth, since this kind of compression is too easy.
> > It complicates my implementation, which means it slows down. And I want
as
> > much speed as possible.
>
> Strange... In my implementation, it speeds up the connection,
> since I know that I can skip that bytes... Maybe my PPP layer is better
> implemented than yours? :)
Maybe... :)
The point is, I don't know exactly how fast my connection is compared to my
MSX. If my MSX needs almost all time between receiving two bytes to process
the data, it is not worth not checking for it. However, if receiving a byte
has a lot of waits in front if it, it is definately worth the effort.
Ofcourse, I could check it... (look how many times the wait-loop is looped).
Anyways, I also haven't implemented it for simplicity. One byte over 500,
maybe 1000 bytes doesn't matter that much. And it complicates certain
things. No, maybe later.
> > > Right. I recommend you implementing Van Jacobson compression.
> > > That's what I'm doing right now on UZIX.
> > I was already thinking about that. What's the RFC of the docs???
>
> RFC 1144.
ok, thanks.
> > Hmmm... Well I'm not that much of a modem-expert either. But it's quite
> > simple, once you understand HDLC.
>
> Maybe you can answer my last mail about modems, so (the one with a
> BASIC code)?
See my other reply.
~Grauw
--
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
email me: [EMAIL PROTECTED] or ICQ: 10196372
visit my homepage at http://grauw.blehq.org/
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
