VOGONS


First post, by CoTeCiO

User metadata
Rank Newbie
Rank
Newbie

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. I know that all the games I want to try (Doom, Starcraft, Duke Nukem 3D, Descent, Need for Speed II, among others) have the much easier serial and TCP/IP or IPX options, but I wanted to give a try to something I had very little experience back in the day, that was playing games through a modem, except one time I played Doom with a friend for way too long and got in trouble with my parents because of the phone bill that resulted of that heh

I've been looking for information but I haven't found anything that leads me in the right direction, pretty much all the stuff I see is for more "serious" applications and are very hard to follow, with very complicated setups. There's apparently some software that can do that, but it's $270 and I'm looking for something that doesn't require busting the bank for software I want to use just to play around with. There was another guide for use with real modems and I'm looking to do this on computers that don't have one. I want to run this on Windows 98 SE, but the possibility of running it on Windows XP as well would be nice for Windows games.

Reply 1 of 8, by superfury

User metadata
Rank l33t
Rank
l33t

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.

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 2 of 8, by Jo22

User metadata
Rank l33t
Rank
l33t
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

Last edited by Jo22 on 2020-01-08, 22:02. Edited 2 times in total.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 3 of 8, by superfury

User metadata
Rank l33t
Rank
l33t

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)?

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 4 of 8, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
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?

Reply 5 of 8, by superfury

User metadata
Rank l33t
Rank
l33t

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

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 6 of 8, by superfury

User metadata
Rank l33t
Rank
l33t

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?

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 7 of 8, by superfury

User metadata
Rank l33t
Rank
l33t

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)?

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 8 of 8, by superfury

User metadata
Rank l33t
Rank
l33t

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)):

Unable to initialize DNS thread (Socket) on '<my computer's LAN IP address here>'. Each socket address can normally be used only once.
...
Service is started
Service 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?

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases