Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locally-Administered IPX Unicast Address Mappings #21

Closed
joeHeartsmith opened this issue Oct 10, 2022 · 3 comments
Closed

Locally-Administered IPX Unicast Address Mappings #21

joeHeartsmith opened this issue Oct 10, 2022 · 3 comments

Comments

@joeHeartsmith
Copy link

DOSBox's native IPX client/server addressing was written with RFC 1234's 'Unicast Address Mappings' in-mind (well, sort-of; they implemented it backwards), so the clients' IPX node host numbers are built using their IPv4 addresses as the first 4 octets of their IPX node host number during registration. The DOSBox IPXNET PING utility shows reply IP addresses that are built this way - using the first 4 octets of the replying clients' IPX node host numbers to show which IP the reply came from. With ipxbox's randomly-generated locally-administered addresses (starting with '02:'), the IPXNET PING utility shows an incorrect IP address from any client connected through ipxbox, and no mapping exists to derive the true IP address from the corresponding IPX node host number.

in ipxbox:

in ./server/dosbox/protocol.go:143:

Addr:    *p.nodeAddr,

(p.nodeAddr is set via network.NodeAddress(node) at line 71, which eventually fetches a randomly-generated address from the 'addressable' package at ./network/addressable/addressable.go:38)

in DOSBox:

in ./src/ipx.cpp:757:

// Generate the MAC address.  This is made by zeroing out the first two
// octets and then using the actual IP address for the last 4 octets.

later (line 813):

memcpy(localIpxAddr.netnode, regHeader.dest.addr.byNode.node, sizeof(localIpxAddr.netnode));
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For ipxbox, the first 4 octets of the DOSBox client IPXNET registration reply IPX address should be set to the UDP source address of the requesting client, followed by the 2 bytes of the client's ephemeral UDP source port. This guarantees that the public IPv4 addresses of the clients are used to populate the first 4 octets of their IPX node host numbers, allowing DOSBox users to see the actual IP/location of peers in the network when conducting a broadcast ping.

  • Maybe this behavior could be a command-line option
  • The same could apply to PPTP clients
  • Honestly, this probably belongs with the DOSBox team as well, because the behavior is inconsistent between client and server.
  • I don't know what to say about IPv6 clients - I think the most appropriate solution is to pull their MAC address from the EUI-64 portion of their Global Unicast Address.
  • To extend this functionality, for ipxbox configurations using the -enable_tap option, ipxbox could supply clients with the primary IPX node network number of the host machine instead of all-zeroes to guarantee that all connected clients are in the same broadcast domain, and to enable routing when necessary.
@fragglet
Copy link
Owner

Thanks - I am aware of this but it was a deliberate decision on my part and I consider it working as intended.

It doesn't actually matter what IPX address the player assigns to clients, and there's the (admittedly minor) advantage that assigning a random address protects the privacy of the clients by not disclosing their IP address to other users. Of course there's the disadvantage that ipxnet ping shows the wrong IP address but I think it's an acceptable compromise.

So I'm going to close this bug, but if you have a convincing argument as to why the dosbox behavior is worth preserving (other than standards compliance and the ipxnet ping output) I'd be happy to hear it.

@joeHeartsmith
Copy link
Author

I figured something like that might be the case. No worries - it was a tall ask that didn't come with too much benefit. I'm definitely loving ipxbox though!

@fragglet
Copy link
Owner

Thanks! I'm glad you like it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants