MsDos attempt: it doesn't work (yet..)

[zenprog]

First of all: what a great idea, Martin! Thanks for this project.

Now I'd like to share the problems I faced.
I've installed the precompiled binary firmware on a AZDelivery D1 Mini NodeMcu ESP8266-12F.
I connected a RS232 DB9 adapter with a 3 wire cabling (TX,RX,GND,3.3V).
I set the bitrate conservatively to 19200 (telnet gateway 7777, set bitrate 19200)
I installed Linux on an old thin client and I followed the instructions Martin provided in the README.MD
IT WORKED flawlessly, great!
Configuration of the esp_slip_router:

CMD> show
ESP SLIP Router V1.1.1 (build: Sun Feb 23 23:34:52 20202)
SLIP: IP: 192.168.240.1 PeerIP: 192.168.240.2
STA: SSID: XXXXXXXX PW: XXXXXXXXXXXXX [Autoconnect:1]
External IP: 192.168.0.175
DNS server: 192.168.0.1
Clock speed: 160
Serial bit rate: 19200
CMD>

Once I turned to DOS with packet driver the problem arised..
I tried with MsDos 5 and FreeDos 1.2, but the problem is the same: I can telnet the gateway
at port 7777 , I can ping the gateway, I can ping the router and other devices on the wifi network 192.168.x.x,
and even the "outside world", e.g. 9.9.9.9 and 8.8.8.8.
That's all. I cannot resolve any address on internet (even google.com) or ftp or telnet
(I also tried to set the DNS to 9.9.9.9 and 8.8.8.8, no way).

This is the software configuration:
DOS

mode COM2: BAUD=19200 PARITY=n DATA=8 STOP=1

Packet Driver:

EtherSLIP (ethersl.com) on COM2 (ethersl 0x60 3 0x2f8 19200)
(but also tried slipper: Slipper COM2 19200 ether nohwhs)
this is the ouput:

Packet driver for ETHERSLIP, version 11.7
Portions Copyright 1988 Phil Karn
Packet driver skeleton copyright 1988-93, Crynwr Software.
This program is freely copyable; source must be available; NO WARRANTY.
See the file COPYING.DOC for details; send FAX to +1-315-268-9201 for a copy.

16550 Uart detected, FIFO will be used
System: [345]86 processor, ISA bus, Two 8259s
Packet driver software interrupt is 0x60 (96)
Interface class 0x1 (1)
Interrupt number 0x3 (3)
I/O port 0x2F8 (760)
Baud rate 0x4B00 (19200)
Receive buffer size 0xBB8 (3000)
My Ethernet address is 00:02:12:00:56:34

TCP software

MTCP with this configuration file:

PACKETINT 0x60
MTU 1500

IPADDR 192.168.240.2
NETMASK 255.255.255.0
GATEWAY 192.168.240.1
NAMESERVER 192.168.0.1

and with this settings in the autoexec.bat:

SET MTCPSLIP=true
SET MTCPCFG=C:\MTCP.CFG

Wattcp with this configuration file (c:\WATTCP.CFG):

my_ip = 192.168.240.2
netmask = 255.255.255.0
gateway = 192.168.240.1
nameserver = 192.168.0.1

and with this settings in the autoexec.bat:

SET WATTCP.CFG=C:\

Here you can find the output of some commands that, maybe, can help..

The most interesting output are from th ping command of mtcp suite,
the ping command of the wattcp suite, the dnstest command of mtcp suite and the pakttool command of mtcp suite.

ping (wattcp)

-----tcpinfo (attcp)

Reading Waterloo TCP configuration file.

Ethernet Address : 0:2:12:0:56:34

IP Address       : 192.168.240.2
Network Mask     : 255.255.255.0

Gateways         : GATEWAY'S IP     SUBNET           SUBNET MASK
                 : 192.168.240.1    DEFAULT


Cookieserver     : NONE DEFINED

