VOGONS


How PPP IPX works with an ISP?

Topic actions

First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

Anyone knows how PPP negotiation(LCP, IPXCP, IPCP) works with an ISP?

I know that either side requests options from the other side. The other side can acnowledge them(OK) or Nak(different value replacement or different length required)/Reject(unnegotatable option, perform default action afaik) the parameters.

Now, what are the options negotiated (acked) used for? Are they parameters applied to the receiving of packets from the side sending the request that's acked?
So when either side receives an ack to it's sent request, it increases the identifier of it by 1 for future requests? Is it then to use said options to encode the PPP stream? And keep using defaults otherwise?
It sounds like such a request is made for sending packets only(not affecting receiving)? Is that correct? So a request packet received from the sender(side A) receiving back on side A an ack from side B(the other side) says that a connection is open for side A to send packets to side B. The same is done in reverse for side B to be able to send lower layers from side B to side A(by side B sending a request to side A and receiving an ack from side A)?

So for LCP it's pretty simple once receiving an ACK: simply apply all options in the ack to the current connections and set the LCP layer status to opened(which starts the NCP layer requests). The same for the NCP layer in that respect.

But when IPXCP or IPCP is used, exactly what is negotiated? Is it negotiating it's own address to use on a network(side A(Windows/MS-DOS), which is the dialling side, where side B is the PPP router being connected to)? If that's the case, what is the ISP negotiating exactly? The ISP doesn't exactly have stuff like username/password(PAP/CHAP) for side A(since side A requests this?) or an address on the network itself that's unique for every client(the modem that's dialing out, which is side A), or does it?

Anyone can explain this? These things don't seem to be explained anywhere I can find?

Last edited by superfury on 2021-09-05, 17:46. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've just split each and every LCP/NCP configuration option field and open/closed statuses for the PPP connection. So now I'll need to build an automaton for the server channel(which controls sending data to the client that's connected). So that means full LCP/IPXCP parsing on both sending and receiving sides need to be added for this?

Although IPXCP request-ack arriving the server side is still unknown how to use said data in the server itself? Anyone knows about this? What does the server negotiate about with the client? It's own supposedly used address? Or is this supposed to be the exact same as the client address when the server is an ISP?

Edit: Or is only the LCP request-ack done in both directions? And IPXCP/IPCP/IPv6CP only done from one side to the other (from Windows to the ISP for instance)? That would make sense, seeing as there's nothing to communicate that isn't two-way filtering during the NCP phase (nothing other than an address that's already negotiated)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 2 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

Anyone knows how the LCP starts out? Does it just begin with all supported options set? And then the options get removed by Request-Reject responses and changed (if possible) by Request-Nak responses?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 4 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++
Matth79 wrote on 2021-09-01, 19:53:

Yup. Already read through it and implemented a simple protocol for the server side to be connected from a client(serial modem for Windows) side. The same for the IPXCP protocol (which is a duplicate of it's base code with adjusted parameter lengths and some extra negotiation on the actual ethernet network (using IPX echo and echo-reply packets (with some little timeout) to detect if an IPX network/node address already exists to Nak it with the next address to try. That also should make it comparible with Dosbox clients, as they send echo replies when receiving them).
I'm just wondering how it should react and start out requesting when the LCP layer is ready for use(e.g. the PPP has a carrier(a serial modem has made an PPP connection by dialing out and logging in using plain ASCII text inputs)).
It's currently receiving LCP Configure-Request and responding with Configure-Ack(starting the lower layer for the other side), Configure-Nak(when it wants a different length or value) and Configure-Rejects all others(unknown or unsupported options).

But I notice Windows sending Configure-Request and eventually receiving back a Configure-Ack. But after that it doesn't seem to proceed to the NCP/PAP phase? It just seems to be waiting for something, eventually terminating the connection?
So I think that the server also needs to try to send Configure-Reject, handle the received Configure-Nak(by changing the options sent), Configure-Reject(by removing options sent(causing them to become defaults instead)) and accept Configure-Ack to raise the lower layers properly?

But does the IPXCP layer need to send Configure-Reject and handle the Configure-Ack/Nak/Reject as well for IPX to be active (when the client has already received a Configure-Ack for that layer from the server)? Theoretically it won't be needed, as the client needs an address etc. (for taking part in the network), but the server doesn't need to (as it can just use the client's requested address for any filtering needed) and the ISP doesn't actually have it's own address to request from the IPX client(it would be unused anyways because only the client address is used for filtering, not the server address itself)?

This is what I've got so far:
https://bitbucket.org/superfury/unipcemu/src/ … ardware/modem.c

Look for the PPP_parseSentPacketFromClient for the parsing of received packets from the client(which is Windows 95 running in Dosbox for testing. The PPP IPX layer (when properly connected) will decapsulate the packet and broadcast it over the Ethernet II network using libpcap/winpcap) and PPP_parseReceivedPacketForClient for handling receiving IPX packets on the ethernet itself (for the client(which simply sends it over the PPP link), as well as echo replies for detecting if an IPX node number/network number combination is already present and needs to be NAK-ed).

Edit: I just implemented such a simple automaton (nothing with delays or anything, other than a 0.5 second interval (after a 3 second interval when starting the PPP service phase) for the LCP configure-request packets. The configure-ack packet received with valid settings(although not checked against the request itself other than the identifier) will establish the LCP connection from server to client with the ACKed options. A configure-nak received will change the supported settings(if not containing unsupported settings in the packet) to their given values. A configure-reject received will remove the settings from further requests (thus causing them to become defaults instead).
Although currently PAP using said method isn't supported (although it is supported from client to dial-up server, but not from dial-up server to client).

I left the NCP phase unchanged, it's supposed to be only requested as far as I can find out by the client and not by the dial-up server?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 5 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmmm.... According to Windows 95, something seems to be wrong with the PPP packets that are received by the PPP server(UniPCemu's server build).

I see various requests for the PPP link to be setup being sent to the Windows 95 host, as well as Windows 95 seemingly successfully requesting LCP configure-request and receiving a configure-ack (as well as various configure-nak and configure-reject before that because of unsupported options being used), but eventually a configure-ack gets through?

Windows 95 seems to say that pretty much all frames contain CRC errors? Exactly 0 packets get through to the PPP driver apparently (according to the ppplog.txt in the windows directory)?

The log says:
CRC errors 66
Bytes received 3331
Bytes transmitted 506
Frames received 0
Frames transmitted 10

All other numbers are exactly 0.
Why would it only report CRC errors and no frames received? The frames 16-bit CRC is createn just like the CRC used to check the Windows PPP packets, which seems to not have any errors?

So my conclusion would be that there's some kind of weird issue with the PPP frames being sent from the server to the client somehow? Can anyone see if they see something wrong with that? It's the part that has the whole PPP encryption option for sending packets? Or is there a problem with the packet building itself in the packet handling function? Anyone?

Hmmm... Perhaps I should try the latest working (afaik) distribution of Linux and run PPPD in debug mode? Perhaps that can tell me what's going wrong? I think the last one working so far is Debian Bo?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 6 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. After properly configuring the linux PPP service to run properly (although disconnecting is more difficult, due to hangup issues with the disconnect script I made), I see that it sends a "LCP ConfReq id=0x1 <mru 1500> <asyncmap 0xffffffff> <auth pap> <magic 0xb87d3123> <pcomp> <accomp>". But it never seems to receive anything?

Currently I'm using the following commands:
ps -u (list of IDs for processes to kill)
sync (save buffers to disk)
tail /var/log/ppplog (list the ppp log generated)
killall -HUP pppd (hangup the ppp connection)
killall -TERM chat (forcing chat down which somehow hangs, even though its shouldn't?)

The PPP log logs various things sent, but nothing received? It says:

pppd[328]: Connection terminated.
...: Receive serial link is not 8-bit clean:
... Problem: nothing was received
char[341]: expect (HANGUP)
pppd[328]: Hangup (SIGHUP)

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 7 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. Just found 2 big bugs in this:
- The escaping of characters in the 00-20h range requested by PPP LCP was escaping the PPP END character(7Eh) instead of the actual sending data.
- LCP ACK being parsed was trying to send back some empty response, while it shouldn't even try to do such a thing(just affect the basic state machine).

With those fixes, I now actually see in the PPPD logs that it's receiving packets! 😁

Edit: Fixed some more stuff fixing the LCP ACK being received for valid parameters instead of switching valid and invalid parameters specified.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 8 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. After some more bugfixing, I now see it sending an echo-request, which gets a echo-reply back with the same data (as UniPCemu's server indeed does).

But Linux seems to not like it receiving it's own echo back somehow? Isn't that what echo-request asks for?

Although I managed to improve that, it still won't seem to somehow properly connect LCP now anymore? I see it's logging it's sending and receiving Ack packets both ways (multiple times sending towards the server, oddly enough)? The server seems to validate, but it doesn't progress to the echo anymore?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 9 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

Can anyone explain what the configure-requests mean? What exactly are those request options applied to? Is the side requesting something requesting options for sending or receiving of data?

As I've currently built it, the side that receives an ack applies those settings to how it's sending to the other side. Is that correct behaviour?

Edit: Hmmm... RFC 1661 chapter 6 says:

Unless otherwise specified, all Configuration Options apply in a
half-duplex fashion; typically, in the receive direction of the link
from the point of view of the Configure-Request sender.

So the configuration-request<-configuration-ack, the side initiating the request and receiving the ack applies those settings for receiving data, not sending data!

I've currently applied the options to be applied for index 0(client-requested) and 1(server-requested).
Although the parameters are currently used for being applied to the sending of data to the server, it's supposed to be applied to the receiving of data instead! So it's applying the settings inversed!

Edit: I do see it performing an echo-request and receiving a reply sometimes before a terminate-request followed by it receiving a terminate-ack. But most of the time it simply ends up with the receiving of the ConfAck for ID=0x1(which is the ConfReq sent at the start of the PPP connection). For some reason, the ConfReq/ConfAck get interleaved with each other? The server does have an multiple second interval before it starts sending ConfReq packets, so that shouldn't theoretically happen?

Edit: After reading the man pages for pppd(8), I've adjusted the PPP settings for proper operation of the IPX protocol (mostly in automatic mode though).

That's by adding the following to the PPP options file:
-ip-protocol
+ipx-protocol
user <username of the server here>

So that should make it work properly with the IPX protocol instead of the default IP protocol.

Still nothing after the PPP goes up though (other than some echo-request and echo-reply followed by a disconnect).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 10 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried Windows 95 again. It actually reaches the network phase (without PAP or other authentication though) and requests an IPXCP connection. But since it's IPX configuration complete (unsupported atm), the connection seems to be rejected?

Edit: Implemented the IPX configuration complete as a placeholder for now. It won't affect the connection in any way.

So now I need to implement the same as I did for the LCP portion, but for the NCP (IPXCP in this case) portion?

Edit: Just implemented IPXCP the same as LCP, but with the IPXCP parameters instead (and no address validation, as that's done by the other side).

Also adjusted the sending of the IPXCP echo-request packets for checking the IPXCP requested address to not affect the IPXCP connection itself if it doesn't succeed (using a seperate IPXCP address for checking this).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 11 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. Having implemented the IPXCP in the same way as the LCP (except waiting for IPXCP from the client first, then trying to authenticate using the client address back to the client, which is a simple little piece of code that can easily be changed), Windows 95 at least managed to dial-up to the server with PPP and just IPXCP enabled! 😁

Although I don't see it sending or receiving any IPX packets yet, as I currently don't know what software in Windows I can use to test it.

Also, the server doesn't use any PAP authentication when dialing back to the client from the server side yet. Perhaps I'll implement that later (it should be way more simple than what those other protocols used, as they're way more complicated in their messages).

Edit: Just implemented PAP support for the server-to-client PPP connection. Now both sides should be able to communicate properly (if software that's driving it is working correctly that is).

Edit: Hmmm... Perhaps Doom 95 would be enough to test it?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 12 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. Having followed the instructions at https://techgenix.com/ipxspx/ , Windows 95 now at least seems to send IPX/SPX packets over the link to the server! So now only for some reason no IPX packets are properly arriving at the client side?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 13 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

With the latest fixes, I see Windows actually sending (at least broadcasting) IPX packets on the local network and clients are receiving said packets properly it seems (checked until the PPP packets gets build, which is only a 3-byte overhead on the raw IPX packets that are sent over the ethernet). 😁

Although Windows 9X networking still doesn't seem to work?

Edit: Doom doesn't seem to do anything on the IPX network? Anyone?

Anyone knows how to get Doom running under Windows 95 with dial-up PPP with ipx?

Also, does anyone know if there's something else still needed for properly handling a PPP ISP with the IPX protocol?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 14 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've just adjusted the packet server to keep active packet server connections in a doubly linked list (just like the CPU's TLBs). That also should decrease most loops used on any connected clients each ticking clock cycle of the server's handling (it's at a 56K rate).

So if only 1 or 2 clients are connected, only 1 or 2 are actually processed (the remainder ignored). That also improves registration time almost infinitely (as it doesn't need to loop at all searching for available clients). That's basically a simple if-else instead of a loop.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 15 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. Windows 95 connects to the server using PPP and displays it's successfully negotiated the IPX and IP protocols.

But when looking at the dial-up information using winipcfg, it displays the server's requested gateway as being empty? Looking inside the TCP/IP configuration in the control panel displays the default gateway I've added that's indeed correct?

Why wont Windows 95 properly detect the default gateway from the server? Windows negotiates with it and clearly ACKs the server-given IP address setting (the option number 3, which is the server-specified data)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 16 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

Slightly related: just fixed the PPP and IPv4 ARP responses to behave properly. It seems that it's actually receiving the IPv4 packets again at least.
But according to Windows 95 itself, I don't see it sending any reponses?

On the other hand, looking at the packets being sent to the client seems to be the case.

Perhaps there's some checksum issues there? Windows 10 sends with a checksum of 0 (according to Microsoft Network Monitor I use to monitor it's traffic). The client sends packets (only when pinging) with a valid checksum (non-zero).

The weird thing is that even with PPP used, the remote server (UniPCemu when UniPCemu connected with Dosbox Windows 95) sends a request for the actual router's address and receives an exact ACK for it. But the default gateway on the Windows 95 machine reports it's own requested IP address? The same for the default gateway in it's routing tables.

Looking at Windows 95's PPPLOG.TXT file inside the Windows folder, I actually see it's receiving a IPCP request from the server with it's gateway IP address. It sends back an IPCP ACK message for that.

So the server is actually reporting the IP address, but Windows isn't using it for some reason?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 17 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've managed to get two different Windows 95 clients trying to speak to each other now.
I installed TCPDump and WinPcap 3.1 on it (afaik the last version for Windows 95).

Looking at what it's reporting, both clients seem to see the packets sent and received most of the time?
When I let one of the two run ping on the other, I see the request being responded most of the time.
But sometimes one or the other completely starts to stop receiving anything anymore?

I also see one of the two clients running IPX server commands on the line, with only one of the two clients responding to it (the first one that connects)?
Still no connectivity using normal IP address conversation though (using a \\othername address in the run prompt and "Entire network" in the networking window)?

It looks like the second client becomes completely silent and non-receiving according to TCPdump on it? After one or two pings from the other machine? It shouldn't become radio silent like that?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 18 of 23, by superfury

User metadata
Rank l33t++
Rank
l33t++

Looking at the weird packets I see Windows 95 sending when configured for Ethernet II packets is the following:

00616e01c68e.4006
00616e029f6c.0452 (> self)
00616e029f6c.4006

04 source network broadcast addr 0452 0001.00616e01c68e 0452
ff ff 00 22 00 11 destination network destination addr 0452 source network source addr ...
00 60 00 04 "
11 "
00 22 00 11 "
ff 00 22 00 11 start of packet addresses
22 00 04 start of packet "
00 04 start of packet "
00 22 00 04 "
ff ff 00 22 00 04 "
ff ff 00 46 00 04 "
ff ff 00 60 00 04 "
ff 00 66 00 14 "
66 00 14 "
14 "
00 66 00 14 "
ff 00 00 66 00 14 "
ff 00 46 00 04 "
00 14 "
ff 00 66 00 14 "
ff ff 00 66 00 14 "
00 11 "
ff ff 00 66 00 04 "

Can anyone shed any light on what's happening here? What weird protocol is that?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io