From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 16 Oct 1996 22:47:44 -0400
From: Scott Schwartz schwartz@galapagos.cse.psu.edu
Subject: unmatched replies
Topicbox-Message-UUID: 4f769286-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19961017024744.kr-fhnZEVOi8XSK7jWBZxLH0LRQ3ECdv67pyE3rZ2IU@z>

forsyth@plan9.cs.york.ac.uk writes:
| the `unmatched reply' diagnostic is easy to generate by
| interrupting a (user level) file server that queues requests and replies
| to them out of issuing order but doesn't (quite) cope with Tflush/Rflush.

That sounds familiar: I was interrupting things, like new instances of
telnet which had hung waiting for packets to come back.  (This is over
ppp, so I could see from the LEDs that there weren't any.)

| dnsiplookup in ndb/cs might be a good place to start looking in your case,
| but i'm just guessing.

That's plausible, I agree.  Once things got confused, starting a new
telnet would induce the error message, and a name lookup is pretty much
the first thing it does.

| it depends what you were trying to do when you noticed that the routing
| tables had changed ...

Pretty much just trying to log in again.