Re: DEQNA on MicroVax II

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I am using=C2=A0 a hub that bridges 10baseT and 10base5 which I used
> many years ago for this same purpose when I had VMS running.

Good, one potential problem down.

> I'm pretty sure that nobody else is replying to pinging as the
> replies are coincident with the operation of the uVax. Surely the
> known issues couldn't stop a ping?

If you're talking about Johnny Billquist's
	There are some known issues with the DEQNA, specifically it
	might stop sending/receiving under some circumstances, because
	of bugs in the microcode.
then yes, they will stop pings same as they'll stop all other traffic.
But they won't stop pings in just one direction, and, if the VAX has
anything to send it will eventually kick the hardware to wake it back
up again (this is the "qe0: xmit logic died, resetting..." that I
brought up in another thread).  And, as I remarked, it doesn't explain
pings failing in only one direction.

> I am using IP addresses, [...].  I have nmapped the network many
> times and know al the mac addresses and IPs assigned by reservation
> on my DHCP server.

Okay, another potential problem down.

> I don't have any other machines with spare disks that I could put
> NetBSD on, but if this can't be resolved any other way I could
> probably buy an old PC and run it headless to do that :-)

Well, possibly; a lot of PCs don't like running headless.  Unless by
"headless" you mean "with no monitor connected" rather than "with no
video output device", in which case they should be fine.

> It is the same whether I use either xcvr.=C2=A0=C2=A0 I cannot find
> any data on what DEQNA parameters I can change on any NetBSD
> documentation.

Probably at least partly because there aren't very many parameters in
the first place.  The DEQNA is pretty old from a modern perspective; I
was using them in the '80s.

> I suppose slip over the console might work, but I have no other
> serial port other than a dhv11!

A DHV11 serial port would be even better, as it wouldn't get output
intermixed with console output, and I *think* would be lighter load on
the CPU.  I was trying to assume you had no hardware you didn't
specifically mention, and you didn't mention any Qbus serial port
hardware.

Or do you mean that none of your *other* machines have serial ports on
them and thus you have nothing to use as the other end of the link?

Some things that might help track this down (I'm fishing for clues,
here, trying to put together some kind of theory of what's going
wrong):

You might try using ping -s 300 or some such to ensure that the ping
packets are nowhere near the minimum size.  If that makes it work, then
you can be moderately sure it's some kind of packet size issue.

Also, does pinging *from* the MicroVAX work immediately after pinging
*to* it from elsewhere?  I'm wondering if there are ARP issues
involved.  (Though I'm admittedly having trouble coming up with a
consistent theory that makes traffic work both ways when the other host
pings but not when the MicroVAX pings.)  Also relevant might be
checking the ARP table on the VAX and on the external host(s) involved
("arp -na" on the NetBSD VAX; I don't know how to check that on Linux)
to see if perhaps one of them is missing an ARP entry you'd expect it
to have.

When the VAX does the pinging, does the target host see the packets?
Obviously, the VAX isn't seeing any replies, but that could be a
failure of sending or a failure of receiving.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B