Just tried the Linux (Debian Bo) inside another UniPCemu session again. It can dial out to the ISP and reaches the IPCP network stage (although the server rejects it because it's still unsupported), but the server side gets stuck at the PAP stage?
The server requests PAP from Linux(using a authentication-request packet). Linux however never sends any reply back to the client?

Windows 95 does send replies though(Authorization-Ack).

Edit: Much improved the handling now. Many bugfixes and improvements, including actual Protocol-Reject handling for the server side (sent by the client). Although Terminate-Ack isn't handled because the server will never send Request-Terminate itself (it leaves that to the peer).
I've also just fixed a small bug where the IPX Routing Protocol was the wrong size (which I found out by examining the final failing Protocol-Reject packet and finding out the size didn't seem to match the contents of said packet. That was obviously a server-side bug, not a client-side bug like Windows 95's corrupted IPX packet sending.

Just tried something. Uninstalled the dial-up networking I installed previously. Installed the DUN 1.4 update for Windows 95.

That seems to have done the trick. Now it dials up correctly again and I actually see it sending/receiving IPX packets over the network 😁

Managed to improve the server quite a lot. Lots of bugfixes in the LCP/PAP/IPXCP protocols (I even had the PAP authentication backwards, thinking it was negotiating authentication to the peer instead of the other way around (makes sense though: a server(the packet server) needs credentials from the client and asks for it to give them after LCP is setup)).

Now PAP works properly with Windows 95. I see it's sending at least some IPX packets on the network, but nothing much more is currently done.

Also, I've added a little new function to the login part of the server. If it finds one of the 3 patterns arriving when waiting for the user to provide login information (to be exact, the moment it reaches the input phase for entering the username). It will then scan the first 5/6/7 character bytes the client sent. If they match the defined PPP packet starts, PPP is immediately assumed and started. Although it has a different method of performing PAP authentication:
- When the client logs in normally without PPP packets, the login username and password, which are already validated, are used as the supposed login credentials. It will simply compare them(as they're also validated before PPP starts by logging in) to the PPP supplied credentials. If they match, login is successfull.
- When the client logs in with PPP only (never doing the text mode (SCP scripted method) login), it will perform a lookup to all possible users and validate their credentials against the PPP-requested credentials. If any of them match, the login is successfull. And of course in both cases, the credentials are left for record (cleared when PPP login fails with PAP, as they're loaded by the search algorithm which compares login credentials against the username/password using it in the emulator's settings).

Windows still sends corrupted packets, though? UniPCemu's server build finds that lots of 'packets' arrive outside the PPP packets? Those seem like IPX packets, looking at their contents?

OK. So the address and network number that the client requests using a IPXCP request packet(and receiving an ACK for it) is the address of the client connected to the PPP server.

Now, can anyone tell me exactly what the address that the PPP server requests from the 'client' is? What is that address used for?

Edit: Just tried lsppp as well again. It's saying:
"Connecting to network...Authenticating...Negotiating IP linkage..."
Then nothing.

I've just started to implement IPv4 IPCP into the server. It will simply handle sending both type requests in a russian roulette-ish handling. So that prevents one protocol from being spammed while the other is still pending.

It starts out by defaulting to spin to the next protocol type. If any protocol tries to go and request but can't yet, the spinner is halted until the request is sent. Otherwise, the spinner continues to try the next protocol.

This of course makes the spinner perform nothing when both protocols are rejected or acknowledged.

In that way, even if the timers for both protocols trigger at the same time, the spinning causes them to both get a chance to send their protocol request from server t0 client.

Still need to implement the receiver(from client to server) part of the IPCP and it's options though(copying and adjusting IPXCP for the protocol).

Now I've added the PPP IPv4 protocol (IPCP and packet handling on the network) to the server. So now (at least theoretically), all base options for networking should be covered (although IPCP and TCP/IP over PPP isn't tested yet).

Looking at PPPD's IPCP's handling of the options the server 'requests' an address from the client, it seems to setup a default route from that acnowledge somewhere? Anyone knows what IPLOCAL does?

Just improved the pcap handling a bit. It now allows the packet server itself to not use pcap itself (even if installed and loaded), instead running an internal loopback. Normally the ethernetcard setting is set to 0 for pcap card detection logging, >0 for selecting a compatible network card to use and -1 (or lower) for disabling the usage of a network card (together with the packet server) entirely.

Now the new option added is -2, where the packet server and pcap handling will be running in loopback mode. That should make it available to use without using any network card (although pcap is still loading in this case, but simply unused for any traffic).

So it's now:
-2: loopback mode packet server (pcap still loaded but not used or required).
-1: packet server disabled (and pcap not required)
0: log pcap device numbers to use
>0: specify an ethernet-compatible 10/100/1000+mB device to use

So in loopback mode, the mac address of the router used normally is replaced by the local mac address (causing everything sent by the server to also be received by the server). Since all clients receive this as normal using this way, pretty much an in-emulator local network is setup.

So computers inside said network can send packets to each other (although sending packets is never failing, receiving of packets depends on whether a client can receive the packet during the next server clock ticked (otherwise, it's discarded, just as with a normal pcap-based connection).

A nice point of being able to put the server's network into loopback mode now is that you can use it to test the server without any compatible network card (for example some/all WiFi network cards) or simply make it a local network when you don't want to or can't use the real network for it.

In my case, pcap can't use the real network card (it's a WiFi card) on one of my developing laptops, but if I can put the packet server's pcap interface into loopback mode (which it can now), the connected clients should be able to still talk to each other using the server (although the internet or any real devices can't be reached because of this). It should also suffice to be able to test the server itself in this case.

Another improvement that I've made now is that the pcap receive handler now runs inside it's own seperate thread. That allows it to much more accurately receive packets that arrive between server ticks. Although the processing and receiving of packets per tick is still limited to only 1 packet (all others are effectively discarded because the pcap interface can't receive them between ticks if the receive buffer is full and a compatible packet is received (causing the double-buffer to get completely filled, making the interface not receive anything on the pcap interface anymore until there's room).

I've just given up trying to run WIndows 95 with a working serial port under Dosbox on my laptop. All kind of weird errors pop up there:
- It can't mount the disk image itself.
- The disk image is mounted and it gives one of the boot loader errors ("Error loading operating system" or "Operating system not found").
- Windows 95 boots but keeps crashing all kinds of apps (including explorer.exe)
- The serial port with a serial modem is detected (the port itself) but it can't detect the modem at all, thus can't dial out or anything.

Guess I'll have to run Windows 95 inside UniPCemu instead (since Bochs doesn't have a serial dial-up modem like Dosbox/UniPCemu has).

