Circuit TCP-0-51, Adjacent node = 5.10 (MICRO1) In this case it was node 51.10 but it's not unique to that machine - I've seen the same problem from time to time on the other links as well. It's always a transient problem; the link comes back up on its own in a minute or so. It seems to come in "clusters" - I'll get a whole bunch of these errors logged one afternoon, and then everything will be stable for a day. It's not always an "unexpected packet type" error; sometimes it'll just be a "listener receive timeout" instead. Given that Multinet uses UDP it almost looks like UDP packets are getting lost or trashed sporadically. So many people are running Multinet links now - does anybody else have this problem? Has anybody figured out the cause or a fix? Hi Bob, I've seen 17 of these on the link we've set up between us. The first one came hours after we started and I thought it was might have been you doing something at your end. Then there was a long interval before the next one and those that followed. I've not seen any bunches (except on December 26th when there were five of them, but even then they were well spread out). Maybe that's because I've only got one Multinet circuit? The latest one is included below. Time is GMT. I didn't notice any other networking grief at the time. I've also managed to provoke one of these when testing a Multinet link over a local ethernet connection when I shut down the link. I think someone said they had details of the protocol used? It might be interesting to analyse the beginning of packet logged to see if it is just noise or if it is close to being valid. Regards, Peter Coghlan. %%%%%%%%%%% OPCOM 8-JAN-2012 21:02:15.65 %%%%%%%%%%% Message from user DECNET on CEIRE DECnet event 4.18, adjacency down