I've just adjusted the parsing of the packets to strip the ethernet headers(after checking the destination and type to match the settings), while sending packets generates an ethernet header based on the settings. The decoded SLIP data sent from the virtual serial connection(from the client connected through a TCP connection) is appended to said generated header and sent using pcap(with the type field set to 0x0800(IP) in big-endian format).

The only basic thing left to do with this is testing it, but I'll first need to get winpcap working for that to work(with mingw if possible).

Lol. Eventually connected to UniPCemu(which was in the new server mode(when compiled with pcap support and configured using the settings.ini file)) using the SLIP8250 driver(from http://www.crynwr.com/drivers/pktd11.zip ), noticed it wasn't seeing any packets being received? Then looked at UniPCemu's code and noticed that the main packet retrieval function(which polls the network for packets and retrieves them into a newly allocated buffer(allocated with the normal zalloc allocation function) to be sent over the TCP connection(the virtual modem data connection) to the other side) wasn't even being called from the main timing function. So I had pretty much all handling and parsing in place(from the server point of view, even sending packets when requested to(non-empty IP packets are sent onto the network using pcap)), except that it wasn't actually sending any packets back(thus no input when being connected and the resulting TCP/IP errors.

Having fixed that, it's time for another go at it with Dosbox!

After some messing around with the code, it's now at least sending out DNS requests(just testing with www.google.nl in the Arachne browser inside Dosbox, which is connected to UniPCemu which is compiled for WinPcap and transmitting all packets received and sent(adding/removing the ethernet frame when converting from/to raw SLIP data). Although I don't know if it's receiving and parsing the resulting stream back correctly? The inbound stream is filtered by UniPCemu to only receive IP packets(ethernet type 0x800 in Big-Endian format).

Anyone knows if this causes any issues with stuff like web browsers(filtering too much or not enough) using the TCP SLIP connection?

https://bitbucket.org/superfury/unipcemu/src/ … dem.c?at=master

Look at lines 1689 to 1873 for the logic that converts to/between both packet formats and reads/writes to the buffer(for sending/receiving to the connected SLIP client on the TCP connection), while receiving raw ethernet data using the net.packet buffer(freed once processed) and sending the ethernet packets using sendpkt_pcap function.

Anyone? Why is the Arachne browser failing to reach the website?

Just tried installing and running Windows 95 on various versions of Dosbox. Pretty much each one of them craps out once they start booting Windows after the installation wizard? Corrupted screen, various exceptions(including #UD exception), NULL pointer exceptions etc. Used to work before. Tried Dosbox Daum, Dosbox-X, Dosbox 0.74 and Dosbox 0.73. All the same(crashing in one way or another)... So far for my brilliant idea to use it's modem emulation to test my software modem emulation... 😖

Oddly enough, using the old Windows 95 installation runs fine until reboot. Maybe a problem with Windows 10 vs Dosbox?

Btw, tried connecting the Windows 95 box through Dosbox. It seems to connect, then for some reason disconnect after that?

Since Arachne IS actually sending the packets properly, can anyone see a problem with the receiving end of things? Is there any MS-DOS software that's running within Dosbox that allows packets to be captured for analysis?

Managed to get Windows 95 running properly under Dosbox-Daum(32-bit version. All other versions as well as the 64-bit Datum version give lots of errors. So it's got something to do with 64-bit Dosbox giving lots of errors?). The current version of the server(made for use with (win)pcap) can be found at the UniPCemu repository(currently only compiling for Linux and Windows(MSys2/MinGW in my case)). It will try to decrypt incoming SLIP packets and send outgoing SLIP packets by en/decoding then into a raw IP packet, then sending/receiving them over the LAN using winpcap, while constructing/removing the ethernet header based on the setting in the UniPCemu configuration ini file.

I've made a little script that can be used with the Windows 95 logon script to login to a server that's hosted by UniPCemu's service:
https://bitbucket.org/superfury/unipcemu/raw/ … odemconnect.scp

So far it's working with Windows 95 to login to the server. Invalid login configurations(like improper authentication or protocol(set to slip in the modemconnect.scp file)) will simply disconnect the client from the server(by the server). So no fancy error handling yet.

Oddly enough, it seems to be receiving packets from the host PC(I see the Windows 95 byte count increasing constantly), but it doesn't seem to send anything for some reason? The send bytes field in Windows 95's information screen(in the connection status screen) seems to be constantly counting upwards, so it seems to be receiving something at least(although unknown whether it's properly receiving/decoding the data received?

Is there a way to look at the received packets on Windows 95?

Even when I fire up the internet browser and open a web page, nothing is sent by the Windows 95 client to the server?

Eventually managed to get portmon for windows 98 running within Windows 95. This is what I get:

Just a simple translation of the text in the second picture(connection status):

Connected at 57600bps
Duration: ...
Bytes received: ...
Bytes sent: ...

Even trying to run internet explorer doesn't seem to send any packets at all?

I do notice two things:
1: It doesn't seem to send packets when loading an internet page using Windows 95's Internet Explorer? Arachne on MS-DOS does seem to send DNS packets, which the server wraps in an ethernet packets(source MAC=Virtual MAC, Destination MAC=Default Gateway MAC(both MAC addresses are configured in the server's settings file).
2: The incoming filter receives lots of packets, filters out only IP packets(type 0x800), where the destination MAC within the ethernet header is matching the set Virtual MAC.

The packets to/from the network are sent using pcap(with Ethernet header(src/mac as configured, type 0x800) slapped on when sending and stripped off when receiving).
The packets to/from the connected client(e.g. Dosbox running Windows 95 or Arachne) are encrypted(when sending to the client) or decrypted(when receiving packets to send from the client) in SLIP format.

I constantly see the Windows 95 internet connection status window increase it's received byte count, while the sent byte count barely increases.

Anyone knows why the IP packets aren't getting through properly? Is something else still needed for it to work?
The only things that don't happen to be encrypted in SLIP format to the client is the authentication process(which hangs up when failing(invalid username/password/protocol supplied) and discards receiving packets from pcap until sending the CONNECTED message(after authentication passes and basic MAC addresses are conveyed to the client in ASCII text format).

Windows 95 connects properly using the login script, but doesn't seem to properly receive the packets?

Is it a problem I'm sending all received packets (only filtering on MAC address and IPv4 packet type)?

Anyone knows how to install MTCP and use it within Windows 95? I've so far gotten Windows 95 connected to my UniPCemu emulator that's running a SLIP server I've built into UniPCemu(which has only support for one client at a time, with optional username/password(when both are non-empty, it's used) and only SLIP protocol), but I can't get stuff like MTCP working with it?

Anyone can see what's going wrong?

To configure it under Windows 95, simply add the TCP/IP protocol and required protocols, add the modem for Dosbox, configure the modem to use SLIP(UNIX) and use the modemconnect.scp to connect. Finally, configure UniPCemu using the modem section(username&password are used when set to non-empty values, in Windows, set the listenport accordingly, MACaddress to your NIC MAC address that you've selected(find index to use by selecting index 255 and running UniPCemu, then set the value to the reported number of your NIC). Set gatewayMACaddress to the MAC address of your default gateway(which can usually be found on your modem configuration pages itself). Of course, don't forget to run UniPCemu(doesn't matter if it's running some XT machine or whatever machine, as long as it's running it's connectable through the set server).
Of course you'll need to configure Windows 95 to dial to the server by specifying <IPADDRESS>:<PORT> in the dial menu(which can also be done in the Modem configuration withing Windows 95 dial-up connection settings).

I see it properly sending packets, but I don't know if it's also properly receiving it? Anyone can see if it's receiving the packets properly? Or is there another problem with the received packets(too many?)? I'm using Dosbox SVN Daum(current version) to run Windows 95 and connect to my server.

Anyone?

A small improvement for the server:

- Added support for a static IP address. That way, it can filter incoming packets for said IP address as well as provide slight IP autoconfiguration to the Windows 95 login script(giving it the IP address that's set).

Edit: Small update: prevented underflow when IP addrress is less thsn 12 digits to form an I{ address. Also added improved support for excluding ethernet footef by using the IP packet length as a limiter of the packet length to send to the client.

I've managed to get automatic IP addresses working(by setting one in the configuration file). Windows 95 detects the proper IP address, but when I look at the configuration set by the Ethernet adapter information(winipcfg), It somehow shows both my IP address(being set correctly) and Default Gateway(being set to the IP address???) being set to the very same address???

Anyone knows how this can be? I've even configured the default gateway in the TCP/IP settings, but it's still not changing?

Whatever I do, those two values keep being the same, even when reconfigured from the server using a "IPaddress:xxx.xxx.xxx.xxx\r\n" field(in this case IPaddress:192.168.178.246\r\n, which is parsed using the logon script I've posted earlier posts)?

After looking at packet logs, I've found out that two things were going wrong:
- The packets weren't getting filtered correctly.
- The packet receiver(that's receiving from WinPcap) wasn't resetting the pointer correctly, thus not starting new packets and also not filtering new packets and scanning for them.

Having fixed this, Windows 95 now properly can find and load(somewhat within the old Internet Explorer) various webpages 😁

Proof(this very thread showing in the webbrowser):

So far, HTTPS doesn't seem to work properly, but plain HTTP does seem to work?

Downloading Firefox 1.5 reeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeally slowly...

Hello from Firefox 1.5 running within Windows 95 using the SLIP server!!!:D
Screen capture following...

And the promised screen capture:

Made some slight update to the UniPCemu server version(alongside some of the more recent bugfixes etc.):

Some updates to the server in this case include:
- A slight 3 second delay between the "CONNECTED" message and start of the transfer of data to/from the internet/client. This is mainly to allow the user to press ALT-P on the arachne MINITERM program.
- The password text input has been encrypted into returning star characters instead of the password that's typed for additional protection(still sent to the server unencrypted, though) for the viewer.
- Backspace support has been added on all input fields during the login process. It will now send backspace back, but with a space and backspace following it, effectively clearing the last inputted character on the screen(at least as long as it's still inputting on the same line).

Another little server update, adding a new feature:

- Added support to the packet server to allow the "ethernetslip" protocol to disable adding and stripping of ethernet layer headers when sending and receiving packets.

The new protocol is the same as the old "slip" protocol(using a SLIP-encoded data stream), but instead of adding an Ethernet header when sending and removing the Ethernet header when receiving, the packet is sent/received directly to the router(only leaving the receiver filters in place). This will allow software that tries to use Ethernet packets over SLIP(Instead of IPv4 packets) to communicate properly using the server.

Newer builds of the UniPCemu server can be found at the itch.io project page. One main improvement it has now is the ability to prevent windows from going to sleep(standby) by passing it the "nosleep" (without quotes) parameter, which is quite handy when you don't want Windows to go in standby while it's running.