1

Currently I'm working on adding my own software to provide internet support to an old MS-DOS game. Because my primary environment is Linux, I use DOSBOX from within Linux and feed my internet connection into DOSBOX as per instructions from here: configuring DOSBOX for internet

After this, linux is basically acting like another router to DOSBOX but the gateway address and DNS that DOSBOX uses are the same as the host uses to connect to the internet.

I then download the mTCP dos internet suite and I can use its ping tool and its htget tool to retrieve the home page of google, but when I analyze the packets in unix's tcpdump I don't see the first 14 bytes of the ethernet frame and I don't even see an ARP packet either, and the mTCP suite has no ARP table.

So I don't understand how its possibly such software can connect to google when it doesn't even know the remote machines MAC address, unless its using broadcast address all the time, but wouldn't that drain network resources?

So back to my own software.... I am able to connect to my host (linux) from DOSBOX (we are dealing with the same computer here) if I use IP packets, but I am having trouble sending an ARP packet out (well at least tcpdump won't show it).

This is the data I am sending on the network in order:

FF FF FF FF FF FF 00 02 12 00 56 34 08 06 00 01 08 00 06 04 00 01 00 02
12 00 56 34 C0 A8 07 02 FF FF FF FF FF FF 08 08 08 08 

And I add zeros to the data until the size of the data is 60 bytes.

DOSBOX identifies my ethernet address through ETHERSLIP driver as: 00:02:12:00:56:34

While DOSBOX runs, I pre-created a tunnel and info for it is as follows:

sl0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1524
    inet 192.168.7.1  netmask 255.255.255.252  destination 192.168.7.2
    adaptive  txqueuelen 15240  (Adaptive Serial Line IP)
    RX packets 0  bytes 0 (0.0 B)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 0  bytes 0 (0.0 B)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Is there a way to set this up so that when I issue an arp request to the network in DOSBOX it will show up as an arp request (instead of showing up nothing) when I use tcpdump in linux?

3
  • So when I make an arp request, I should make all destination field values in the entire frame to FFh (meaning both mac address fields should be FF:FF:FF:FF:FF:FF and destination ip as 255.255.255.255)? I'll try that anyway and see what happens despite me already knowing the gateway address to the router
    – Mike St
    Apr 16, 2021 at 21:32
  • I'm not trying to ask for ARP beyond my physical router. I'm trying to allow DOSBOX to receive an ARP response by connecting to my router attached to my computer. Remember that DOSBOX and linux are on the same computer, but the arp requests that DOSBOX makes is not reaching linux (at least according to the tcpdump utility).
    – Mike St
    Apr 16, 2021 at 21:40
  • oh ok thanks for your help on that.
    – Mike St
    Apr 16, 2021 at 21:58

1 Answer 1

3

MAC addresses are only ever seen or relevant on the local layer-2 LAN. Also, not all layer-2 networks use MAC addresses, some use other addressing, and some use no addressing. Of those that do use MAC addresses, some are 48-bit and some are 64-bit MAC addresses. Routers strip off the layer-2 frame that contains MAC addressing and build a new frame for the next interface. A packet could pass through various layer-2 protocols from source to destination, and you have no way to know which protocols are used or which use MAC addressing or not in the path.

The DOSBOX connection is not using a protocol that uses MAC addressing, so it does not ARP. It is using SLIP, which is a point-to-point protocol, like PPP, that does not use MAC addressing (or any other layer-2 addressing, so there is no ARP. For SLIP, like for PPP, there are only two possible endpoints, so layer-2 addressing is not needed or used. All traffic from one end goes to the other end without using an address.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy