DOS ain't dead

Hi everyone.

I ususally don't announce for NDN here myself, but since
the latest release of NDN for DOS contains a FTP implementation
I'd like to ask interested users of this forum to try it out.

You need a working packet driver installed for this to work.
The rest should work out of the box.

http://ndn.muxe.com/download/
http://forums.muxe.com/index.php?showtopic=3226

Thanks for your time,
Stefan / AH

Hello Stefan!
Thanks for your effort!

I downloaded and tried this new version.
Unfortunately the FTP stuff doesn't work for me. I tried it on two computers - with Realtek RTL8129 and Realtek RTL8139 but the result is the same:
if I want to connect to FTP site it reports error message Socket error 11001 "GetHostByName(): Failed"
Tried with WATTCP.CFG variable set (in WATTCP.CFG file I have manualy written my network configuration) and also without this variable - so it should use DHCP.
Other my DOS internet software works fine.

I don't know what is bad. Maybe wold help some debug version of NDN which would create some log file about network proceses?

---
DOS-u-akbar!

> I ususally don't announce for NDN here myself, but since
> the latest release of NDN for DOS contains a FTP implementation
> I'd like to ask interested users of this forum to try it out.
>
> You need a working packet driver installed for this to work.
> The rest should work out of the box.
>
> http://ndn.muxe.com/download/
> http://forums.muxe.com/index.php?showtopic=3226

I don't use Linux much except to screw around on liveCDs occasionally, but I did download NDN for that "just in case." However, I don't see the binary! I think you left it out!

P.S. Note to everybody else: URL has changed, update your bookmarks!

---
Know your limits.h

> I ususally don't announce for NDN here myself, but since
> the latest release of NDN for DOS contains a FTP implementation
> I'd like to ask interested users of this forum to try it out.
>
> You need a working packet driver installed for this to work.

It works for me.

> The rest should work out of the box.

Probably - if one can recall the strange "#:" syntax ( I needed about 10 minutes for that ).

I also tried to connect to my site, which requires a userid+password. This "didn't work" first, NDN was able to connect, but an empty panel was shown only. I then left NDN and removed the entry in file ftp.ini. When I restarted NDN, it automatically tried to connect again to my site and this time it was able to show the contents!?! This is a slightly "unexpected" behavior.

---
MS-DOS forever!

Hi Laaca.

I have some sample executables that I used while developing
the IP stack and FTP support. I have uploaded them here:
http://bnhof.de/~ho1459/files/samples.rar

You should try dhcptest or ping.
Both display a lot of statistics on the network setup.
I guess this should help us to find the reason for the
failing GethostbyName() call.

Thank you for your time,
Stefan / AH

> I don't use Linux much except to screw around on liveCDs occasionally, but
> I did download NDN for that "just in case." However, I don't see the
> binary! I think you left it out!

Thank you, RAR handles wildcards differently than 7Zip.
The executable was excluded from the archive.
I've uploaded a complete archive.

Thanks again,
Stefan / AH

> > You need a working packet driver installed for this to work.
>
> It works for me.

That's good news!

> > The rest should work out of the box.
>
> Probably - if one can recall the strange "#:" syntax ( I needed about 10
> minutes for that ).

"Strange"? :P
It fit's into NDN quite well - I couldn't have done it much better I guess. :P
You can also open directories or VFS' via ALT-F1/F2.

> I also tried to connect to my site, which requires a userid+password. This
> "didn't work" first, NDN was able to connect, but an empty panel was shown
> only. I then left NDN and removed the entry in file ftp.ini. When I
> restarted NDN, it automatically tried to connect again to my site and this
> time it was able to show the contents!?! This is a slightly "unexpected"
> behavior.

I think this has nothing to do with the FTP.INI editing.
Probably the directory parsing has failed.
CTRL-R to reread the directory probably would have also solved the problem.

Thanks for your time,
Stefan / AH

> > time it was able to show the contents!?! This is a slightly
> "unexpected"
> > behavior.
>
> I think this has nothing to do with the FTP.INI editing.
> Probably the directory parsing has failed.
> CTRL-R to reread the directory probably would have also solved the
> problem.

The main problem is not that it did show an empty directory first, the main - security - problem is that NDN obviously caches userid + password and still remembers them even after I deleted the entry in ftp.ini.

Admittedly one can argue that the FTP protocol is inherently insecure and therefore this unwanted "restoration" of sensible data isn't such an issue, but still...

---
MS-DOS forever!

> > > time it was able to show the contents!?! This is a slightly
> > "unexpected"
> > > behavior.
> > I think this has nothing to do with the FTP.INI editing.
> > Probably the directory parsing has failed.
> > CTRL-R to reread the directory probably would have also solved the
> > problem.
>
> The main problem is not that it did show an empty directory first, the
> main - security - problem is that NDN obviously caches userid + password
> and still remembers them even after I deleted the entry in ftp.ini.
>
> Admittedly one can argue that the FTP protocol is inherently insecure and
> therefore this unwanted "restoration" of sensible data isn't such an
> issue, but still...

Ah, I see:
When you quit NDN while having an FTP connection open the FTP data
is saved to the desktop file, and restored on restarting NDN.
On my todo list is a plan for encryption of passwords etc.
Maybe even better the complete URL in case of FTP.
But I don't know when or how... :P

> > Probably - if one can recall the strange "#:" syntax ( I needed about
> > 10 minutes for that ).
>
> "Strange"? :P
> It fit's into NDN quite well - I couldn't have done it much better I
> guess. :P

It's an inconsistent user interface. There is such a huge menu system in NDN which is supposed to navigate through all of NDN's features, but to open the FTP dialog you need to enter a cmdline command.

As an example for a consistent user interface see "Far Manager": There's an FTP entry in the menu which is opened with ALT-F1/F2.

---
MS-DOS forever!

I ran your utilities and here are the results.
The first listing is done when my WATTCP.CFG is disabled (renamed), the other ones are with WATTCP.CFG enabled with fixed settings.
-----------------------------------------------------------------
C:\NDN2\TEST>dhcptest
Driver information:
name = PCIPKT
version = 11 class = 1 type = 54 number = 0 func = 2

TPacketDriverAdapter.PrintInformation(): Couldn't get packet driver parameters!
TPacketDriverAdapter.PrintStatistics(): Couldn't get packet driver statistics!
Parsing environment...
Match: wattcp.cfg -> wattcp.cfg=c:\freedos\bin
Store: c:\freedos\bin
Parsing file(s)...
Parse: (.;C:\NDN2\TEST\;C:\FREEDOS\BIN;C:\KOMP;C:\BAT;C:\UTIL\HXRT\BIN;\;c:\fre
edos\bin\)
IP configuration for 0.0.0.0:
Ethernet address: 00:00:E8:5A:1A:93
DHCP server : 10.1.2.1
NetMask : 0.0.0.0
DNS server : 0.0.0.0
GateWay : 0.0.0.0
Could not resolve host name "http://google.com".
Driver information:
name = PCIPKT
version = 11 class = 1 type = 54 number = 0 func = 2

TPacketDriverAdapter.PrintInformation(): Couldn't get packet driver parameters!
Driver statistics:
packets in = 109 out = 132 lost = 64
bytes in = 43046 out = 16381
errors in = 0 out = 0
---------------------------------------------------------------------

---------------------------------------------------------------------
C:\NDN2\TEST>dhcptest
Driver information:
name = PCIPKT
version = 11 class = 1 type = 54 number = 0 func = 2

TPacketDriverAdapter.PrintInformation(): Couldn't get packet driver parameters!
TPacketDriverAdapter.PrintStatistics(): Couldn't get packet driver statistics!
Parsing environment...
Match: wattcp.cfg -> wattcp.cfg=c:\freedos\bin
Store: c:\freedos\bin
Parsing file(s)...
Parse: c:\freedos\bin\wattcp.cfg (.;C:\NDN2\TEST\;C:\FREEDOS\BIN;C:\KOMP;C:\BAT;
C:\UTIL\HXRT\BIN;\;c:\freedos\bin\)
Match: my_ip -> my_ip=10.1.2.198
Store: 10.1.2.198
Match: netmask -> netmask=255.255.255.0
Store: 255.255.255.0
Match: nameserver -> nameserver=195.47.47.2
Store: 195.47.47.2
Match: nameserver -> nameserver=217.71.128.8
Store: 217.71.128.8
Match: gateway -> gateway=10.1.2.1
Store: 10.1.2.1
IP configuration for 10.1.2.198:
Ethernet address: 00:00:E8:5A:1A:93
DHCP server : 0.0.0.0
NetMask : 255.255.255.0
DNS server : 217.71.128.8
GateWay : 10.1.2.1
Could not resolve host name "http://google.com".
Driver information:
name = PCIPKT
version = 11 class = 1 type = 54 number = 0 func = 2