superfury wrote on 2020-01-08, 21:53:

Can IPX be encoded using SLIP anyways(like TCP/IP), then just sent/received to/from the router/network broadcast using pcap(by adding the ethernet frame around it)? So archieving IPX without PPP(which seems pretty difficult to implement), using SLIP instead?

I managed to do a setup where DOSBOX can access the internet via DOS TCP/IP over a SLIP based packet driver. For IPX, you could load the appropiate dos drivers on top of the packet driver (I think Microsoft NDIS or ODI would help you there).

Except that my setup uses Linux as the host OS and it follows the DOSBOX networking how-to guide.

Basically, I use socat to create a server (ipV4 address) which translates to a port. Then I use slattach to convert that port to a special ethernet card device with a name starting with sl, then I use iptables to create a NAT masquerade so accessing special defined private IP addresses in DOSBOX can translate to the IP addresses on your real internet card. Then I modify dosbox configuration to assign a serial port to match the server address and port and include in my autoexec section of dosbox config the ETHERSL.COM (I think thats the name) utility with the correct serial port parameters.

See: https://www.dosbox.com/wiki/Slip_configuration_on_linux_host for example commands and even a unix script that shows how its done.

Then again I think DOSBOX has special IPX functionality already built-in.

P.S. I wish I could find such utilities for Windows 64-bit then I could make my commit driver for duke nukem work for new Windows, and not limit it to just 32-bit machines and dos only.

mike_canada wrote on 2021-09-12, 05:00:

I managed to do a setup where DOSBOX can access the internet via DOS TCP/IP over a SLIP based packet driver. For IPX, you could […]
Show full quote

superfury wrote on 2020-01-08, 21:53:

Can IPX be encoded using SLIP anyways(like TCP/IP), then just sent/received to/from the router/network broadcast using pcap(by adding the ethernet frame around it)? So archieving IPX without PPP(which seems pretty difficult to implement), using SLIP instead?

