OS/2 Shareware BBS: 35 Internet/35-Internet.zip/tserve11.zip/TSERVE.ISP

Text File | 1996-02-02 | 35KB | 667 lines

        HOW TO BECOME AN INTERNET SERVICE PROVIDER WITH WARP!

        TSERVE V1.1b - PPP (terminal) server for WARP CONNECT!

If you have WARP connect, a network, and a dedicated connection to the
internet, you can be an Internet Service Provider (ISP)!  This shareware
program and documentation will help you get well on your way.

This package is NOT intended to provide you with everything you need to
get started, nor is it intended to teach you all about the internet,
TCP/IP, or networking. You'll need to do a LOT of research on your own
and just when you think you know all you need to know, you'll discover
that you've only begun. Even the experts aren't experts when it comes to
the internet.

This package assumes that:

        * You have WARP CONNECT installed and running on at least 2 CPU's.
        (you can do this with the TCP/IP package, but the installation and
        setup may be different.)

        * You have these machines connected to eachother through a network.

        * You have an idea what networking is, packets are, what TCP/IP is
        and you're reasonably proficient with OS/2.

        * You have a dedicated connection to the internet (or you know
        where and how to get one).

        * You want to offer dial up connections to your network and the
        internet through PPP.


        A QUICK REFRESHER...

        When you connect a bunch of computers together so that you can send
data back and forth between them, you have a network.  For most of us,
though, a network just means that we can use files and printers that we
don't have on our personal machines.  How does this happen?  If it were a
perfect world, when you wanted to see a file on another computer, you'd
press a button, and your computer would send a message to the other asking
for the file.

        "HEY!, Send that thing over here!"...

        The other computer, not having a whole lot to do with it's millions
of operations per second, would respond by sending the whole file to you in
one big chunk.

        "Oh, Ok, You asked for it, here it comes... <stuff> <stuff> <stuff>
        <stuff> ..."

        The problem is, we don't live in a perfect world and communications
are just as imperfect... While the sending machine would be sending the
file like you see it above, the receiving machine would probably be getting
it something like this:

        "Oh, Ok, YoU asKED for iT, HERe i ome ... <SnarF> <Snort> <Sniggle>
        <stuff> ..."

        The first thing we do to get around this is put check values into
the messages and files that we send so that when they get to the other end,
we know wether they're correct. This way, when the sending computer sends
<stuff> and the receiving computer gets <SnarF>, something can be done
about it. Specifically, the file or message can be sent again. In fact, you
can keep asking for the same file to be sent again and again until you finally
get a copy that "looks" like it's correct. (Check values are not a certain
way of knowing that what you got is the same as what was sent).

        Think about that for a second though... Sending files takes time
and money... If Murphy is having a field day (and he usually is) then
you'll get the whole file completely right (all 200 megabytes of it) up to
the last bit of <stuff> and then the last one will be <Sniggle>. DAMN! Now
what do you do? Send the whole thing again? NO!

        Instead of sending our messages back and forth in huge monolithic
blocks, we break them up into little pieces, and send the pieces one at a
time with a check value in each one. So, now when you ask for a file, the
sending machine spits out something like this:

        "<Here it comes 1>...<stuff 2>...<stuff 3>...<stuff 4>..."

        And when you get it, you might see something like this:

        "<Here it comes 1>...<stuff 2>...<Snort 3>...<stuff 4>..."

        When you see that, you can ask for #3 to be repeated (a small part
of the whole file) while you continue to recieve all of the other
"packets". This is the fundamental basis of networking as we know it:

        * Messages are broken down into packets.

        * Packets are sent and repeated individually as necessary.

        So, how does all this relate to the internet? Well, there's one
piece missing, and it's one of the biggest stumbling blocks. That's
addressing.

        When you connect a whole lot of computers toghether and have them
