Circuit TCP-0-0, Adjacent node address out of range
Packet beginning = 0101800640020200002C0100FC010200
Both have maximum area set to 63, maximum node set to 1023, and both are routing IV.
What could I be missing?
The packet beginning shows node type = Level 1 router. So the area number is supposed to match, and it doesn't.
Isn't ROUTING IV level 2 router? EXEC TYPE is defined as that...or it
should be anyway.
Oh. Misread the HELP page. I wanted AREA not ROUTING.
paul
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
Circuit TCP-0-0, Adjacent node address out of range
Packet beginning = 0101800640020200002C0100FC010200
Both have maximum area set to 63, maximum node set to 1023, and both are routing IV.
What could I be missing?
The packet beginning shows node type = Level 1 router. So the area number is supposed to match, and it doesn't.
Isn't ROUTING IV level 2 router? EXEC TYPE is defined as that...or it should be anyway.
paul
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
Circuit TCP-0-0, Adjacent node address out of range
Packet beginning = 0101800640020200002C0100FC010200
Both have maximum area set to 63, maximum node set to 1023, and both are routing IV.
What could I be missing?
The packet beginning shows node type = Level 1 router. So the area number is supposed to match, and it doesn't.
paul
Circuit TCP-0-0, Adjacent node address out of range
Packet beginning = 0101800640020200002C0100FC010200
Both have maximum area set to 63, maximum node set to 1023, and both are routing IV.
What could I be missing?
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
node = 7.61 (BITXOO)
NCP>
%%%%%%%%%%% OPCOM 1-MAY-2013 18:46:32.05 %%%%%%%%%%%
Message from user DECNET on BITXR1
DECnet event 4.7, circuit down, circuit fault From node 7.92 (BITXR1), 1-MAY-
2013 18:46:32.05
Circuit TX-1-7, Line synchronization lost
My setup is as follows:
7.92 (experimental machine):
sim> show vh
VH address=20000140-2000017F*, vector=2C8-2E4*, lines=32, 4 units
VH0 attached to
32011,Line=15,Connect=192.168.0.8:32024;notelnet,32024;notelnet, DHV
mode, 1 connection
VH1 DHV mode
VH2 DHV mode
VH3 DHV mode
BITXOO:
sim> show vh
VH address=2013E140-2013E14F*, vector=E8-EC*, lines=16
attached to
32023,Line=15,Connect=192.168.0.2:32024;notelnet,32024;notelnet, DHU
mode, Modem
Hangup, 2 connections
sim>
BITXOO is running VMS 4.7, and it is a simulated 780. The other machine is
running 7.3 and it is a virtual 3900...
Anyone has been succesful setting this thing up?
Hmmm... I've tested this with DZ devices on windows hosts and not seen circuits popping up and down...
I would work with the DZ device first. It has been tested and had its modem related behaviors more solidly verified.
By the way, you shouldn't need to disable telnet as long as you have the telnet setting the same on both ends of the connection (i.e. notelnet<->notelnet or telnet<->telnet). The telnet setup we are using provides an 8 bit clean binary telnet channel.
I would make sure that you've have MODEM and HANGUP settings enabled on both ends (from the simh perspective).
What do you have for /MODEM and /HANGUP settings on the VMS ports?
If you can confirm good behavior on the DZ devices and bad on the VH we can explore why...
- Mark
Circuit TX-1-7, Line synchronization lost
My setup is as follows:
7.92 (experimental machine):
sim> show vh
VH address=20000140-2000017F*, vector=2C8-2E4*, lines=32, 4 units
VH0 attached to 32011,Line=15,Connect=192.168.0.8:32024;notelnet,32024;notelnet, DHV mode, 1 connection
VH1 DHV mode
VH2 DHV mode
VH3 DHV mode
BITXOO:
sim> show vh
VH address=2013E140-2013E14F*, vector=E8-EC*, lines=16
attached to 32023,Line=15,Connect=192.168.0.2:32024;notelnet,32024;notelnet, DHU mode, Modem
Hangup, 2 connections
sim>
BITXOO is running VMS 4.7, and it is a simulated 780. The other machine is running 7.3 and it is a virtual 3900...
Anyone has been succesful setting this thing up?
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
I was able to find DECNET-20 documentation which is unfortunately not what you're looking for. ;(
(BTW the "buffered console" feature in 4.0 is also awesome, specially to run headless simulators. Now if we could do an unattended RSX boot it would be wonderful!).
Yes, an unattended RSX boot WOULD be nice. ;)
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
On Feb 22, 2013, at 12:45 PM, Cory Smelosky <b4 at gewt.net> wrote:
--
Cory Smelosky
Sent from a mobile device
On 22 Feb 2013, at 13:37, Julian Wolfe <julian at twinax.org> wrote:
HI all,
Registered on HECnet many years ago, but was never able to get on for long or at all in the past. Now it seems this problem plagues me yet again in a different form.
I've got a PDP-11/23+ running RSTS/E 10.1 and DECnet/E 4.1 behind a DD-WRT router in my basement (WRT54GS, DD-WRT build 13064), and this is behind an AT&T U-Verse router. Something is going on with the packet source ports - they are being marked with a randomized source port.
My questions are: Does the source port matter, when using Johnny's bridge, and he knows my port?
If the port does matter, has anyone experienced this issue (specifically on AT&T U-Verse or otherwise) and solved it?
Is this something I can fix myself, or do I need to look for another solution?
The wierd part is, I used the bridge successfully for 2 days with the bridge installed on a Mac running Mac OS X 10.8. This machine was also talking through a different WRT54GS with DD-WRT build 13064 and identical settings to the other router (client bridged mode). I then moved the PDP to the basement with the rest of my servers, had it go through the linux box for the bridge, and suddenly the packets have this mangles source port. I tried switching it back to the Mac, and now this problem has cropped up there too.
Phew! Help! I just want to hang out with yous guys :)
I can't speak for Johnny's bridge, but you can use a virtual Cisco to join up if all else fails...assuming you can forward GRE.
Julian