TPacketDriverAdapter.PrintInformation(): Couldn't get packet driver parameters!
Driver statistics:
packets in = 9 out = 22 lost = 37
bytes in = 2232 out = 2730
errors in = 0 out = 0
---------------------------------------------------------------------

---------------------------------------------------------------------
C:\NDN2\TEST>ping
Ping target: http://google.com
IP configuration for 0.0.0.0:
Ethernet address: 00:00:E8:5A:1A:93
DHCP server : 10.1.2.1
NetMask : 0.0.0.0
DNS server : 0.0.0.0
GateWay : 0.0.0.0
Destino M scara Gateway IP Local Costo
--------------- --------------- --------------- --------------- -----
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 0
Could not resolve host name "http://google.com".
---------------------------------------------------------------------

---------------------------------------------------------------------
C:\NDN2\TEST>pktinfo
Driver information:
name = PCIPKT
version = 11 class = 1 type = 54 number = 0 func = 2

TPacketDriverAdapter.PrintInformation(): Couldn't get packet driver parameters!
TPacketDriverAdapter.PrintStatistics(): Couldn't get packet driver statistics!

---
DOS-u-akbar!

Hi Laaca!

> Driver information:
> name = PCIPKT
> version = 11 class = 1 type = 54 number = 0 func = 2
>
> TPacketDriverAdapter.PrintInformation(): Couldn't get packet driver
> parameters!
> TPacketDriverAdapter.PrintStatistics(): Couldn't get packet driver
> statistics!

Ok, parameters are not supported if func=2, but statistics should work
here too, as they did after sending the first packets...

> IP configuration for 0.0.0.0:
> Ethernet address: 00:00:E8:5A:1A:93
> DHCP server : 10.1.2.1
> NetMask : 0.0.0.0
> DNS server : 0.0.0.0
> GateWay : 0.0.0.0

Hm, it seems that the software was able to detect the DHCP server.
I have added debug code to the DHCP code.
Please try this:
http://bnhof.de/~ho1459/files/dhcp00.rar

> IP configuration for 10.1.2.198:
> Ethernet address: 00:00:E8:5A:1A:93
> DHCP server : 0.0.0.0
> NetMask : 255.255.255.0
> DNS server : 217.71.128.8
> GateWay : 10.1.2.1

The parsing of the cfg file also seems to work.

Strange, let's see what the new tool shows (I guess it is stopping on
the DHCP request...).

Thank your helping me,
Stefan / AH

Hi Jap!

> It's an inconsistent user interface. There is such a huge menu system in
> NDN which is supposed to navigate through all of NDN's features, but to
> open the FTP dialog you need to enter a cmdline command.

NDN behaves very consistently:
a) Open drives/VFS/directories via ALT-F1/F2
In Options.File Manager.Setup.Behaviour you will find the option
"[ALT-F~1~/F2] Show VFS" - turn it on.

b) Open drives/VFS via the driveline with the mouse
Enable "Show VFS on Driveline" in the same configuration menu.
You should now see something like this:
[ C D E F G H I J K L M N X Z * ? # : ]

c) Open drives from the command line:
C: for drive C
*: for the temp VFS
#: for FTP...

If you want you might as well type the ftp URL on the command line
and NDN will try to connect to the server instantly.

> As an example for a consistent user interface see "Far Manager":
> There's an FTP entry in the menu which is opened with ALT-F1/F2.

I don't want to argue about the correct historical context on which
file manager existed first and what file manager introduced which
features first. ;)
A really good and interesting site on this is the OFM:
http://www.softpanorama.org/OFM/index.shtml
http://www.softpanorama.org/OFM/index.shtml#Comparison Table
http://www.softpanorama.org/OFM/Paradigm/Ch05/far.shtml
http://www.softpanorama.org/OFM/Paradigm/Ch03/dos_navigator.shtml

All the best,
Stefan / AH

> NDN behaves very consistently:
> a) Open drives/VFS/directories via ALT-F1/F2
> In Options.File Manager.Setup.Behaviour you will find the option
> "[ALT-F~1~/F2] Show VFS" - turn it on.

Thanks! Looks much better now!

> > As an example for a consistent user interface see "Far Manager":
> > There's an FTP entry in the menu which is opened with ALT-F1/F2.
>
> I don't want to argue about the correct historical context on which
> file manager existed first and what file manager introduced which
> features first. ;)

The "historical context" isn't that interesting. Relevant is the current status. And currently FM has this option enabled by default while NDN has it disabled - and an occasional user like me is very unlikely to ever find the correct way how to enable it ... without professional help.

---
MS-DOS forever!

