Just wanted to update everyone on this. I work with Julie and we're working
on this together.
We've gotten some good advice (stuff we'd forgotten over the years too!) but
so far no progress.
Here's what we've done:
- due to a physical move, our test system (Albert) moved subnets.
- ensured both system have the proper node names and IP address in
NSDIR.NET.SYS
- verified IP connectivity between systems (ping tests)
- verified each server can DSLINE and open a remote system to the other
- verified that there are no firewalls or other devices blocking any ports
related to the problem.
But we still cannot DSCOPY from either system to the other.
We did some packet sniffing, and put the sniffer on the same physical LAN as
our production system (Herbert). He hasn't changed subnets and we haven't
changed his configs at all except to update the address he know for the test
system (Albert). So, when Albert tries to DSCOPY to Herbert, we see the
packets come from Albert to Herbert, but Herbert does not send a response
packet. We thought "maybe he's sending a packet back to Albert's old address
instead of his new one", but we verified that isn't happening. Herbert is
just eating that packet and ignoring it totally. Since the sinffer was
between Herbert and the gateway, it's clear that the router is not filtering
packets ... Herbert just isn't emitting one.
Then we did another test, and it blew our mind.
- DSCOPY from Albert to Herbert fails. BUT, if we DSLINE from Herbert to
Albert, start a remote session on Albert, and then DSCOPY back to Herbert,
the DSCOPY works.
- The reverse situation is also true: if we DSLINE from Albert to Herbert,
and then DSCOPY back to Albert, that works.
That should tell us something .. I'm just not sure what.
--
"He's old enough to know what's right and young enough not to choose it.
He's strong enough to win the world and weak enough to lose it." - Neal
Peart
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
