Well, UniPCemu has a server build which emulates an ISP with SLIP protocol that can be connected to on a TCP port(theoretically multiuser, practical it's still having trouble with 2+ simultaneous users due to unknown reason(and the current released version has a TCP disconnect bug(already fixed in git repo, applies to all UniPCemu release builds)).

It starts out with some plain ASCII for login(username,password(response is *-masked), protocol(username/password only when enabled(set) in the settings file), then switches to SLIP after saying CONNECTED(and 0.3 second delay before it switches to SLIP packet mode). Invalid credentials/protocol will make it terminate the TCP connection(hang up).

Edit: Thinking about it, IPX won't work(as it's not a IPv4 wrapped or encoded packet), but TCP/IP(TCP wrapped inside IPv4) should work(the server uses IPv4 headers to encode/decode and filter the packets for the connected clients(currently all use the same IPv4 filter, unless a specific IP address is assigned to different users instead of the (empty) default one(the very first, required, IPaddress field)). And of course SLIP encoding is used to receive/transfer the IPv4 packets to/from the connected clients.

Hmmm... SLIP is only for IP anyways, not UPX:
https://www.cisco.com/en/US/docs/ios/11_0/acc … ide/acslip.html

Configure Transport-Layer Protocols over SLIP and PPP
You can configure transport-layer protocols, such as AppleTalk, IP, and IPX, over SLIP and PPP. SLIP supports only IP, while PPP supports each of these protocols. Refer to the sections that follow to configure these protocols over SLIP and PPP.

superfury wrote on 2020-01-08, 07:56:

Hmmm... SLIP is only for IP anyways, not UPX:
https://www.cisco.com/en/US/docs/ios/11_0/acc … ide/acslip.html

Configure Transport-Layer Protocols over SLIP and PPP
You can configure transport-layer protocols, such as AppleTalk, IP, and IPX, over SLIP and PPP. SLIP supports only IP, while PPP supports each of these protocols. Refer to the sections that follow to configure these protocols over SLIP and PPP.

That makes me wonder - what about X.25 emulation, more precisely, a PAD* login system ? 😉
(*In German Datex-P, that was a computer system that connected incomming callers with terminals from landline to the wordwide X.25 network)
I know this is slightly off-topic, but some popular online services like CompuServe used X.25 originally.

https://en.wikipedia.org/wiki/X.25
https://en.wikipedia.org/wiki/CompuServe

Edit: Never mind. Got further information.
That network type was called "Packet Switched Public Data Network = PSPDN"
http://fitxers.oriolrius.cat/1718/x25tcpip.html
Datex-P: shutdown after almost 40 years - A data service disappears

Edit: Found some more information. Still looking for emulation projects.
I know there was something similar, like a mainframe emulation for Minitel/BTX/Videotex. ^^
A Guide to X.25 in Computer Networking

Edit: Found it. That project was called "RetroNet".
https://wiki.retrocomp.net/index.php/Main_Page

Also, found some mainframe emulation projects for Minitel systems.
https://en.wikipedia.org/wiki/Minitel
https://medium.com/@cq94/get-your-minitels-ba … ck-1d8c42f1ea17
https://github.com/bildschirmtext/bildschirmtext
http://runningserver.com/?page=rs.thelab.minibtx

It makes me wonder, though. UniPCemu uses (win)pcap as a method of transferring TCP/IP packets over the network for the connected client, can the same be done with IPX encapsulated/encoded in SLIP? Perhaps just a different ethernet header to use(replacing the IPv4 type with some kind of UPX type)?

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? Will software (in Dosbox/UniPCemu etc.) allow such a combination(SLIP+IPX instead of PPP+IPX)? And can IPX be sent/received on a modern network easily using the ethernet layer addition?

Edit: Hmmm... At least on the pcap side of UniPCemu, it should be possible:
https://en.m.wikipedia.org/wiki/Internetwork_Packet_Exchange
Just replace the Ethernet II frame header's EtherType field with 0x8137 as the ID instead of the current 0x0800 as is used with UniPCemu's current slip protocol.

I am wondering about filtering, though. The IPv4 packets are filtered by IP and/or MAC address(allowing packets of all broadcasts and IP of the user that's logged in(or default) only to be sent to the client). Does IPX need filtering in the same way, or does it just need to pass all IPX packets to all users?

Hmmmm... That only leaves the problem of packet encapsulation over the TCP port. Can SLIP be used instead of PPP to encapsulate it(just using a different protocol during login("ipxslip" instead of the current(only atm) "slip")?
Does software allow custom login scripts etc. for IPX with SLIP and manual/custom text input before the IPX packets(like Windows 95 scripts and Arachne's dialer)?

Edit: Just implemented a "ipxslip" protocol in UniPCemu(it's in it's git repository now). It encodes IPX over SLIP when selecting the protocol(instead of just choosing plain "slip" when asked during authentication). It will ignore it's IPv4-based IP address filter(as they aren't IPv4 packets) and otherwise behave the same(except for the EtherType field) as the normal "slip" method, except no filters(other than the MAC address of the host card(in the settings) and the MAC address of the destination(which when sending is always the router's MAC address). The IPX packet itself is encapsulated in a Ethernet II frame and otherwise unmodified when sent. And it strips the Ethernet II header (without any filtering other than EtherType and MAC address in then Ethernet II header) off for the SLIP packet to send to the connected client.

Would that be correct behaviour? All clients receive all IPX packets received from anyone(to a broadcast MAC and to our own MAC address)?

CoTeCiO wrote on 2020-01-08, 07:20:

I want to emulate a dial up modem connection over TCP/IP (or UDP, I'm not very clear about network terminology) so I can play multiplayer games using that method.

Are you aware that DOSBox does this already?

If DOSBox is no good, then what are you looking for? Something that will work in DOS natively?

Just, after some searching, found http://theory.cs.uni-bonn.de/ppp/rfc/rfc1662.txt . It's the first I actually find that explains the PPP escape sequence properly(like SLIP's escaping, but using a XOR'ed value on bit 5 instead of the escaped value). That should be easy to implement, although I'll have to dig deeper into the protocol for proper PPP to/from Ethernet II frame conversion(if required).

So 0x7E is PPP_END essentially, while PPP_ESC is 0x7D. And following PPP_ESC IS (val XOR 0x20), both used for encoding and decoding.

Edit: Just implemented said functionality as a ppp protocol in UniPCemu's server git repository. The only issue with it is that atm I don't know how to move the PPP packets to(inject) and extract them from the ethernet II packets. Anyone knows more about that?
In effect that means that it will atm just discard and not send or receive any PPP packets on the ethernet side of things(the client just doesn't receive any packets(received packets are discarded by the filter), while packets that are sent are simply gobbled up(from their TCP receive buffers, although parsed) and discarded(no sending functionality for them yet)).

Edit: Hmmm... https://sites.google.com/site/amitsciscozone/ … p-over-ethernet
So EtherType 0x8863 for some discovery packets and EtherType 0x8864. But how to know which of the two to use when sending/receiving packets? Receiving has them already(ready made because it's a received packet), so just send encoded to the client without distinction?
But what about sent packets from the client? How would it know which of the two EtherTypes to use for such a packet?

Edit: Hmmmm...
https://tools.ietf.org/html/rfc2516

Is the discovery part done by the client or is the server supposed to do that when a client connects/disconnects?

Edit: So probably, the server is supposed to do the 4-step channel request and termination handling(after authentication in text mode).
But what about the PPP packets themselves? UniPCemu now decodes and encodes them(parsing the escapes into the send buffer/receive buffer to/from the client).
Are the packets in the Ethernet II frame(type 0x8864) decoded ones or encoded ones? Does it need to re-encode them for putting them inside the type 0x8864 packet(and the reverse for receiving)? Or is it supposed to send the raw unencoded ones one by one?

Edit: Just finished implementing it, with unencoded packets being sent/received over the PPPOE type 0x8864 frames.

Edit: I've just added some missing functionality:
- Implemented sending the PADT packet when the client is disconnected on the TCP connection.
- Implemented unencoded transfers over the PPP connection(previously it was decoding it on receive before passing it through to the ethernet layer instead of keeping it in the same form). The reverse applied when sending packets from the Ethernet to the client.
- Added checks and protection against sending/receiving 2+ following PPP END characters(the 0x7E ones), preventing 0x7E7E from appearing in the data stream to/from the client to the PPPOE server.
- Improved handling of all PAD packets to not propogate through all clients(causing e.g. multiple clients to accept the same Session_ID when simultaneously waiting for their PADS packets).
- Implemented automatic reconnecting using a PADT packet(and the following packets until PADS) when a client is still connected, has received a PADT packet(the PPPOE server requesting a termination of the connection) and the client tries to start to send a new packet.
- Added a modemconnect.ppp.scp file (and renamed the old file to modemconnect.slip.scp) for connecting using the new PPP connection support.
Edit: Just a tiny bugfix: don't send the IPaddress information text(specifying an IP address to use for the client) when using the PPP protocol, as the PPP protocol will do that itself. 🤣

OK. After some first testing the new version, I noticed an infinite loop happening when a client connects, causing the server to hang up the application. Whoops! Now fixed, though(SLIP so far confirmed working correctly again).

Edit: OK. Confirmed it's actually sending the PADT packet and receiving it back(due to the packet being broadcast). But it never sees any PADO packet being received, thus never continuing on?

Perhaps there's no server that's handling the PPPOE packets? Is there a way to make windows implement a PPPOE packet server?

OK. Managed to check the packet that's sent(the PADI packet) with Microsoft Network Monitor. The packet itself looks fine and looks like it has no errors.

But there doesn't seem to be any PPPOE server responding to it, thus it will never authenticate further(and the login process on the server will never send a CONNECTED\r\n message to the client, because the PPPOE connection isn't fully setup yet. Is there supposed to be a timeout for that kind of thing(the PPPOE Discovery stage)?

Also, if the modem itself doesn't support PPPOE, can OSes like Windows or Linux support it somehow instead(and respond to the PPPOE packets)?

So far have been trying to use ARPminer to create a PPPOE server for UniPCemu to connect to, but it won't start the service, not even on the Virtualbox Host-only network adapter.

It says the following errors in the log(translated by hand from Dutch(my Windows 10 OS version)):

1Unable to initialize DNS thread (Socket) on '<my computer's LAN IP address here>'. Each socket address can normally be used only once.
2...
3Service is started
4Service couldn't be started. The entry is invalid.

So it tries to create a DNS thread, but isn't successfully able to do so somehow? The stuff until the LAN IP address is still in English, but the rest is in Dutch(my OS local language).
Edit: Perhaps it's trying to 'replace' the Windows DNS service? And that's of course not allowed, because Windows uses it?

There's something nice I've just implemented in the UniPCemu packet server: support for the PPP protocol with IPX support. It translates those to plain ethernet packets, just like IPv4 for the SLIP protocol.

That should theoretically allow IPX games to run over a dial-up connection, but is such a configuration(dial-up PPP running IPX) supported by MS-DOS games? (I didn't port the IPv4 protocol to be available on the PPP protocol yet, though(requiring IPCP and IPv4 to both be added). It'll still need to use SLIP to use that, so not allowing both protocols at the same time yet)

Logging into the server is done as usual(sending username/password using the dial-up scripting), which will start the PPP service for the client. After that, the PPP protocol can be used to logon using the exact same username/password using the PAP protocol.
Then, once the IPXCP protocol finishes, the IPX protocol can be sent/received over the PPP connection.
Currently all the IPX packets are broadcast on the network with pcap using only a simple ethernet header.
All clients that listen to the IPX packets being sent on the network will receive the packet that's sent(it's a broadcast after all). UniPCemu's packet server won't do any filtering on the addresses, though, so all IPX packets that are sent on the network are received by all the clients simultaneously(the destination address is ignored and currently must be filtered by the app(for example Doom running inside an emulator) that is connected to the packet server).

Or do the packets need to be filtered somehow by the server? Anyone?

You may be able to use a *nix box in between the XP boxes to use as an "ISP "of sorts as long as it has two serial ports. just a thought. The system wouldn't have to be anything fancy either. Any old Pentium 1 class system will do.

OK. So there is dosppp06.zip or dosppp05.zip which provides PPP (after the server has been dialed and logged into to start it's PPP service for DOS) under MS-DOS.
Now how do I convert that connection (after the driver is loaded, probably at interrupt 60h) to support the IPX protocol for games (as I said before, IPv4 is unavailable for PPP. It's currently only supporting LCP, PAP authentication and IPXCP/IPX protocols)?

Edit: Would PDIPX run with the dosppp05 driver? ( http://www.shikadi.net/network/#shimIPX ). Would that be enough to get IPX running for games?

Hmmm... How is IPXCP supposed to verify if to ACK a certain IPX network and node number? Or is it just to assume those as a filter and pass through any packets matching it (no matter if it's a duplicate address)?
Nothing is mentioned about it in the IPXCP spec?

After lots of bugfixing the PPP packet handling code, I now see DOSPPP06's PPPD keep performing a LCP Configure-Request (receiving an ACK answer) followed by an invalid protocol FFh being given a Protocol-Reject result?
Why isn't it doing something else? Why the invalid packet followed by another login until it reports failure ("PPP link is down, driver not installed.")?

LSPPP that's with the Arachne browser seems to have the same issue? It keeps sending 0xFF-protocol packets?

Edit: Just fixed a bug with the header compression being enabled not interpreting the header being supplied (0xFF followed by 0x03 at the start of a PPP frame), causing it to read the protocol code instead (which isn't what happens according to the documentation (which says to examine the first 2 bytes for the sequence to match to disable the header compression for the frame received)).

UniPCemu's PPP IPX dial-up server works mostly in Windows 95 using dial-up 802.3 now. I see a one IPX packets being broadcast and received when logging in with PPP(Windows dial-up)? Nothing otherwise though. (No Doom 95 multiplayer running yet so far).

A slight improvement: just modified the LCP/PAP/IPXCP request packets sent from the server to the client and the IPXCP timeout for the waiting of the replies to the sent echo for checking IPX network/node assignment conflicts during authentication at the IPXCP stage to use the same clocking as the other parts of the server (instead of running at realtime speeds, which can be MUCH slower, because it's depending on the emulator's host speed relative to the emulated system's speed).

OK. That (at least one) IPX broadcast that Windows sends when having established the connection might be a NCP(https://en.m.wikipedia.org/wiki/NetWare_Core_Protocol) packet for a server?

Anyone knows how much of it is required for Windows to function properly over IPX?

OK. Just found out that the PPP transmitter for the client (from the server to the client) could get into a permanent halting state when during PPP packet transfer another packet arrives. In that case, it was causing the PPP transfer to be interrupted and never continue, which is incorrect behaviour (it should simply keep the packet buffered until it's ready to receive such a packet after all).

OK. Now, having fixed said issue, I see something strange happening: the IPXCP packets that are received from the client have wrong checksums?
Edit: In fact, looking at them directly shows that it's receiving incorrect PPP packets?

Anyone knows anything about Windows 95 sending invalid PPP frames when only IPX is supported and selected in the dial-up configuration?

Basically LCP(with PAP) and NCP(IPXCP) are sent without issues and proceeds to the open state.
But it looks like any other packet type(which can only be IPX in this case, all others being NAKed or Rejected) causes Windows to send unrecognisable data, probably IPX packets unencapsulated by PPP frames(only 0x7E bytes are used, though), looking at it's contents?