I managed to do a setup where DOSBOX can access the internet via DOS TCP/IP over a SLIP based packet driver. For IPX, you could load the appropiate dos drivers on top of the packet driver (I think Microsoft NDIS or ODI would help you there).

Except that my setup uses Linux as the host OS and it follows the DOSBOX networking how-to guide.

Basically, I use socat to create a server (ipV4 address) which translates to a port. Then I use slattach to convert that port to a special ethernet card device with a name starting with sl, then I use iptables to create a NAT masquerade so accessing special defined private IP addresses in DOSBOX can translate to the IP addresses on your real internet card. Then I modify dosbox configuration to assign a serial port to match the server address and port and include in my autoexec section of dosbox config the ETHERSL.COM (I think thats the name) utility with the correct serial port parameters.

See: https://www.dosbox.com/wiki/Slip_configuration_on_linux_host for example commands and even a unix script that shows how its done.

Then again I think DOSBOX has special IPX functionality already built-in.

P.S. I wish I could find such utilities for Windows 64-bit then I could make my commit driver for duke nukem work for new Windows, and not limit it to just 32-bit machines and dos only.

What I mean is how to setup MS-DOS (real MS-DOS, not Dosbox DOS) to use IPX over PPP. I assume I'd have to load a PPP driver and the IPX driver next, but I don't know of any PPP drivers that support that (other than Windows 9x's own drivers when Windows is loaded). Anyone knows how to do that in pure MS-DOS?
All PPP drivers I can find only seem to support IP and not IPX?

Edit: Windows 95 running Doom 95 now actually works with the latest fixes and improvements! Although TCP/IP has some difficulty over PPP in Windows 95? (Arachne under MS-DOS using EPPPD runs fine)

Hello from Dosbox
running Arachne
connected using
EPPPD to UniPCemu
server using the
PPP protocol!
Sadly, still no
Windows 95
connectivity yet
for IPv4, but IPX
is apparently
working there.
MS-DOS seems to
run fine, though!

Anyone knows exactly why people say that to use TCP/IP on PPP, you'll need to disable the IPX/SPX? Is it because of some bug? Or simply because dial-up servers don't support IPX/SPX?

Seeing as at least TCP/IP doesn't work with both enabled atm. And MS-DOS (Arachne) which uses only TCP/IP works fine. Windows fails with the combination of the two(but IPX/SPX seems to run fine, allowing multiplayer Doom 95)?

Edit: Is it just because of this?

Just modified the packet server clients to get two buffers on their incoming packets. One for IPv4 packets and one for other types (PPPOE, IPX (,ARP which is currently unused as it's handled directly without local buffers)).

Both buffers are filled using the same condition as previously by the Pcap thread (all clients in one go from one packet per type to the clients' receiver buffers to send). And the pcap thread will wait for all those receiving buffers to clear before filling up the packet to send to all clients (filtered) after it clears.

Now, originally this was done with each packet accepted by the pcap thread to go to every client's packet buffer. But now the packet buffer of both the clients and pcap thread is split in two. The pcap thread will fill one of the two buffers (depending on the packet type) with the packet that's the specified type (IPv4 or other). And the main thread will see that a packet is queued in one or both of those buffers and if it finds it is buffered, it will transfer those buffers to their respective IPv4 or other buffers(the original buffer variable) for all clients.

Then all clients simply process their buffers twice: once for the other buffer, once for the IPv4 buffer. Exactly the same code is ran for both buffers (done using a simple goto based on a flipflop and if statements with checks if the first processed has been reached again (which happens when both clients buffers are idling about)). Otherwise, the flipflop will keep toggling each time a packet is parsed and received by a client, causing the client to alternate between the two packet types if both are buffered at the same time.

This is exactly the same round robin style used for sending PPP IPXCP request and IPCP request packets to the client (but they are based on timers expiring (and resetting upon starting to send it to the client) instead of buffers being filled).

Edit: After fixing the problems with the new round robin style of IPX vs IP packets alternating (~50% bandwidth each), Dosbox connected to UniPCemu seems to run fine, browsing the internet and running Doom multiplayer IPX, both over the serial dial-up connection! 😁 The speed isn't half bad (besides somehow the window with Doom blacking out on every movement) on 56K?
Edit: Just implemented subnet mask handling for subnet mask 0.0.0.0(force either local or host network local ARP). And 255.255.255.255 always sends when not the client's own IP to the default route, otherwise clients own MAC.