DosFreak wrote on 2022-09-04, 15:42:Have you verified that you can access a share on a 95 client on the host network without using unipcemu? Need to make sure you a […]
Show full quote
Have you verified that you can access a share on a 95 client on the host network without using unipcemu? Need to make sure you aren't running into an issue with security settings with Windows 10.
This is also likely a NETBIOS issue.
On a real network we'd use IP Helper for this traffic.
You are likely relying on NETBIOS broadcasts if you aren't using WINS or LMHOST.
Does unipcemu allow the broadcast traffic just from client to host or also from host to client?
How are the NETBIOS packets being handled? Name resolution in "network neighborhood" doesn't necessarily mean it's communicating correctly.
Are you able to use wireshark on this connection to compare successfull vs non-successful connections?
The client itself is on a PPP connection just sending and receiving IPv4 packets (as well as IPX, but those aren't used by the host (Windows 10) afaik).
UniPCemu receives all IPv4 packets, then filters them based on:
1) The MAC address. It just accepts packets for the client if a broadcast(ff:ff:ff:ff:ff:ff) or the client's MAC address (1 past the starting address, as the first MAC address of the used range for clients is reserved for the host to use itself)). This is also the MAC address used for sending packets (broadcast or client's own MAC address). All other MAC addresses are ignored by the client's receiver. This sending (for broadcast or specified IP) or receiving is handled the same w.r.t the MAC address on both sending and receiving side of the server (receiving filtering and sender setting said MAC address(non-broadcast to IP's ARP lookup, otherwise broadcast MAC(for broadcast-detected IPs) or default gateway's MAC address(if it's ARP succeeds))).
2) The IPv4 packets are mostly sent unmodified onto the host network. It uses ARP to send it to either the router (which is the default route) or the MAC address of an IP that's to be sent to according to the IP packet's destination field.
Then, after doing the ARP, special operations for IP address translation are performed (this is reversed on received packets on the host(using pcap receiver) or client network(using a one-entry local loopback buffer)):
- If the IP header specifies (when sending) that it's for the client network's broadcast address (determined by the client's IP combined with the subnet mask, with the client's host bits all set), it will replace the sent packet's IP address with the host's IP adress masked by the subnet mask with the host IP bits all set (the host's broadcast address).
- If the IP header specifies (when receiving) that it's for the host network's broadcast address (see above for the host's IP address and it's subnet mask based method), it replaces it with the client network's broadcast address when sending it to the clients connected to the server. The only exception for sending onto the host network is if the subnet specifies a non-broadcast local network IP (based on the netmask of the client). In that case it's sent to the loopback within UniPCemu, being received by clients of UniPCemu only.
That's basically all the 'routing' it does (modifying the IP address of sent and received packets for subnet broadcast addresses from host(when receiving) or from client(when sending)). Otherwise, the IP address is sent or received unmodified.
Edit: Just found a little 'bug' inside the sending and receiving. It would apply all those rules, but didn't apply the new destination MAC broadcast address if the IPv4 packet was broadcasting in any way (unless the ARP lookup for the client's destination IP field as detected to be a broadcast (so not including the all-ones IP address of 255.255.255.255)).
Now, with the latest commit, it will force the destination MAC address towards either client or host network to always be broadcasting on the MAC address level when the destination IP address is a broadcast of either network.
The receiving of such all-ones didn't have any problems with the MAC address, as it doesn't filter based on it (that's done at an earlier stage, which isn't using the IPv4 packet data as mentioned above).
Also, I can't compare successfull connections vs non-successful ones, as I don't have any capture of successful ones (Dosbox running Windows 95 (can be UniPCemu instead of Dosbox as well, but Dosbox's much faster emulating it, so more realtime packets) connected using PPP with UniPCemu's server build. UniPCemu's server build then sends and receives non-loopback packets onto the host network (described above). Loopback packets are instead sent directly to UniPCemu's pcap receiver thread (using a simple memory allocated buffer that's removed once the pcap thread of UniPCemu sends it to all designated clients connected to UniPCemu's server) instead of through the pcap driver.
Edit: After running wireshark and looking at the packets, I see (at least part of) the conversation between two Windows 95 clients using the filter:
(eth.src == 02:00:00:00:01:01) or (eth.src == 02:00:00:00:01:02) or (eth.dst == 02:00:00:00:01:01) or (eth.dst == 02:00:00:00:01:02) or arp or (eth.dst == ff:ff:ff:ff:ff:ff)
Here, the two Windows 95 hosts are on the :01:01 and :01:02 MAC addresses.
I see all hosts sending packets, but not everything that seems to be any question-answer communication?
