> > > 3. How to make the modem dial and establish a connection
> > send init string:
> > ATZ
> > OK
>
> This "OK" isn't sent by the modem itself???
It is.
> > and then dial:
> > ATDT0123456789
> > CONNECT 115200
>
> And also this "CONNECT"?
It is sent by the modem (actually the ATDT and the ATZ too since it's
echoed). I am merely listing the responses you get.
> > Now you are connected to the peer.
>
> Nice. So I just need to send and receive characters
> (including modem commands) from the RS232 without worring about anything?
Well, you have to worry about HDLC (and about flow control when you access
the drives), but besides those, no.
> > > 4. How to detect that the server I dialed send some strings
> > > ("login:", "password:", etc)
> > That's part of the SLIP protocol. DO NOT USE IT!!! It really, really
sucks.
> > For example, it doesn't support IP address negociation etc
>
> Hey fudeba... I know SLIP very well, ok?
k.
> > not supported by the server. Instead send a PPP Conf_Req in an HDLC
frame
> > immediately after the CONNECT message to start using PPP.
>
> 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.
If you need to fill in your IP-address yourself, it's a SLIP connection. If
you don't, it's PPP.
> > The only disadvantage of PPP over HDLC instead of SLIP is that HDLC is
more
> > secure and has an FCS check over all the outgoing and incoming bytes,
which
> > is a bit double since the upper level protocols (IP, TCP) also have a
> > checksum. You can ignore the FCS when receiving frames, and it is quite
> > easily calculated for outgoing frames (in most cases the outgoing
traffic is
> > lower than the incoming traffic, so it's not really a problem). And
using an
> > experimental protocol (I don't know how much servers implement it, but
my
> > guess is most do) you can even disable the FCS check. However in my PPP
> > implementation I don't support that yet.
>
> FCS is very easy to implement using a lookup table (less
> computational cost for slow machines). I don't remember the RFC by now,
> but it has a C-coded example of a fast FCS calculation using a lookup
> table.
Yes, I know. I have it (it's RFC1662). My implementation of it works and is
fast (although the explanation was a bit unclear at first). But it's a
useless error check. There is no error recovery system provided, and
besides, IP and TCP already provide there own error discovery mechanisms
which work just as good, so it's a bit double.
> > > 5. How to send to the server some strings (the user name and
> > > password)
> > Use the Password Authentication Protocol (PAP).
>
> Most ISPs use PAP, but, as I said, some ISPs use SLIP for
> authentication.
Some very old ones (which haven't been updated for ages). And with the
current amount of free providers you can quite easily switch to another one,
so I don't think it's worth the trouble to implement SLIP as well. Support
for multiple lower-level protocols only makes things slow.
> > > 6. How to send/receive data from modem (authentication finished,
> > > so I want to start sending/receiving data!)
> > It's all in the PPP protocol
>
> The PPP protocol I know. I'm just not familiarized with the
> interaction of a modem and PPP. I'm just not sure how to "talk" with the
> modem and to know when I start the PPP layer.
Through HDLC, documented in RFC1662. That's about all of it. HDLC is a bit
like SLIP, it provides escape-codes to use packets over a serial line.
[...]
> Yeah, I also know that.
[...]
> I know, I know...
:)
> > packets until all options have been negociated. Options include
> > Authentication Protocol negociation (PAP or CHAP (yuk!)
>
> I didn' study CHAP yet, so I can't comment.
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.
> > Header Compression (matters a very few
> > bytes, not worth the effort)
>
> 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.
> > and several other things which are only making
> > things complex like Magic Number etc.
>
> Magic Number is just useful for loopback test. But generating a
> random number at the beginning and using it is not problem.
No, it actually isn't, no. 1 byte: clock, 2 bytes: JIFFY, 1 byte: R register
and voila. A Magic Number.
> > 4. Established.
> > Now you can start sending IP packets to the peer (using PPP protocol
#0021).
>
> 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???
> > If you need to be helped out you can ask me specific questions (me=PPP
> > expert :)).
>
> Thank you. But me also PPP expert. I'm just not a modem expert. :)
Hmmm... Well I'm not that much of a modem-expert either. But it's quite
simple, once you understand HDLC.
> > I've got two 2400bps modems layin' around, but the mail cost would exeed
the
> > value of the modem 10 times. It's not worth the money.
>
> No problem. Maybe some day I get one from a kind person. :P :)
:)
~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/
****