all send these packets to each other, you need a sure way of figuring out
who gets each packet. The way it's done on the internet is with an IP
address. IP (Internet Protocol) is essentially the embodiment of our first
idea - breaking messages and files down into manageable little chunks. Each
packet (or datagram or whatever you've heard it called) has a piece of the
message, an address to go to, an address it came from, and a check value to
help decide if it's right when it gets where it's going. The Internet
Protocol is an agreement (among the machines) about what these packets
should look like and how they should be sent back and forth.

        Each computer on the internet has it's own IP address so that each
packet knows where it came from (the computer that sent it) and where it's
going (the computer who should receive it). If there are extra machines in
between the sender and the receiver, those machines need only look that the
addresses in the packets and send them in the right direction. Almost
nobody needs to know exactly how to get to anywhere as long as enough
machines know which direction you go to get there...

        It sort of works like this: You're trying to get to the doctor in
a small town full of gas stations. Each gas station has a lanky guy in
cover-alls who basically knows which direction to go to get "close" to the
doctor's office. One of these guys at one of these gas stations happens to
live right next to "Old Doc Brown" so he can tell you exactly where to go.
But first you've got to get to that guy...

        You start your journey.. up to the first gas station and ask Elmo
where the doctor's office is. "Don't know for sure, but you gotta turn left
and go down that road somewhere." Maddening isn't it... right about now
you can look over at your co-pilot who's usually so smug about this
direction thing, and give them the look... you know, the one you always
thought about when they said "why don't you stop and ask directions!.."

        So, you turn left, go down the street, and run smack dab into
Burt. Burt says, "Hmmm... according to my list here, Doc's down this road
to your right somewhere." Again, not particularly encouraged by your
ordeal, you thank the guy and head out down the road.

        Wouldn't you know it, you end up at another gas station, and this
one has a sign that says something about a doctor, but you don't read it
because you're just too mad, tired, and fed up with the whole gas station
metaphore.

        Dickie comes up to you, with his name tag flappin' in the breeze
and says in the all too familiar drawl, " C'n I he'p you?". You're
infuriated, but you try to keep your cool. Looking down at your gas guage,
you realize you've got about one more road's worth, and it just so happens
you're trapped in a town where all the gas stations DON'T HAVE ANY GAS! You
clench your fist, take a breath, relax just a bit, and calmly articulate,
"Could you please tell me where I can find the doctor?" Fully expecting a
repeat of your previous experiences, you prepare for the worst.

        Luckily for you, and for Dickie, this is the end of your chaos.
Dickie replies, "Sure, 's right over there, third house on the left, you
can't miss him."

        In case you didn't get it, all the guys at the gas stations were
routers, the list talked about at the second station was a routing table,
and the gas guage was a "hop count". Routers "ARE" the internet, it
wouldn't work without them.

        This idea is so big, that there are some internet sites full of
special computers who's entire job is sending packets in the right
direction. At least one of the machines on your network will be doing this
job.

        Something else you should know about IP: It doesn't make sure you
get the whole message, and it doesn't make sure you get it in the right
order. In fact, it doesn't even make sure you get it at all. For that, you
need TCP (Transport Control Protocol). TCP is an agreement about how and
when to ask for "retransmissions" so you can get the parts of a message or
file that didn't get to you, or got to you wrong. IP lets you send
messages, and TCP lets you organize the messages so that you're sure to get
them all.

        For example, if the sending machine sends:

        <Stuff #1>...<Stuff #2>...<Stuff #3>...

        And the receiving machine gets:

        <Stuff #1>...<Sniggle #2>...<Stuff #3>...

        or

        <Stuff #1>..................<Stuff #3>...

        IP won't do anything about it. All IP does is send the packets
along. It's up to TCP to ask for <Stuff #2> to be retransmitted. TCP does
this by sending a packet back to the sender to ask for the repeat. TCP
sends this packet using IP because TCP can't do it! TCP only organizes the
packets, IP sends and receives them.

        The reason this is important is that in order for one machine on
the internet to be able to "reliably" send OR recieve messages, it must
be able to send AND receive packets. If either one of these doesn't work,
the whole thing quits.

        A LITTLE STORY...

        I mention this because it's important to recognize the true nature
of what's going on, especially when you encounter problems with your network.
One such problem happened to me while I was setting up my service.

        One of my machines acts as a web server. It was happily running
along sending beautiful web pages to everyone who'd care to ask. Then one
of my dial-up users connected to my system and tried to "talk" to my web
server. It didn't work!

        The first thing I thought was... there must be something wrong with
the user... Except that they could talk to anything they wanted to on the
internet, just not MY web server. So I scratched my head.

        The next thing I thought was that it must be my web server...
except that everybody on the internet could see my web server just fine...
So I scratched my head.

        I Started tracing the packets (remember those) to see where they
went... The dial-up user would send their packets to my web server, and
they got there fine. My web server would send the reply packets to the user
and they'd get half way there... Then it broke down. The return packets
(from my web server) were getting all the way back to my router (where the
dial-up user was connected), but they stopped right there.

        The result was that it looked to the user as if there was no web
server, and it looked to my web server that there was no user. All of this
even though the messages were making 99% of the round trip.

        I don't want to get too technical about this right now, because you
are probably tired of my ramblings, and you want to get on with setting up
your internet site. Besides, there'll be plenty of time for old war stories
once you've go it all up and running.

        OK, SO HERE GOES...

        Here is a QUICK START list of steps to take to set up your internet
site. I'll try to cover enough detail to make sure you know what's going
on, but I obviously can't tell you everything that's involved. You should
do a LOT of research, talk to others who have done similar things, and
spend a lot of time reading books on the subject. Even the experts aren't
experts on everything, the internet is a BIG place with scary dungeons.


       *1) You need to find an internet provider that will give you a
        dedicated connection to the internet. I will assume that you're
        going to use a PPP connection through a 28.8k modem. This is NOT
        the only option, and it's not the best option, but it will get
        you started.

       *2) You need to register a DOMAIN NAME with "the internic". The
        internic is the organization in charge of assigning domain names
        and IP addresses on the internet. Each machine on the internet
        should have it's own unique IP address. Your DOMAIN NAME will
        identify you to other people on the internet, and make it easier
        to find you. For example, you could telnet to my BBS system using
        it's IP address: 206.239.24.12, but it's a lot easier to remember
        that it's bbs.micro-neil.com. My system's domain name is:
        micro-neil.com. When I put a new computer (host) on my system, I
        can simply come up with a host name for it and prepend it to my
        domain name. For example, my web server is www.micro-neil.com.

       *3) You need to purchase a CLASS C license (again from internic.)
        A CLASS C license is your own personal set of IP addresses. With
        a CLASS C, you get 256 IP addresses which you can assign to any
        of your computers and your dial-up user's computers. For example,
        my CLASS C address is 206.239.24.0. This means that I can use any
        address from 206.239.24.1 to 206.239.24.254. Notice that I left
        off .0 and .255. That's because these are special. When you use
        206.239.24.0, you're talking about my entire "subnet" or "sub-
        network". That means any machine on my network. When you use
        206.239.24.255, you're talking about ALL machines on my subnet.
        This is the "broadcast" address.

        A note about address usage:
        A broadcast address (.255) is used when you want to send a message
        to all machines on the subnetwork. This is used, for example, when
        one computer (such as a server) want's to advertise itself to all
        of the other computers on the network.

        It is customary to save the lower IP addresses .1-.9 etc for any
        routers you have in your system. This is not any kind of hard rule,
        but it's not a bad idea to stay pretty close to the conventions so
        that when you need help (and you probably will) the person helping
        you will have some idea what's going on.

        It is also customary, although I don't know why, NOT to use the .1
        address. Perhaps I'll find out someday, but for now, I don't mind
        letting it sit idle.

        A note about your Class C and Domain name:
        I highly reccomend that you let someone (your provider) handle the
        legwork for you on getting these things set up. This work cost me
        $200. That's $50 for the Class C license, $100 for the domain name
        registration (good for 2 years), and $50 for the leg work. I hear
        that it's well worth the price, and I believe it.

        Also, letting your provider get this set up for you leaves them in
        a good position to help you with the other things you'll need to
        set up.

        NOTE: There are other types of addresses CLASS A, B, & D, but you
        will probably not need them. If you do, you've already outgrown the
        information in this document.

       *4) Your provider will need to set their router(s) to route packets
        destined for your network to your connection. Any packets destined
        for your subnetwork (CLASS C) will be forwarded to your system
        through your connection. Remember from above that as long as enough
        machines know which direction to go (what connection to send a
        packet through) nobody needs to know exactly how to get there.

       *5) Your provider will need to place your machine name(s) into
        their DNS so that other people on the internet can find you.

        About machine names and the DNS (Domain Name Server): A DNS is a
        computer (or program) who's job it is to figure out an IP address
        from a machine name, and a machine name from an IP address.

        For example, when somebody plugs http://www.mirco-neil.com/ into
        their browser, their browser asks their local DNS what the heck
        www.micro-neil.com means. More specifically, it asks for the IP
        address that belongs to that name. Hopefully, after some searching
        and looking around, the DNS will tell their browser that the IP
        address is 206.239.24.10. That's the IP address of the computer I
        use as my web server. From then on, their web browser knows exactly
        how to address it's packets when it's asking for pages from my
        server.

        You will find a place in your TCP/IP configuration notebook where
        you should enter the address of your provider's DNS server.

        It is possible to run your own DNS, however, that topic is beyond
        the scope of this document.

       *6) You'll need to make names for the machines on your network.
        I used the names sys0.micro-neil.com, sys1.micro-neil.com and so-on
        for all of my systems. It's probably a good idea to follow some
        kind of convention to make things easy on yourself. You may ask now
        where www.micro-neil.com comes in... It is an alias. In other
        words, along with the real machine (host) names in the DNS tables,
        there are aliases. So, for example, my web-server machine's
        registered name is sys0.micro-neil.com. If somebody asks a DNS what
        host is attached to the address 206.239.24.10, the DNS will respond
        with sys0.micro-neil.com. However, if somebody asks the DNS what
        address goes with www.micro-neil.com, the DNS will look it up, find
        that it's an alias for sys0.micro-neil.com, and then return that
        address.

        Once you've decided on the machine names for your systems, you will
        need to tell your provider so that they can make the entries in the
        DNS. You will also need to go into your TCP/IP configuration
        notebook on each machine and fill in the host name for that
        machine. You will want to use the REAL host name, not the alias.

        Remember that each HOST on your network will need a unique IP
        address and you'll have to assign it when you pick the name.

       *7) You need to set up TCP/IP across your network (Mine is a 10 base
        T) by configuring it in each machine that will participate. In your
        TCP/IP setup notebook, you'll need to:

                * Enter that machine's IP address.

        * Enter that machine's host name.

                * Enter your netmask (255.255.255.0).

                * Enable your network interface.

                * Enter the address of the DNS (provided by your provider).

        This step will not get you onto the internet, but it WILL establish
        your TCP/IP network on your Ethernet (if that's what you're using.)

        This much should be done to every machine that will be
        participating in the network. You'll also need to pick one of your
        machines to use as a router. That one will be treated differently.
        On my system, I use sys2.micro-neil.com (206.239.24.12). This
        system connects my network to the internet and connects to my
        remote callers. Since this machine is my router, I tell all of the
        other machines on my network to send any packets they can't figure
        out to this machine. That is, when my web server needs to send a
        packet somewhere it isn't directly connected to, it sends the
        packet to my router machine.

        On all machines except for your router, add a defaultroute to the
        routing table in your TCP/IP configuration notebook that points to
        your router. On my system, on sys0.micro-neil.com (206.239.24.10) I
        enter a default route to sys2.micro-neil.com (206.239.24.12). So,
        whenever 206.239.24.10 needs to send a packet somewhere else, it
        looks in it's routing table and sees the default entry, and sends
        the packet to 206.239.24.12. Since 206.239.24.12 is my router, when
        it gets the packet, it should know where to send it next: to my
        internet provider, or to some other system it's connected to like
        one of my dial-up clients.

        While you're in your TCP/IP notebook, you might as well enter the
        names of any servers that you'll be using from your provider (or
        your own system) such as news servers, mail servers, web servers,
        etc... Most of this information is not absolutely necessary, but
        since you've got the thing open, you might as well enter everything
        you can.

        If you've set all this up right, you should be able to PING all of
        the systems on your network. Since you are not yet conected to the
        internet provider, you will need to tell ping the IP addresses of
        the machine(s) you're trying to ping rather than the names.
        Remember that the DNS (name server) is at your internet provider
        and we're not talking to them yet. On my system, when I want to
        make sure I can "talk" to my router machine from my web-server
        machine, I get into an OS/2 command line window (on my web server
        206.239.24.10) and type:

        ping 206.239.24.12

        When I'm done looking at all the ping responses, I just hit ctrl
        break and close the window. If I don't see any responses, I start
        asking questions about what I've missed. Remember from earlier
        that you need to be able to send and receive in order to send or
        recieve data reliably on a network. Ping works by sending a packet
        to the machine you tell it (206.239.24.12) and waiting for a reply.
        When that machine gets the packet, it will send a response back
        where that one came from. If ping sees the return packet, the you
        have successfully networked those two machines. This works across
        the room or the entire internet (for the most part). If ping does
        not see a response, then the packet(s) got lost somewhere.

        I found it extremely helpful to have a lot of blinking lights. Not
        only is it impressive to look at, but when you're trying to see if
        your packets are getting somewhere, that's often the only quick
        indication you have. If you don't have a network concentrator with
        lights on it that show traffic, then you're missing out.

        ****

        At this point, you should have your network talking to itself. You
        should be able to FTP, TELNET, or WEB browse to any system that is
        directly connected to your network. Next step is to get you onto
        the internet... otherwise it wouldn't be much fun would it?

       *8) Establish your PPP connection to your provider. You should know
        that dial-up phone line connections go down from once an hour to
        once a week.. If you get a good connection for longer than that,
        you are really lucky. Also, even the best 28.8k modems seldom get
        connections better than 24000, and even more seldom greater than
        26000... so don't expect miracles, and be prepared to increase your
        "bandwidth" quickly if you have a lot of traffic. It can get mighty
        slow if you have 5 people all trying to work through a single 28.8k
        modem.

        Another thing you should know about modem connections. Remember
        from above when we talked about retransmissions and missed packets.
        If your connection is losing the odd packet from time to time, you
        will see errors displayed by your PPP program. If you suspect that
        your data isn't flowing as fast as it should, and you see a lot of
        errors popping up in the window running your PPP program, it's a
        good be that you're:

                Talking to the modem too fast for your computer's hardware.
                TRY USING A LOWER BAUD RATE.

                Connected on a very bad line and your modem(s) are
                retraining too often. Try a different line, or lower
                speeds. Also try turning off compression.

        When you establish your PPP connection with your internet provider,
        I suggest that you use a .CMD file rather than the PM dialer. This
        makes it very easy to re-establish the connection should it go
        down.

        My connection command file looks something like this:

        :BEGIN

        PPP com5 115200 rtscts modem reneg mru 1500 priority 1 exit
           206.239.24.2:207.123.123.2 defaultroute connect "slattach
           atdt5432109 ogin: myname sword: myword"

        countdwn 10

        goto BEGIN


        The PPP command line above is wrapped around, but you must type
        it all on one line. The countdwn program is a simple utility I have
        that gives me 10 seconds to kill the task if something really ugly
        happens. Essentially, the ppp command is executed repeatedly until
        I kill the program. That way, if the connection drops, I just wait
        a few seconds and it dails in again. The addresses and phone number
        above are fake, but you get the idea.

        This PPP command line is where all the fun begins. Remember what I
        said about IP addresses belonging to machines? I LIED! They belong
        to interfaces between machines. So, if you have a computer that is
        connected to more than one network, it will have a number of IP
        addresses... one for each network connection. (sort of).. You
        should do some reading about this, because network routing can get
        a bit tricky to explain, and I don't want to make this text any
        longer than it needs to be.

        Suffices to say: the 206.239.24.2 address above belongs to my
        router machine as an interface to my internet provider. The
        207.123.123.2 address belongs to my internet provider as their
        interface to my router machine.

        Remember how we put a defaultrout entry into every machine except
        the router machine... The PPP command line above creates the
        default route for the router machine. This means, whenever the
        PPP connection is active, if the router machine gets a packet that
        doesn't belong to it's network, it will send it out the (206.239.24.2)
        interface and on to the internet provider. Since the provider
        is sending all packets destined to my network into my router
        machine through the same interface, we've established the 2 way
        connection we need to communicate with the internet.

        Once you have your PPP connection running, you should be able to
        PING the DNS or any other system on the internet provider's network
        and, for that matter, anywhere on the internet. If not, go back and
        check to see that you haven't skipped a step.

        Once you've successfully pinged out onto the net from your router
        machine, you should also be able to ping the internet from any of
        the machines on your network.

        For example, once my PPP connection is established with my
        provider, I can go to my web server machine and ping the DNS, or
        www.yahoo.com, or anywhere I like.

        CONGRATULATIONS, YOU're ON THE NET! At this point, you should be
        able to communicate directly with any system on the internet, and
        they can communicate with you. It would be wise to look into
        security measures, especially if you have a file server or some
        other service on your network that speaks TCP/IP... If you're
        concerned about this, you should disconnect your PPP link until
        you've taken actions which make you more comfortable.

        That's it for the quick list. Now we get into providing access to
