[Coco] DriveWire 4 server version 3.9.98

[Aaron Wolfe]

2011/10/25 gene heskett <gheskett at wdtv.com>:
> On Tuesday, October 25, 2011 07:46:13 AM Aaron Wolfe did opine:
>
>> Hi Coconuts,
> [...]
>> This is somewhat experimental so please use with caution until it's well
>> tested.  Especially with disk images from remote source (web sites, ftp,
>> etc) the last modified date may not be reliable.
>> If the server finds that the source timestamp has changed whilst it has
>> uncommitted changes in it's buffer, it will warn you in the log but it
>> *will* overwrite the source with it's version.
>>
>> -Aaron
>>
> Hi Aaron;
>
> I'm back from Cinci, with a cold thats really a drag.  I put the newest
> .jar in just now.  And last night, I blew myself away by making another
> boot floppy for the coco3 while booted to the previous drivewire enabled
> disk. The reason for my amazement was that format needs about 7k of free
> ram, and smap said I only had 4!  But it worked, and I added a few more /n#
> descriptors.
>
> I have also setup the printers filepath, and added my cocodw daemon to
> GO.sh, so theoretically I should be able to print, but haven't tested that
> yet.
>
> I also found a src of USB-2.0 extension cables that I thought when I
> ordered them, were 15 feet long, which would just barely reach, but when
> the order came in, they were 10 meters long, way beyond the USB-2.0 spec,
> but the one I installed last night works well and signs on at 480Mbs.
>
> From a lsusb:
> Bus 001 Device 015: ID 1a40:0201 TERMINUS TECHNOLOGY INC.
>
> I also bought a 10 port hub for the cocos desk, and all this runs over that
> 33 foot extension cable now.  This includes a ser-usb connection from /t2
> running at 9600 baud.  This, sacia etc are what I want to remove from the
> bootfile & use something like putty over one of the /n connections, which
> should free at least 3 to 5k of system ram.
>
> But, at this point I think I need some inetd or puttytel help.  I can't get
> anything but a connection refused out of puttytel to localhost 6809.
>
> So, what should my inetd.conf, which is:
>
> 6809 telnet protect banner,login,
> 6810 proc,
>
> be set to, or, what is the correct puttytel invocation?
>
> This:puttytel -telnet -P 127.0.0.1:6809
> opens puttytel's configuration screen, I then fill in the IP, on port 6809,
> hit "open", which opens a greyed out small window, and a full brightness
> "connection refused" box, which when ok is clicked goes away, along with
> the greyed out window.  This is true for localhost 6809, 192.168.xx.xx
> 6809, or the FQDN of this machine.  Also true if I just use putty -telnet.
>
> Probably an attack of dumbass, or -ENOTENOUGHCAFFEINE, but its not working
> and staring at the putty man page isn't helping.
>
> inetd is running:
> {t2|07}/X1/NITROS9/6309L2:proc
>
>  ID Prnt User Pty  Age  Tsk  Status  Signal   Module    I/O Paths
> ___ ____ ____ ___  ___  ___  _______ __  __  _________ __________________
>  1   0    0  255  255   00  sTimOut  0  00  System    <Term >Term >>Term
>  2   1    0  128  128   00  s        0  00  Shell     <Term >Term >>Term
>  3   7 0 128 128 02  s        0  00  Proc      <t2   >t2   >>t2
>  5   0    0  128  131   00  s        0  00  Shell     <W4   >W4   >>W4
>  6   0    0  128  129   00  s        0  00  Shell     <W1   >W1   >>W1
>  7   0    0  128  131   00  s        0  00  Shell     <t2   >t2   >>t2
>  8   0    0  128  128   00  s        0  00  inetd     <DD   >Term >>Term
>
> Clues?  LART's?


We need to determine if A -the server is listening, but Putty can't
get to it, or B - the server just isn't listening.

The easiest way would be to issue the 'dw net sh' command, here's what
the output looks like here:

{N2|04}/DD:dw net sh

DriveWire Network Connections:

Connection 0: mfalconVII:62367 (connected to port /N2)

Listener 0: TCP port 6809 (control port /N1)
Listener 1: TCP port 6810 (control port /N1)
Listener 2: TCP port 6811 (control port /N1)


The significant part is that we have listeners for the TCP ports we
want to accept connections on registered via /N1 (the port inetd is
using for control).

If you are not having luck with the dw command in OS9, you can issue
the same command using the DW4 GUI client, just type it in the box at
the bottom of the screen.

So.. if we have listeners registered, then we know inetd at least told
the server it's intentions.

Next step is to see if the server is indeed listening.  For this you
can use the "dw server show threads" command:

{N2|04}/DD:dw server sh th

DriveWire Server Threads:

                       Reference Handler  10 system   WAITING
                               Finalizer   8 system   WAITING
                       Signal Dispatcher   9 system   RUNNABLE
                         Attach Listener   5 system   RUNNABLE
                              dwserver-1   5 main     TIMED_WAITING
                            dwproto-0-10  10 main     RUNNABLE
                            dskwriter-11   1 main     TIMED_WAITING
                           dwUIserver-12   5 main     RUNNABLE
                           tcplisten-167   5 main     RUNNABLE
                           tcplisten-168   5 main     RUNNABLE
                           tcplisten-169   5 main     RUNNABLE
                             tcpserv-206   5 main     RUNNABLE
                              dwutil-484   5 main     RUNNABLE

{N2|04}/DD:


Note there are 3 tcplisten threads in the runnable state.  the id #s
are not significant, but the fact that there are 3 and I am listening
on 3 ports is a very good sign.  Again we need to know if this is the
same on your system.

If all is well so far, you can be fairly sure that the server is
indeed ready for connections, and I would start looking at Putty
issues or perhaps local firewall rules.  On the other hand, if you do
not see these results on your system, the problem is within the
DriveWire portion of the puzzle.  Let me know what's different in that
case.

It may be helpful to turn logging up to DEBUG and take a look at
what's said during a connection attempt.   The logs can map the pids
in the thread output to individual TCP ports, i.e.:

22:43:18: [tcplisten-167 ] tcp listening on port 6809
22:43:18: [tcplisten-168 ] tcp listening on port 6810
22:43:19: [tcplisten-169 ] tcp listening on port 6811

Also, if Putty is managing to get to the server at all, you will see a
line like:

22:43:50: [tcplisten-167 ] new connection from 192.168.128.50

even if nothing else works, seeing that line lets us know you do have
communication between putty and the server.  that would be good to
know.

-Aaron