Yet another netcat for DOS

[wiwa64]

As already announced in the thread "IRCjr updates, Netcat, and DHCP Client",
i too wrote an incarnation of the famous program "netcat" for (MS-)DOS.
To avoid confusion with other variations of this program, i gave it the name ntool.

Please feel free to download and use it. Should you do so and use it, i would appreciate some feed-back.

Please don't use this version (1.2) anymore, as it appears to have a bug.
Rather use the bugfixed version (1.3) further below in this thread instead.

 

[mbbrutman]

It looks very full featured! I need some help though ..

DHCP: I was not able to use DHCP. I created a WATTCP.CFG file that looked like this:

my_ip=
netmask=
gateway=
nameserver=

Then I ran ntool -g "set " and expected to see good parameters, but the IP addr was set to 0.0.0.0, netmask was 255.255.254.0, etc. What did I miss?

If I used my own DHCP client I received good parameters and was able to create a WATTCP.CFG file with them that worked.


DNS: 'No workie'. If I provided an IP address it was fine, but if I used a name it failed immediately.


Any ideas on these two problems?

 

[wiwa64]

well, that's easy

If you want to use DHCP, then you have two options.
Either you have no WATTCP.CFG at all. In this case however, you might get an error message, even though it works fine.
Or, if you want to avoid this ugly message, you should have a WATTCP.CFG file with only one line: my_ip=dhcp

Then, ntool itself should work fine. If you have got programs, that do not support dhcp properly,
you can then use the -g switch to generate a WATTCP.CFG file to be used by the other programs.
Typically you would use this procedure once during system boot and then use the WATTCP.CFG file obtained this way.

I hope this will help you.

 

[wiwa64]

DNS: 'No workie'. If I provided an IP address it was fine, but if I used a name it failed immediately.

Well, with this one i am not quite shure.
I must admit, i only tested it in my local lan,
and always used ip-addresses.

I could however imagine, that it's a follow-up problem,
a consequence of not having properly set-up the nameserver entry.
So try to fix the dhcp problem first, then try again.

 

[mbbrutman]

Not having a WATTCP.CFG file does not work. But having a file with just 'my_ip=dhcp' worked fine.

DNS does not work under any circumstances, even when the DHCP server provides the correct NAMESERVER address. You might want to try it to confirm the problem.

(My netcat doesn't even have it yet, but that's a matter of laziness ...)

 

[wiwa64]

Unfortunately you didn't specify, what "does not work" means
precisely, when trying DNS.

I now tryed it too and it indeed didn't work for me as well.
In my case "does not work" means, i get the error message
"ERROR: Unable to resolve host: ", followed by the correct
host name. This is significant in so far, as it means, the
resolve function is apparently called with the correct name,
and it suggests, that something within the resolver must
go wrong.

If you look into the source code, you will find, how i call
the resolver:

    if(!(remoteip = resolve(host))) {
      fprintf(stderr,"ERROR: Unable to resolve host: '%s'\n", host);
      return(3);
      }

And if you compare that to how it is done in one of the
example programs (ping) that come with the WATTCP lib:

    if (!(host = resolve( name ))) {
        printf("Unable to resolve '%s'\n", name );
        exit( 3 );
    }

you will hardly find any significant difference.

The resove function which is called in these code segments,
is part of the WATTCP library, which i just link to my program.
Even though i had a quick look into the source code of the
library, i diddn't find any obvious reason.

So i am puzzled and cannot promise you a quick solution for that particular problem.

 

[mbbrutman]

I'll be more specific:

C:\ntool -i brutman.com:80
ERROR: Unable to resolve host: 'www.brutman.com'

Does not work at all and returns me to the DOS problem immediately.

ntool -i 209.216.205.162:80 works as expected.

 

[wiwa64]

So that's exactly the same kind of behaviour i see when trying to use a hostname instead of an ip-address.

I still don't know why, but inspecting the process with an ethernet analyser shows, that it even doesn't attempt to resolve the address.

Whether this is a problem of my code calling the resolver (see above),
or a problem inside the WATTCP library, on wich i simply rely,
or a consequence of some totally different part of my code,
that only shows up at this very unexpected place, i still don't know.

Have you seen more problems, or is this the only one so far ?

 

[wiwa64]

Luckily it wasn't quite as difficult as i suspected initially,
so i could find the problem and even fix it.

Please try the attached bugfixed version 1.3 to see if it works for you.

(By the way, is there a method to withdraw the buggy attachment to my posting at the beginning of this thread ?)