outside callers. Essentially, they will connect with you in the same way
that you connect with the internet. On my system, I have outside callers
connect with my router machine (sys2.micro-neil.com) using the TSERVE
program. This program answers the phone, gets the user's password, and
determines if they are a PPP user or a BBS user. If they're a PPP user, it
asks them for a password (to make sure) and starts PPP. Assuming they
called in using a similar command line to the one above (or using the
Dial-Other-Providers, or whatever package), they will instantly be able to
communicate with the internet through my ppp connection.

        Just for the sake of details, the important things to note about
        connections to dial-up callers are:

        Typically, they do not include IP addresses in their settings...
        this allows my system to assign the addresses dynamically.

        Their ppp command line includes the defaultroute command, and the
        ppp command line on my router machine DOES NOT. Remember that we
        want all unassigned packets to go out to our internet provider, not
        to the dial-up caller.

****
        Getting outside callers to talk to the internet was fairly straight
forward. However, getting them to communicate with systems on my network was
a bit more tricky. This is the rest of the story I started to tell earlier.
Dial-in callers could see the internet without a problem. At the same time,
my network's systems could see the internet without a problem. The internet
could see both my systems and the caller without a problem. BUT my systems and
the caller's could not talk! WHY?

        As it turns out, this shouldn't have been the case... That is, the
