Hmmm.... Does anyone know how to calculate the PPP HDLC CRC? Is it calculated over the entire frame (minus frame delimiters(0x7D))? Or is it just calculated over the info field (the payload)?
Edit: Nvm. Found out how to calculate it. It seems to be calculated much the same way as a normal 32-bit CRC, but in 16-bit format instead (CRC16?)?

OK. So the PPP connection needs the LCP protocol for the PPP connection itself to be established and IPXCP for the IPX connection itself t0 be established afterwards? Would that be correct?

Just finished implementing PPP with the LCP protocol (although with minimal options, the only valid options being the compression settings). So it should at least be able to open and close it now, together with the various Ack and Nac results being sent back as far as I can understand the documentation.
Now I still need to copy and adjust the LCP protocol code to the IPXCP code. And of course after that implement the basic IPX routing itself, which should be relatively easier(some filters afaik, but that'll have to wait until I get to the IPX protocol after the IPXCP code is implemented).
The LCP is currently pretty much a 2-state machine(either closed or open). Stuff like authentication protocols (PAP?) aren't implemented. Are they mandatory, though?

Just implemented the missing LCP Echo-Request to give a proper Echo-Reply(if the Magic-number option (also added) is set for the Opened LCP connection).
Also fixed some bugs regarding cleanup of dynamically allocated buffers (for the LCP Configure-Request).

Just implemented the IPXCP packets as well, although without valid options yet(the list of options is commented out for later implementation) and without proper nak/reject packets being sent yet(still TODO).

Although it's still unknown if I need to implement at least the PAP protocol? Can it also run without those authentication protocols(by Rejecting the security protocol option field, as it does right now during a LCP configure-request)?

Also, when rejecting/nak a configure-request, it'll send both of those packets if both apply to the same request(configure request->nak&reject). Would that be correct behaviour? Or is there some unmentioned priority going on those(reject, otherwise nak?).

OK. Just simply implemented the PAP protocol as well. So now only the IPXCP protocol has to be finished (it's option fields) and then the actual IPX handling needs to be added for sending and receiving packets(with filtering on receiving) through the Ethernet protocol that's already there.

Just finished the IPXCP protocol with it's minimal option fields required as far as I know.

Then proceeded to implement the IPX packet sending and receiving on the PPP link, which was relatively easy (although the IPX packets are sent on the ethernet using a simple broadcast).

Then other programs like this one (https://github.com/jsalin/ipxgw/ , although it needs a bit of extra logic for the filtering and sending over the ethernet II frames using protocol 0x8137) can route it into other software, like Dosbox.

Although, UniPCemu packet servers can communicate to each other using this protocol without known issue.

Still got the issue how to handle the packet filtering for receiving packets though (with IPv4 it's clear. With the IPX protocol I don't know exactly how to do this yet).

After various bug fixes, UniPCemu now receives proper PPP packets and seems to decode them correctly.

But somehow, the response isn't received or liked by the LSPPP/PPPD clients, which keeps complaining that the driver is down or "LCP: Can't establish connection" for the case of LSPPP?

Is there some open-source PPP(/IPX) packet driver out there that can tell me what's going wrong?

Hmmm.... Looking at the LSPPP.LOG generated when running "LSPPP /z" (according to http://macall.net/ladsoft/index.htm) after establishing a dial-up connection with the UniPCemu server, I see it list a lot of send packets (which seem correct), but no "recv" is ever logged? When looking with a binary editor I do see the send and recv strings right beside each other, so both should be supported by the logging method.

So it somehow isn't receiving any PPP packets from the server at all? That's weird?

OK. When Windows 95 tries to connect to the server in PPP mode, it seems to recognise that the LCP connection at least has been setup (since it sends a terminate-request when I try to disconnect while it's stuck in it's "Verifying user name and password..." phase of dialing)?

So why isn't it using the network layer protocols as PPP calls it? It simply stops sending PPP packets to the packet server?
Edit: OK. C:\Windows\System\ppplog.txt says (after terminating the connection) "CRC Errors 4", 1 frame received, 5 frames transmitted.
So somehow, perhaps the response CRC is incorrect somehow?

Edit: Can anyone see what's going wrong there?
It's at https://bitbucket.org/superfury/unipcemu/src/ … ardware/modem.c , function PPP_parseSentPacketFromClient.

Why is Windows rejecting those responses? The FCS and packets themselves seem to check out without issues when parsed by that function, but the response doesn't seem to be fine according to Windows 95 (running in Dosbox-X)?

Hi!
http://dukertcm.com/knowledge-base/downloads- … tiplay-drivers/

Pipx v1.00 Test Drive Release
Parallel Technologies, Inc. 84 Parallel-port IPX driver: play Quake (or any IPX network game) over parallel ports: works perfectly with Quake and Duke Nukem 3D.

Hmmm... Do both ends of the PPP connection(both server and client) need to send a configure-request and receive a configure-ack for Windows to consider starting the lower layer (PAP(if used), followed by NCP(IPCP, IPXCP) or network layer(IPX, IPv4, IPv6))?
Currently the server only replies to the configure-request and doesn't send configure-request packets or acknowledges configure-ack packets that are received. Does it need to do that for Windows to consider the lower-layer protocols to be used?

It's currently still hanging after receiving the LCP configure-ack to a LCP conf8gure-request(Identification 01h).

A simple question: what packets need to be sent and/or received at the server side of a PPP connection for the client(Windows) to proceed to the next phase?

So does the server that's being dialed through a PPP connection on a dial-up modem need to send a configure-request and receive a configure-ack from the Windows client before the lower layers become active (for example IPXCP)? Or would it simply need to sort of echo the configure-ack response's parameters into a configure-request and receive a configure-ack for that before proceeding to the next phase?
And of course the same thing needs to happen for the lower layers (IPXCP in this case) as well(so both ends receive a IPXCP request-ack to start sending the lower IPX layers)?

Anyone knows why Windows 95 keeps reporting CRC errors? Is that Dosbox's fault or are the PPP packets' CRC fields or contents somehow incorrect?

Does anyone know how an ISP requests an PPP LCP/IPXCP connection from the server side(the Windows/Arachne client being the client side)?

Does it wait for the appropriate request-ack packet to be sent to the client and then use the same information to formulate a request for the sending of lower-layer PPP protocols to the client(until reaching the IPXCP connection established)? Are the options for LCP and PAP/IPXCP from the server side to the client PPP request/ack negotiation taken from what the client requests first, or are those entirely defaulted(with server-supported settings that are removed and/or adjusted by the server receiving a nak/reject LCP/IPXCP packet)?
What happens to required fields for authentication etc. when not supplied as option fields? Are they simply request-NAKed into the next request by the client(as UniPCemu's server does right now for such fields when missing)?

Managed to at least figure out how the PPP protocols are supposed to work. There is another thread already (one of them becoming the new active conversation about all this, merging this all into them , so I'm stopping to listen to this thread. Consider it closed.

The thread I'm merging this conversation to is: How PPP IPX works with an ISP?