On 2013-02-25 15:07, Jordi Guillaumes i Pons wrote:
Please add this node to the nodelist:
7.74 BITXOW (SIMH VAX 8600, OpenVMS 6.1)
Thanks!
Say what? Have simh added VAX 8600 emulation? Do you know how accurate that is? I have plenty of code for NetBSD which plays with that machine (I have a real machine to work on).
Anyway, node added.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-23 07:19, Julian Wolfe wrote:
We actually got a VPN going, and this solved the problem. My machine is part of Area 18 now and is called FLIND (18.777).
Excellent. I'll drop you on my bridge then.
You can remove BIGBOA (1.42) for the time being.
Done. (As well as FLIND)
Johnny
On Feb 22, 2013, at 2:55 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-02-22 19:37, Julian Wolfe 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've hit the problem with mangled ports in the past. Yes, it certainly do matter for the bridge (or anything else using UDP). Not only a security issue, but you peer needs to know where to send his packets as well.
I have a hack to the bridge, which sortof adapts to this. Ping me sunday, when I have some more time...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-26 21:24, Clem Cole wrote:
That sounds right. I've forgotten many of these details.
IIRC: DEC had something called "regions" that were bastardized by the
screen handlers like termcap et al to do some of the same things.
Horton (termcap and terminfo author) or Kent (terminal firmware author)
might remember.
Yeah. You can use the scroll region to do insert/delete lines. However, there is no help for insert/delete character. You just have to send it all on a VT100.
Johnny
Clem
On Mon, Feb 25, 2013 at 5:30 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
As far as I know, the VT100 do not do insert and delete at all.
Those were added in the VT102...
That sounds right. I've forgotten many of these details.
IIRC: DEC had something called "regions" that were bastardized by the screen handlers like termcap et al to do some of the same things. Horton (termcap and terminfo author) or Kent (terminal firmware author) might remember.
Clem
On Mon, Feb 25, 2013 at 5:30 PM, Johnny Billquist <bqt at softjar.se> wrote:
As far as I know, the VT100 do not do insert and delete at all. Those were added in the VT102...
Johnny,
As part of the hub I'm setting up at my data centre, I'd like to also bridge directly to you. Could you please add a bridge to myst.platinum.net 199.166.5.172:4711. It is a static IP address. I have configured the bridge software on my end. let me know if I need to change the default destination of tempo.update.uu.se:4711.
Thanks!
Ian
Ok, one MAJOR rewrite later and this code is a little bit more sane.
One of the best parts is instead of the db returning little blurbs of "this is what changed" it now returns the inserted/updated/deleted rows as JSON that the python script can ingest and make much better decisions with.
I've got some ideas for stuff I want to add now but I'm pretty happy with where it is now.
I'm also open to ideas if you all have any.
My current TODO list is:
Use PySNMP instead of the net-snmp CLI tools:
Better control over what's going on. Non-responsive routers seriously blow up my snmp script file. Calling an external script is..... ugly and I don't like it.
Add exclusions:
exclude tunnels, so say from dave to peter's Uppsala location, for example
mesh/hub/spoke:
The question of "do we do a full mesh or just a few hubs" has been moved in my mind from being a global question to an individual question. You will be able to choose if you want to be mesh connected or hub connected.
GRE/IPsec:
Dave hasn't responded to that email yet, but if he has in mind what I think he does I'm going to add code that is smart enough to setup an IPsec tunnel between locations if both ends support it and GRE if they don't.
Only update needed:
This one is WAY low priority but my plan is to make the code smart enough to only update routers that need it. For example: if Cory's IP changes his router config doesn't actually need to change but everyone else's does. If Dave's source interface changes his router config needs to change but no one else's does. This is seriously OCD/pedantic territory, but that's me. :)
-brian
On 2013-02-25 22:43, Clem Cole wrote:
the ANSI spec was started before the vt100 project. I once had an mid ??1970's??? draft. but iirc it took a couple of years to go from draft to final spec.
decent started the vt100 using the vt52 sequences but because it was based on a micro (8080 iirc) there was a push to write ANSI compliant firmware. when ANSI was not finalized dec decided to put both modes in and ship.
again I've forgotten the details. as I recall the vt100 does not do insert and delete properly. again my memory is the first fully ANSI conforming product was the Ann Arbor Terminals Ambassador which was About 3 or 4 years post vt100 release. Clem
As far as I know, the VT100 do not do insert and delete at all. Those were added in the VT102...
Johnny
we had a bunch to test with which is why I remember that detail.
On Feb 25, 2013, at 3:22 PM, Ian McLaughlin <ian at platinum.net> wrote:
On 2013-02-25, at 12:18 PM, Johnny Billquist <bqt at softjar.se> wrote:
And yes, the VT100 predates ANSI, but it's not really incompatible, but there are a bunch of DEC private sequences, that are not in the ANSI spec.
I'm not aware of any incompatibilities with the ANSI spec, but feel free to point them out to me.
What's the history of the ANSI spec? I've always just assumed that it codified what was being used in the industry already.
Ian
the ANSI spec was started before the vt100 project. I once had an mid ??1970's??? draft. but iirc it took a couple of years to go from draft to final spec.
decent started the vt100 using the vt52 sequences but because it was based on a micro (8080 iirc) there was a push to write ANSI compliant firmware. when ANSI was not finalized dec decided to put both modes in and ship.
again I've forgotten the details. as I recall the vt100 does not do insert and delete properly. again my memory is the first fully ANSI conforming product was the Ann Arbor Terminals Ambassador which was About 3 or 4 years post vt100 release. Clem
we had a bunch to test with which is why I remember that detail.
On Feb 25, 2013, at 3:22 PM, Ian McLaughlin <ian at platinum.net> wrote:
On 2013-02-25, at 12:18 PM, Johnny Billquist <bqt at softjar.se> wrote:
And yes, the VT100 predates ANSI, but it's not really incompatible, but there are a bunch of DEC private sequences, that are not in the ANSI spec.
I'm not aware of any incompatibilities with the ANSI spec, but feel free to point them out to me.
What's the history of the ANSI spec? I've always just assumed that it codified what was being used in the industry already.
Ian
>Clem Cole wrote:
[Snip]
The problem is as Tom, says the unless you have a DEC keyboard layout, you are mapping something and that tends the be source of much discomfort.
I use the VT100 emulator under Ersatz-11 which provides
support to re-define keys. In particular, on a PC 104 key
keyboard, the <CTRL> key is in the wrong place and the
<SCROLL> / <NOSCROLL> key does not exist.
The solution was solved by the suggestion that John Wilson
makes for Ersatz-11 to use the <CapsLock> key as the
<LCTRL> key and I added my own definition to the
original <LCTRL> key to become the VT100 equivalent
of the <SCROLL> / <NOSCROLL> key with the
additional functionality that the Ersatz-11 KEYPRESS
sends the <CTRL/S> character and the KEYRELEASE
sends the <CTRL/Q> character. I found that since the
screen displays so quickly under Ersatz-11 that it was
impossible to react quickly enough to start and stop the
scrolling if the key had to be pressed twice as with the
actual VT100. So I do not have to hold the key down
permanently to hold the scrolling stopped, when I also
hold the <LSHIFT> key at the same time I am releasing
(KEYRELEASE), the <CTRL/Q> character is not sent.
These two changes managed to map the PC 104 key
keyboard to the VT100 as well as I can expect and I am
more than pleased with the results.
Jerome Fine
>Ian McLaughlin wrote:
The VT220 series are my favourite - nice and compact (compared to a Vt100).
I have SIX VT100 real DEC terminals on my desk.
They are stacked 2 high which I can't do with a VT220
unless I build a small shelf to hold the monitor and the
keyboard.
Otherwise, I agree that the VT220 LK201 keyboard
is quite a bit more functional over the VT100 keyboard.
Jerome Fine
