>In article <H000006600031be3@MHS>, [log in to unmask] says:
>>
>>I've got a customer with a DTC problem which no one has been able to
>>figure out yet.
>>
>>They have a pair of routers which are configured as bridges, and a
>>DTC16iX on the other end. Everything was working fine, then they
>>messed with the network on the DTC end. They now claim to have put
>>everything back the way it was however.
>>
>>The DTC downloads fine from the 3000.
>>
>>TERMDSM says it is fine, status and everything looks good.
>>
>>Spooled and hot printers on the DTC work fine.
>>
>>Sessions can be started on the DTC ports with :STARTSESS and work.
>>
>>But, if a user hits <CR> on a logged-off terminal, they immediately
>>get a "Cannot Establish Connection" error.
 
I experienced a similar problem at one site.  Perhaps this can explain the
problem:  The network was changed from a bridge between the DTC and the
HP3000, to a router with bridging enabled.  The net result was everything
worked successfully until the DTC was reset.  The download to the DTC worked
but no connection from a DTC port to the host worked.
 
We found the problem to be the one-time HP Probe broadcast from the DTC to
resolve the address for the HP host.  HP Probe is a UDP/IP packet with a wierd
broadcast destination address.  The router was bridging all AFCP packets fine,
but was not passing the UDP/IP packet forward since it acted as a router for
this known protocol.  The short term solution is to disable all routing on the
router whenever the DTC needs to be reset. Then make an initial connection to
the host through the DTC.  The router can then be changed back to routing IP
and all future DTC connections will work... until the next DTC reset!
 
P.S. The problem does appear in reverse when the HP3000 is rebooted. The first
attempt to open a printer port will fail until the above process is repeated.