[Q] DNS-resolve with MTCP and Intel E100(B) Packet Driver?

[Guido Lehwalder]

Hi,

I would like to ask if anybody knows if any Intel (Pro) 100(B)
DOS-Packet-Driver as funtions does support to use a DNS/NAMESERVER with MTCP?

I got the follwing Packet-Drivers:

- E100PKT v0.3 from Seth Simon

- E100BPLT from Morien W. Roberts in v11.11 and v11.12 (E100B11C.ZIP)

I can ping/telnet IPs inside my local network 192.168.6.x like

- 192.168.6.1 my DSL-Router

- 192.168.6.116 my Pi-Hole AdBlocker

- 192.168.6.80 ,y ESP32-Telnet-Server with RunCPM

But I cant ping a domain name like www.heise.de or 
a IP like 8.8.8.8 (Google DNS)

dnstest -name 8.8.8.8 say it does "resolve" it as 8.8.8.8

but any other resolve-test do fail with

Dns server error: (5) Server Refused Us!

I also cant use my DSL-Router as a working DNS but it can be pinged.

So my though is that the E100-Packet drivers may not support this funtion, because pkttool from MTCP gives me for

e100bpkt a function flag of 10 (unknown) and for

e100pkt  a funtion flag of 1 (basic funtions only)

Is DNS a basic function?

Does anybofy know an additional driver or version with DNS-resolve-function for the Intel Etherexpress Pro e100?

With the former SLIP--serial connection I could ping the Google DNS 8.8.8.8 :(

So my network and netmask (255.255.255.0) seems to be OK.

Many thanks in advance for reading and maybe replying to my question :)

[Michael Brutman]

Hi Guido,

I think  your packet drivers are probably fine.  Their only function is to be able to send or receive packets.  If they can do that, they are doing their job.

The -name option on dnstest is the target name of the server you want to resolve.  That should be a human readable name, like www.heise.de, not 8.8.8.8.  Using 8.8.8.8 there works because there is no work to resolve an IP address that is given in numerical form.

For testing purposes you want to specify the nameserver to use, and that should be specified as a numerical IP address.  Google's name servers work well, and those can be found at 8.8.8.8.  Your ISP name servers should also work.

Try the following:

dnstest -name www.heise.de -nameserver 8.8.8.8

That says to resolve www.heise.de using the Google name servers.

What nameserver are you using in your MTCP configuration file?

-Mike

[Guido Lehwalder]

Hi Mike,

I'm ashamed to write it, but it was an user (me) error and not the fault of MTCP.

While migrating MTCP from SLIP (ethersl Packet-Driver) to Ethernet I was
smart enough to activate the new E100PKT-Packet-Driver,
but missed  to comment out (with a REM) the line

MTCPSLIP=TRUE

in my CONFIG.BAT 

(MTCPSLIP=FALSE doesnt seem to do the same as commenting it out)

I would like to apologize for my fault ;)
MTCP is a real cool piece of software - many thanks for that.

It was also not the fault of my Router, Wifi-Ethernet-Bridge

nor my ISP :)

Maybe my fault will help in the future another user when this strange
behaviour does reapear.

Kind regards and many thanks for the quick help & email-replys :)
Have a nice start in ther new week!

Guido

[Michael Brutman]

I'm glad you figured it out but I'm confused.  The presence of the environment variable just "stuffs" an entry in the ARP table for the gateway, which is irrelevant on a SLIP connection as those are point-to-point.  However, the dummy ARP table entry satisfies the need to do figure out the next hop address, as regular ARP is not available on a point to point connection.

The dummy ARP entry is set to the broadcast address though, which is probably what causes the problem - I still think that something else responded to the DNS query, and your DOS machine using a broadcast address when talking to the gateway might have triggered another machine on your network to answer (and refuse) the DNS query.

I'll try that experiment here to make sure that was the root cause of the problem.