> The "historical context" isn't that interesting. Relevant is the current
> status. And currently FM has this option enabled by default while NDN has
> it disabled - and an occasional user like me is very unlikely to ever find
> the correct way how to enable it ... without professional help.

One problem is that old (N)DN users don't like changes. :P
Many features that I enabled by default in the past because I
considered them quite useful resulted in complains by users...

I guess I should go through a virgin install of NDN and check what
useful options are disabled by default, then asking the users if they
mind if I enable them.

Thanks for making me think about that and for testing the FTP client.

Stefan / AH

OK, I tested the new version of your DHCPTEST.
With disabled WATTCP.CFG:

--------------------------------------------------------------------
C:\NDN2\TEST\I>dhcptest
Driver information:
name = PCIPKT
version = 11 class = 1 type = 54 number = 0 func = 2

TPacketDriverAdapter.PrintInformation(): Couldn't get packet driver parameters!
TPacketDriverAdapter.PrintStatistics(): Couldn't get packet driver statistics!
DHCP_ConfigIP(): DHCP_OP_DISCOVER failed!
IP configuration for 0.0.0.0:
Ethernet address: 00:00:E8:5A:1A:93
DHCP server : 10.1.2.1
NetMask : 0.0.0.0
DNS server : 0.0.0.0
GateWay : 0.0.0.0
Could not initialise IP stack. Wrong Parameters?!
--------------------------------------------------------------------
--------------------------------------------------------------------

And with WATTCP.CFG enabled:
--------------------------------------------------------------------
C:\NDN2\TEST\I>dhcptest
Driver information:
name = PCIPKT
version = 11 class = 1 type = 54 number = 0 func = 2

TPacketDriverAdapter.PrintInformation(): Couldn't get packet driver parameters!
TPacketDriverAdapter.PrintStatistics(): Couldn't get packet driver statistics!
IP configuration for 10.1.2.198:
Ethernet address: 00:00:E8:5A:1A:93
DHCP server : 0.0.0.0
NetMask : 255.255.255.0
DNS server : 217.71.128.8
GateWay : 10.1.2.1
Could not resolve host name "http://google.com".
Driver information:
name = PCIPKT
version = 11 class = 1 type = 54 number = 0 func = 2

TPacketDriverAdapter.PrintInformation(): Couldn't get packet driver parameters!
Driver statistics:
packets in = 241 out = 184 lost = 11
bytes in = 212418 out = 25373
errors in = 0 out = 0
--------------------------------------------------------------------
--------------------------------------------------------------------

Here I see a potential problem but I am not sure if it can be called "bug"
The "DNS server" shows my secondary server not the primary one.
This is fragment of my WATTCP.CFG file with original comments:
--------------------------------------------------------------------

# Notes: DHCP/BOOTP servers may add additional name-servers to the one(s)
# you specify here.
# There are no default server. There can be a total of 10
# nameservers. All name-server are queried in sequence (starting with
# the first listed below) until an IP-address is returned. Enter the
# fastest or closest name-server first for best result.
#
nameserver = 195.47.47.2 ; primary DNS, mandatory if not using DHCP
nameserver = 217.71.128.8 ; secondary DNS, optional

---
DOS-u-akbar!

Hello Laaca.

> DHCP_ConfigIP(): DHCP_OP_DISCOVER failed!
> IP configuration for 0.0.0.0:
> Ethernet address: 00:00:E8:5A:1A:93
> DHCP server : 10.1.2.1
> NetMask : 0.0.0.0
> DNS server : 0.0.0.0
> GateWay : 0.0.0.0

Apparently it does read the DHCP server but then exits when trying
to read the other parameters...

> DNS server : 217.71.128.8
> Here I see a potential problem but I am not sure if it can be called
> "bug"
> The "DNS server" shows my secondary server not the primary one.

The config parsing of NDN is pretty modular and flexible but behaves quite simple in this case: it overwrites the previously parsed parameters with new ones if another parameter of the same type is found.
Maybe it should save only the first occurance?!

But this can't be the problem we have here,
I think that the packet handling is broken.
The PCIPKT driver behaves different from the drivers I know.

I have uploaded a new version of dhcptest:
http://bnhof.de/~ho1459/files/dhcp01.rar

Besides the screen output there wil be a debug file on drive C:\ called
vp_debug.txt. The output of the file is probably too big to post it here.

I think it is enough if you only do the DHCP test with wattcp.cfg disabled,
since the fix to the DHCP problem might also fix the problem if all parameters
are parsed via wattcp.cfg.

Thanks a lot for your help,
Stefan / AH