Re: PPP for accessing an embedded device (routing problem)
- From: James Carlson <james.d.carlson@xxxxxxx>
- Date: 01 Mar 2006 09:16:29 -0500
"Gingko" <nospam@xxxxxxxxxxxxxxxxxxxxxxxx> writes:
I am working on a PPP stack designed to be running on an embedded device in
order to give access to a tiny HTTP administration server.
I works now quite well, but as PPP is normally designed to access Internet
from a client machine,
No, it's not "normally designed" to do that. PPP (the protocol at
least) is a link layer protocol that can carry arbitrary network
layers.
Some *implementations* do behave as you describe. But that's an
implementation choice, not something driven by either the relevant
standards or by underlying requirements of PPP itself.
it appears that all TCP/IP request are automatically
routed through the dialup server once connected, because the client machine
normally set up its default route via this server's address.
That's a matter of routing configuration.
That means that, because of this default route setting, the client machine
no longer have access to Internet if it was previously able to use Internet
by a different method, until the PPP connection is closed. It can only
access the dialed device, "thinking" that this device is an Internet Service
Provider...
Again, this has nothing to do with PPP. You're talking about routing.
You might want to try another group, such as comp.protocols.tcp-ip,
instead.
By default, PPP with IPCP provides just a point-to-point IP link. It
does *NOT* provide access to the Internet or any other such thing.
That's a matter of IP routing configuration.
Some PPP implementations have a feature that allows them to change
routing configuration. This has nothing to do with PPP itself; it's a
convenience feature. If yours does that and isn't configurable as you
need, then complain to the vendor of that software, or get a better
implementation.
I am wondering if there is any way to have it differently configured, by
asking the dialing computer to not set the default route, and instead having
it to just set a host or a network route to the device's IP or to the device
network, so the client machine would be able to access simultaneously the
embedded server machine and any Internet access that it had before
establishing the connection.
Sure. You'll need to mention what platform you're using and what
software.
I read the RFC 1332 and RFC 1877 about IPCP negociation, but there doesn't
seem to be any configuration item inside them allowing the server to tell
the client how to configure its network routing.
Right. It has nothing to do with the protocol. This is intentional.
Of course, I know how to manually set up this routing after the connection
is established, but I expect it to be used by people with little or no
networking knowledge, so it would be great if I could set up this
transparently without asking the user to make non standard PPP
configurations, and having this working whatever kind of OS (Windows, Mac
OS, Linux ...) is used by this user.
So my question is basically : is there any way to configure the dialup
server for telling the dialing machine that he is NOT an ISP and that only a
very small segment of the global network will be handled by the dialup
server ?
No. The server side does not control the client's routing table. The
client does that. (In fact, PPP is peer-to-peer, so there is no
"client" or "server.")
But the client system _may_ opt to use suitable protocols over the PPP
link to set up the local routing (forwarding) tables as needed, and
those protocols can in fact gather the necessary information from the
other end of each link. One way to do this is to run DHCP over the
link. Another way is to run a routing protocol (such as RIP-2) to
receive the appropriate routes. Both of those mechanisms work on
links other than PPP -- this is another intentional design decision in
these protocols; they're intentionally layered so that the same
feature doesn't have to be redesigned each time a new link layer is
developed.
Again, if the client system isn't behaving as you want, then you need
to complain to that software vendor. What you're talking about isn't
really related to PPP at all.
--
James Carlson, KISS Network <james.d.carlson@xxxxxxx>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
.
- Follow-Ups:
- References:
- Prev by Date: PPP for accessing an embedded device (routing problem)
- Next by Date: Re: PPP for accessing an embedded device (routing problem)
- Previous by thread: PPP for accessing an embedded device (routing problem)
- Next by thread: Re: PPP for accessing an embedded device (routing problem)
- Index(es):
Relevant Pages
|