Nameserver       : 192.168.0.1
Domain           : "(null)"

BOOTP            : NOT USED
BOOTP Server     : BROADCAST
BOOTP Timeout    : 30 seconds

Default Timeout  : 30 seconds
Max Seg Size MSS : 1400 bytes

tcp_Socket : 4206 bytes 
udp_Socket : 2097 bytes 

-----pkttool (mtcp)

mTCP pkttool by M Brutman ([email protected]) (C)opyright 2012-2020
Version: Mar  7 2020

Details for driver at software interrupt: 0x60
  Name: ETHERSLIP
  Entry point: 0366:03CE
  Version: 11   Class: 1   Type: 0  Interface Number: 0
  Function flag: 2  (basic and extended functions)
  Current receive mode: packets for this MAC and broadcast packets
  MAC address: 00:02:12:00:56:34

All statistics are from when the packet driver was loaded.

Packets in:           26  Packets received
Packets out:          31  Packets sent
Bytes in:           1852  Bytes received (includes Ethernet headers)
Bytes out:          2224  Bytes sent (includes Ethernet headers)
Errors in:             0  Receive errors
Errors out:            0  Sending errors
Packets lost:          0  Lost due to no packet handler, out of buffers, etc.

I also tried different net masks

255.255.255.0
255.255.255.252
255.255.255.254
255.255.0.0

but no way.

Does anyone have a good idea? :)

[zenprog]

...no idea? It seems quite weird that that the esp_slip_router doesn't work in a msdos environment

thanks for reading

[martin-ger]

Sorry, I have no experience with MSDOS networking. If you can ping to the outside, but not telnet, it seems to be a problem with MSDOS TCP, IP and routing seems to work.

Could you perhaps try a wireshark on a local client to see, whether the TCP SYN requests reach the outside?

[cshunt]

I believe you need to set NAMESERVER 192.168.0.1 in you mtcp.cfg file to something like the default NAMESERVER 8.8.8.8 to use google's name server, unless you have your own nameserver forwareded from your router. Thats why you can ping outside ip addresses but not resolve the names.

EDIT: The above does not make any change. Odd that linux has no issues resolving but mTCP does. ms-dos using mTCP name server look up connects fine through a shared serial port on linux just not thru esp8266_slip_router when using ms-dos. must be a formatting issue. I haven't used wire shark, perhaps I can get a copy of the traffic both from linux and from esp over the serial port when running "ping" command from mtcp.

[cshunt]

I ran some wireshark on the connection request from dos --> esp8266 --> windows shared wifi running wireshark --> internet
192.168.137.1 is the windows assigned ip to the esp8266. I'm not very good at deciphering this data but one item stands out. On the answer, the ip address is sequenced backwards. I'm not sure if this is correct. Could anyone more familiar with dns request let me know if this is right?

Appreciate any help. it is pretty cool using microweb to view a webpage on an 8088 machine.

[cshunt]

So the issue seem to be that esp8266-slip-router isn't completely transparent, changing ip and nat connection. Request can make it out but the path back is not found. The esp8266 is not looking for the mac address of mTCP/etherslip contained in the packet

Below is my connection to pi zero, the last part would be nice to somehow include in esp8266-slip-router but it may fit into the "zimodem" program better, zimodem already does some internet lookup dns stuff a little more directly. Web addresses can be "dialed up" with modem commands.

1. To get mTCP connecting to the web through a linux machine (pi zero w)

• stty -F /dev/ttyS0 -clocal -crtscts 115200 (using 115200 baud for virtualbox ms-dos to serial port passed thru)

• slattach -d -v -L -m -p slip -s 115200 ttyS0 &

• ifconfig sl0 192.168.2.5 pointopoint 192.168.2.6 mtu 576 up netmask 255.255.255.0 (default netmask does not work with mtcp)

• arp -s 192.168.2.6 b8:27:eb:57:62:4c pub (<--- my mac address of wlan0 of pi zero, "ifconfig")