PPP program should have (or could have) solved the problem when it
connected to the user. In newer versions of the PPP program, the problem
may be solved, or not... but here is the explanation....


        (THIS GETS TECHNICAL)

        When the caller sent a packet destined to one of my systems, the
packet went into the router machine, out into my ethernet, into the system
it was supposed to, and a reply (appeared) to go out. But it didn't.

        The TCP/IP network that is the internet is a separate thing
entirely from the ethernet network that ties my systems together. Each
ethernet card has it's own unique hardware address so that any two cards
can co-exist on any ethernet without any confusion about which packets
belong to which machines. In order for my systems to talk to each other over
the ethernet, they need to figure out what these hardware addresses are so
they can send the ethernet packets to the right places.

        The web server on my network tried to send a response to the
dial-up user, but didn't know exactly where to send it... so my server
transmitted a broadcast message requesting an answer to the question "Where
on this network do I send packets for this user?" As I understand it, the
real question was, which ethernet card address should I send these packets
to. This is an ARP request. (Address Resolution Protocol).

        You might ask why this would make a difference... "Isn't the system
supposed to send any packets it doesn't know about to the router, and won't
the router simply pass them on to the caller?" I asked the same question.
The answer is NO. The confusion comes in when the network interface is set
up.

        When we enabled the network interface for TCP/IP, we told the
routing tables in the web server that any packets going into this network
(206.239.24.0) should be sent out through the ethernet card. Any other
machine participating in this network would have answered the request
directly on the ethernet if it was asked where it was (ARP). But the caller
(206.239.24.0) isn't directly connected to the ethernet so it can't
answer directly.

        My server system assumed that since it had a NET entry in it's
routing table for 206.239.24.0, and the address it was trying to reach was
206.239.24.103, it should simply make an ARP request on the ethernet to
find out how to send it's packets. There is no reason to ROUTE the packets
to the router unless it doesn't know where to send them...and this packet
obviously belongs right here on the ethernet.

        ( I mistakenly thought this request was the response on it's way
        back to the caller from my web server...)

        The problem is that the user's dial-up interface isn't connected to
the ethernet, so it can't reply to (or hear) request for ARP. There was
no way for my server machine to know where to send the packets (on the
ethernet) so they'd get to the user, and there was also no reason to send
the packets to the router because they belong on the ethernet somewhere.

        THIS IS WHERE THE SOLUTION COMES IN.... We needed to make a proxy
ARP entry on the router for the remote user. What this means is that the
router machine will answer ARP request on the ethernet for the remote user.
Once this was done, my server machine could resolve the address, and start
sending packets to the dial-up user(s).

        You should look up the documentation, but here is how I enter proxy
ARP entries on my router machine to cover my dial-up users.

arp -s 206.239.24.103 00:00:c0:02:6c:4c pub

        The first part is easy to understand,.. (206.239.24.103) is the IP
address of the remote user. The part after that is a little more difficult,
it is the MAC address (hardware) of the ethernet card on the router
machine. What this line really says is, "If an arp request comes in for the
IP address 206.239.24.103 on the ethernet card at 00:00:c0:02:6c:4c, then
the router machine should reply for (in proxy) the host at 206.239.24.103.

        (You can get your ethernet MAC address using netstat)

        This allows anyone on the local network to resolve addresses to
remote callers. You should add an ARP entry in this way for each remote
user. If you really want to get it right, you should add the entry when the
user connects and remove it when they disconnect... that way, you can have
multiple hosts answering calls. PPP should do this, but it's broken..
You'll find the command line parameter in the documentation, but at the
time of this writing, it was not working correctly.

*****

        That's basically it.. If you've done your research, and you've
followed these steps, you should be taking calls and surfin' the web.
Please see the TSERVE.DOC file for specifics about the TSERVE program and
DON'T FORGET TO REGISTER... A lot of work went into creating this package.

See you on the web...

-Pete

[e-mail]
http://www.micro-neil.com/
telnet:bbs.micro-neil.com   (<cr> only, not <cr><lf>)