Re: PPP for accessing an embedded device (routing problem)

"Gingko" <nospam@xxxxxxxxxxxxxxxxxxxxxxxx> writes:
Sure. You'll need to mention what platform you're using and what
software.


Very simple.
The dialed server is made by myself (actually derived from Zilog's ZTP), and
the dialing clients should be any Internet enabled computer, but very likely
a vast majority of Windows XP, 2000, NT or 98 systems.

In that case, the vendor you want to contact is Microsoft.

Even if it is not part of the PPP specifications, it looks like that almost
all common implementations use to build a default route to the dialed peer
after establishing the connection, and this is certainly necessary for this
very common use of PPP : creating an Internet connection through a telephone
line. I understand that this is not part of PPP, but it is certainly very
commonly associated to it.

Indeed; I believe Windows does that by default. You'll probably need
to read through Microsoft's documentation to figure out how to change
its behavior.

I just expect having my users to use their common (if not standard)
installations for accessing my devices like if they have to connect to
Internet through (in most of the cases) a telephone line. These users will
be using the computer that they already own, and will not buy another one
(and should not have to install some particular extension) just for making
these specific connections. I expect them to use the resources they already
have.

It seems like a reasonable expectation to me. It'd certainly be easy
to do on a UNIX-based system. I don't know whether those particular
clients you've decided to support can live up that expectation,
though. It's something you'll have to work out with them.

Or try a newsgroup that's dedicated to Windows-related issues. That's
where the problem is; it has nothing to do with PPP.

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.")


Ok ... But when establishing a PPP connection, there is at least one end
initiating the connection and the other receiving the request.
Thus I call them (maybe improperly) "client" for the first one, and "server"
for the second one.

Not necessarily. PPP is also used on nailed-up leased lines, where
neither end does any "initiating."

I agree that it's fairly common to refer to the two endpoints the way
you are, but it's also technically incorrect, and it's important to
understand that PPP in fact establishes a connection between two
peers, not between a "client" and "server."

Ok ... Is it possible to do this on a basic Windows XP machine with no
specific extensions ?

No idea. You'll probably want to consult the Windows documentation
and/or newsgroups related to Windows.

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.


Do you really think that I could complain to Microsoft for having them
changing all of their already sold Windows PPP implementations in order to
met my very tiny needs ? :-) :-) :-)

Yes. Or, rather, it's one of only a few rational choices I can
imagine. The others include telling those uses to get better, more
capable operating systems.

At least to me, I think there's little reason to waste a great deal of
time trying to support something that isn't designed to do what you
need to do. It's like using a crescent wrench to drive in a nail.
Sure, you can probably manage to do it, but it'll be harder and you'll
probably also make a mess of things in the process.

By the way, the IPCP extensions (see RFC 1877) seem to have mostly been
added in order to allow the settings for the DNS servers needed on the
established links. I am wondering if this really had to be included in the
PPP specifications if PPP was only intended to establish a simple TCP/IP
link ....

Read RFC 1877 carefully. It's a Microsoft hack. It's listed as
"Informational" (not standards-track) because it was not a product of
the standards process.

In fact, it's a mistake. Both DHCP and BOOTP do everything that it
does, and more, and do it better, and work fine on PPP, and in fact
were in common use on both SLIP and PPP links before Microsoft ever
started working on that "extension." There's no good reason for it.

The fact that there's no v6 counterpart nor extension for other
application layer details is due in no small part to the realization
that 1877 was a mistake.

--
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
.

Relevant Pages

  • Re: Serious Security Issue in Windows XP SP2s Firewall
    ... Subject: AW: Serious Security Issue in Windows XP SP2's Firewall ... If you update a WinXP SP-1 with enabled Internet ... Connection Firewall ...
    (Focus-Microsoft)
  • Re: Internet Connection Delays
    ... >> I use Windows XP Pro with SP2 installed, AMD Duron Processor, ... >> have to wait 90 seconds to connect to the internet after my ... >> delete internet connection ... > I have found problems with some applications, relating to DEP. ...
    (microsoft.public.windowsxp.help_and_support)
  • Serious Security Issue in Windows XP SP2s Firewall
    ... PC-WELT discovers and fixes serious security issue in Windows XP SP2 ... Internet via dial-up or ISDN. ... Internet Connection Sharing of the PC ... network at home: Often, we did not even encounter password protection. ...
    (Bugtraq)
  • Re: Big hole??
    ... supposedly safe SP2 for Windows XP invites any Internet ... Connection Sharing of the PC has to be disabled. ... visible in their network at home: ...
    (microsoft.public.windowsxp.general)
  • Re: Wireless network issue for two SP2 computers
    ... with DSL Internet ... When I pull up view network computers, when I try to add network ... >The LAN connection also has TCP/IP, with Client for MS Networks, QoS Packet ... If the computers run the original or SP1 versions of Windows XP, ...
    (microsoft.public.windowsxp.network_web)
Loading