• echo 1 >/proc/sys/net/ipv4/ip_forward ( failed until I modified sudo nano /etc/sysctl.conf and uncommented "net.ipv4.ip_forward=1")
  (above will get a ping and connection between the machines, the below make the linux machine look for packets with the mTCP/etherslip mac address and forward them through the serial link.) (I think something here would need to be added to give esp8266-slip-router the ability to look for different mac address request or swap out mac addresses of the packets in both directions.)

• iptables -t nat -A POSTROUTING -o sl0 -j ACCEPT

• iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

2. mTCP setting (net.cfg) autoexec.bat points to these

• packetint 0x60
mtu 576
hostname dbox
telnet_cga 1
IPADDR 192.168.2.6
NETMASK 255.255.255.0
GATEWAY 192.168.2.5
NAMESERVER 8.8.8.8
LEASE_TIME 3600

[ssshake]

I am having the exact same problem and I would be thrilled to find the solution. I'm connecting an esp to my DOS computer over serial. I can do all the same stuff described above except for DNS.

I am trying to use microweb, a web browser for dos. I've been using this successfully over a wired serial connection to a pi. Now I am trying to use your software to get wifi ethernet.

The goal is to not have to have a man in the middle such as a pi doing anything. I would like to be able to plug an ESP8266 into my DOS computer serial port, connect to my wireless AP and then use the ethersl.com driver to get internet access.

Anyone know what needs to be done to get over this hurdle? Thanks!

[ssshake]

Following up here. I think @martin-ger's assessment the "If you can ping to the outside, but not telnet,.." was incorrect.

I believe the OP is able to do everything but DNS resolution. I believe he could telnet to the outside world by IP.

This is the same issue I have too. I can do anything by IP. I can PING IRC, FTP, Telnet, and HTTP by IP.

I cannot do anything by domain name.

On the same DOS computer instead of using ETHERSL (SLIP serial ethernet) to connect to the ESP8266 I am using ETHERSL to connect to a raspberry pi over serial. When I connect this way DNS works fine. So I think it's fair to rule out an issue with the DOS configuration or software.

One thing I've observed is that when I telnet to esp_slip_router and type SHOW it always says my DNS server is my gateway (10.0.0.1 in this case).

If I issue a set DNS 8.8.8.8, save and reset, when I type SHOW again it still shows 10.0.0.1.

I have tried multiple DNS servers in my mtcp.cfg in DOS. I've tried my local DNS of 10.0.0.1, I've tried 8.8.8.8, 9.9.9.9 and 192.168.240.1

The IP address of my DOS system is 192.168.240.2.

Why wouldn't the UDP (I assume) packets for the DNS look up being resolved?

[ssshake]

Ok I think I have a clue in the verbose output of dnstest.exe

DNSTEST.EXE -name google.com -verbose returns an error

Bad checksum: c097, should be 8609 Src: 168.240.1.192

It seems to me that the IP address is mixes up, the 192 part is shifted to the end where the .1 part should be.

[zenprog]

Hi everyone!
I'm the one who opened this issue in march 2021.
I'm not that geek, but it's exactly what I experienced in my setup. Something goes wrong with the UDP packet, I suppose. Martin, Is it possible to solve it..? It would be a great piece of news to the vintage pc community to have a old dos pc working seamlessly with the esp8266 connected to the serial port.
Let us know! :)
Thanks

[cml37]

Following!

[ssshake]

I've been digging through the source code trying to get familiar with the code base. So far it's far out of my comfort zone but I'm interested to learn how to fix this!

[zenprog]

thanks ssshake ! :)

[jhhoward]

This looks suspiciously like a one byte offset error when processing the IP packets. If you look at the layout of an IPv4 packet header it has the source address (4 bytes) followed by destination address (4 bytes). With this error:
Bad checksum: c097, should be 8609 Src: 168.240.1.192
It looks like it is splicing together the last three bytes of the source address and the first of the destination address, indicating that it started reading the packet one byte later than it should have done. Perhaps this is a problem with the SLIP implementation or mTCP itself?

[zenprog]

Hi jhhoward!
Well, I suggest that maybe the problem could be in the SLIP implementation, because I experienced the same problem in either mTCP or WATTCP (see first post of the thread). Just a guess...

[jhhoward]

@ssshake does the checksum failure error appear consistently for you? It doesn't trigger any checksum errors in my setup, although still fails to perform the DNS resolve

[ssshake]

@jhhoward No sorry I should have updated my comment. I only saw that on occasion and I don't know how to force it to throw that error.

[martin-ger]

I am not fully following this discussion due to many other things, but perhaps the problem comes from the fact, that the NAT lib doesn't rewrite low ports (<1024)?

You might try to change this here for TCP https://github.com/martin-ger/esp-open-lwip/blob/5157a11da89c2ae8aeca0653c5a44fed7377fde8/lwip/core/ipv4/ip.c#L879 anf here for UDP https://github.com/martin-ger/esp-open-lwip/blob/5157a11da89c2ae8aeca0653c5a44fed7377fde8/lwip/core/ipv4/ip.c#L923

[mbbrutman]

Can somebody provide a packet capture or run the mTCP trace and send me the trace file? There is a bug in mTCP that makes it insist on UDP packets having valid checksums, even though they are optional for UDP in IPv4. You may be hitting this and I'd like to confirm it or rule it out.

[ssshake]

Hey it's @mbbrutman the author of mTCP himself! If you want to contact me offline I can mail you a wifi device to load up this firmware on. You can reach me at web master at the old net dot com.

Can you give me instructions on how to provide the trace that you want? I have no idea where to begin on that.

@martin-ger thanks for this input. I understand you didn't create this firmware to be used in DOS so I appreciate the extra effort helping us out. For context we are vintage computer enthusiasts and we are trying to get network connectivity on old dos computers.

I will try to make some time to try the changes you proposed but if anyone else gets to it before me please let know.

[cml37]

Wireshark would probably work for the tracing unless @mbbrutman has another utility!

[mbbrutman]

mTCP has it's own equivalent tracing facility.

Before running mTCP set the following environment variables:

set logfile=tcp.log
set debugging=255

Then do whatever you were going to do that fails. Every packet will be dumped into the trace file, so don't send passwords or sensitive data. On a low machine this can really hurt performance, so use something faster with a hard drive if you can.

(The full instructions are in the mTCP PDF documentation in the debugging section.)

[mbbrutman]

ssshake sent me a device, and after trashing the device with a bad config and trashing my Ubuntu 16 machine trying to install the flash tools, I eventually got to debugging it. :) (Wow, I hate Python.)

The mTCP DNS resolver code uses UDP port 57 as the source port. The SLIP router probably views 57 as a privileged port and is sending back an ICMP message saying the port is unreachable. I tested with port 1057 as the source port instead and then DNS resolving started working. I will have a test version of mTCP available for people to try this weekend, but I've been making lots of other changes so I'm a little worried about people grabbing it and then forgetting to get the next release.

On a related note:

My DOS machine can ping the outside world, resolve DNS addresses, and do useful work (telnet, ftp) through the device. All is good.

However, if I ping the device on it's public address (the one that my router handed out) no echos are received. And my DOS machine can ping my home router, but it can't ping anything else on my home network.

If I move the device back to a Linux machine I have the same problem, so DOS is not the issue here. And it's not just PING either; I can't make socket connections to machines on my network.

Am I missing a configuration step?

[jhhoward]

That's good to know that there is a solution for DNS resolution for mTCP!
Could the ping packets also be getting blocked for the same reason? i.e. dropped for being on a privileged port number
Did you test with FTPSRV as I imagine port 20/21 could also get blocked for the same reason?

It might be worth investigating adding a setting for the SLIP router to allow for forwarding packets on privileged ports.

Something that I was able to do was telnet into a Raspberry Pi on my network from my DOS machine using the SLIP router. The Pi was connected to the router via an Ethernet cable rather than connected by WiFi though. I think that there can be problems with routing packets via WiFi as I experienced problems in the past when using a Raspberry Pi as a SLIP router.

[mbbrutman]

I opened another issue for the connectivity problems, as they are not related to this issue. (They seem to be caused by the esp_slip_router device not sending ARP requests or responding to ARP. But it is caching hardware addresses, which is why it can ping the home router and the outside world, but not anything on the internal network. The work around is to prime the ARP cache on the other machine, then have it ping the esp_slip_router device, which allows the esp_slip_router device to cache the hardware address.)

For this issue (DNS resolving) I went back through the specs again. Using port 57 as a source port for UDP should be perfectly legal. Ports below 1024 are only sensitive when used as target ports for services, and that is really only by convention. A NAT device should be transparent and should not be enforcing restrictions like this. (It's a policy, not a technical requirement. Which is why it works everywhere else.)

I have a work around that uses a higher number source port, but really I think this is a but in the NAT code in Lwip that should be fixed there.

[martin-ger]

As said above, feel free to adapt this here in the code:
For TCP https://github.com/martin-ger/esp-open-lwip/blob/5157a11da89c2ae8aeca0653c5a44fed7377fde8/lwip/core/ipv4/ip.c#L879 and here for UDP https://github.com/martin-ger/esp-open-lwip/blob/5157a11da89c2ae8aeca0653c5a44fed7377fde8/lwip/core/ipv4/ip.c#L923

[mbbrutman]

Both checks look to be incorrect as per my description. But I was hoping to get your opinion on if you think I am correct or if I am missing something.

If it is incorrect it really should be fixed upstream, as it is affecting every other lwip NAT implementation, unless this is a local change.

[martin-ger]

I would merge a pull request for that, but for the moment I don't have the time to go into testing.

[e1z0]

ssshake sent me a device, and after trashing the device with a bad config and trashing my Ubuntu 16 machine trying to install the flash tools, I eventually got to debugging it. :) (Wow, I hate Python.)

The mTCP DNS resolver code uses UDP port 57 as the source port. The SLIP router probably views 57 as a privileged port and is sending back an ICMP message saying the port is unreachable. I tested with port 1057 as the source port instead and then DNS resolving started working. I will have a test version of mTCP available for people to try this weekend, but I've been making lots of other changes so I'm a little worried about people grabbing it and then forgetting to get the next release.

On a related note:

My DOS machine can ping the outside world, resolve DNS addresses, and do useful work (telnet, ftp) through the device. All is good.

However, if I ping the device on it's public address (the one that my router handed out) no echos are received. And my DOS machine can ping my home router, but it can't ping anything else on my home network.

If I move the device back to a Linux machine I have the same problem, so DOS is not the issue here. And it's not just PING either; I can't make socket connections to machines on my network.

Am I missing a configuration step?

Hi, is it possible to use mTCP nameserver with port specified for example local dns with port 5353? It Would be a good solution for now..

[e1z0]

I have updated esp-open-lwip, also made new firmware utilising these fixes, now dns are fully working on DOS environment. Also i've made simpler build environment using docker, you no longer need to setup complex build tools to build this firmware or esp-open-lwip lib.

[martin-ger]

Great! I added a link to the repo in the Readme.

[e1z0]

Maybe one of you guys tried it using Win9x ? https://support.dynabook.com/support/viewContentDetail?contentId=108228

[guidol70]

I have updated esp-open-lwip, also made new firmware utilising these fixes, now dns are fully working on DOS environment.

@e1z0
GREAT - with your firmware version I got it up and running and so I can connect with my DOS-PC via MTCP/Etherslip/Telnet-Client using the ESP8266-Slip-Router to my ESP32-Telnet-Server which is running the RunCPM CP/M-Emulation Software :)