On 11 Mar 2013, at 16:37, "Bob Armstrong" <bob at jfcl.com> wrote:
I'm trying to SYSGEN an 11M 4.1 system from the distribution on RL01s
using a dual RL PDP-11/23+ (which is simh in this case, so I know the
hardware works). I'm letting it autoconfigure and I'm taking pretty much
the default answer for everything. The build seems to go without error and
yet the resulting system crashes as soon as it boots. I give up - what am I
doing wrong? Somebody give me a clue, please! The simh log is attached.
Thanks,
Bob Armstrong
<install.log>
Oops, looks like my email server was misconfigured and my message got lost.
What version of simh?
On 2013-03-11 21:37, Bob Armstrong wrote:
I'm trying to SYSGEN an 11M 4.1 system from the distribution on RL01s
using a dual RL PDP-11/23+ (which is simh in this case, so I know the
hardware works). I'm letting it autoconfigure and I'm taking pretty much
the default answer for everything. The build seems to go without error and
yet the resulting system crashes as soon as it boots. I give up - what am I
doing wrong? Somebody give me a clue, please! The simh log is attached.
When RSX is building the system, it at one point creates the new system image to run, called [1,54]RSX11M.SYS.
The relevant line is
>PIP RSX11M.SYS/CO/NV/BL:498.=RSX11M.TSK
Now, your machine only have 128kW. That is 256 kByte. Of this, 8 kByte goes away because of the I/O page. Leaving 248 kByte. This is 496 disk blocks.
It *might* be that your disk file is too big, making the system assume that it can place stuff in memory that don't exist. RSX11M.SYS is pretty close to just a memory dump.
Try creating a new RSX11M.SYS, which is a bit smaller, and then rerun the VMR command, and try booting that file instead and see if that helps?
Johnny
I'm trying to SYSGEN an 11M 4.1 system from the distribution on RL01s
using a dual RL PDP-11/23+ (which is simh in this case, so I know the
hardware works). I'm letting it autoconfigure and I'm taking pretty much
the default answer for everything. The build seems to go without error and
yet the resulting system crashes as soon as it boots. I give up - what am I
doing wrong? Somebody give me a clue, please! The simh log is attached.
Thanks,
Bob Armstrong
From: Johnny Billquist <bqt at softjar.se>
Ok. The time is drawing near to actually get my new TCP/IP for RSX out
the door. So I'm looking for possible interested people who would like
to try things out. This is like field testing, so expect there to be
some issues, and helpful feedback would be appreciated.
Awesome!!! Yes please. It's great that you've taken it so far.
The API is not compatible with any Unix like one at this time,
Excellent. (Don't get me started!)
Nice work -- that's really cool!
John Wilson
D Bit
Ok. The time is drawing near to actually get my new TCP/IP for RSX out the door. So I'm looking for possible interested people who would like to try things out. This is like field testing, so expect there to be some issues, and helpful feedback would be appreciated.
The state right now is that the protocols seems to work fine. They have been tested by myself for many years, and the last week a first external person started testing, which means I'm right now trying to get a distribution kit together that is usable.
What is in there? Nice of you to ask. Of course the basic protocols - ARP, IP, ICMP, UDP and TCP. In addition, there are libraries for using this from MACRO-11 and from high level languages (the one tested extensively so far is BASIC+2, but libraries for F77 and C will also be in there). Additional suggestions are welcome. In addition, a few example pieces exist, such as a web server, TFTP daemon, RWHOD daemon, IRC client, and an IRC robot, and a few well known TCP services (ECHO, SINK, DAYTIME and QUOTD).
Additionally I am working on FTP right now (both server and client), and both a TELNET server and client is planned, but will take a little more time.
This TCP/IP requires a RSX-11M-PLUS system. It has only been tested on V4.6, but I believe it should work ok on any V4. It might also work on previous versions, but there are possible issues. Let me know if you want to test it on something like that. The package will not work on 11M. Mostly because some pieces really need the split I/D space. It would be possible to work around that, but it would be a rather big project, and unless someone actually needs it enough to pay for that work, it will not happen.
The whole system runs as device drivers and one ACP. It can coexist with DECnet, or use the XE: device driver for Unibus machines. Qbus machines without DECnet is not possible right now, but is something I will address eventually.
The whole TCP/IP takes little resources. It uses a small amount of pool, and a little CPU, but not really noticeable under normal operation. It creates its own memory region which it uses for most memory consumption.
The API is not compatible with any Unix like one at this time, although adding such a layer is definitely possible, and might be something I'll do if enough people want to waste the memory. However, the actual API existing is really easy to use, and very versatile.
There is a reference system online. You can telnet to mim.update.uu.se (or set host to MIM::), and login with guest/guest if you want to look at it (emulated 11/74, so this address does not point at the TCP/IP stack of RSX). You can also point your web browser at madame.update.uu.se, which is the RSX systems web server.
So, please contact me if this interest you. My address is bqt at softjar.se.
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 7 Mar 2013, at 15:46, Johnny Billquist <bqt at softjar.se> wrote:
Ah. That is another issue. If your terminal (xterm in this case) is configured to use UTF-8, then you will not work well against a machine that do not use UTF-8 (it's a mess).
Johnny
Oh god, just had a horrid flashback to calling BBSes in Finland in the early 90s with people using {}\| for etc.
In Portugal they just gave up and used apostrophes for accents, acute goes before the letter, grave goes after. Wait or is it the other way around?
sampsa <sampsa at mac.com>
mobile +961 788 10537
On 2013-03-07 12:45, Jordi Guillaumes i Pons wrote:
Al 07/03/13 00:59, En/na Johnny Billquist ha escrit:
I hope you are aware of the fact that telnet by default is not 8-bit
clean. :-)
Well, sort of. The same xterm configuration displays (and inputs) 8 bit
characters if I telnet to a linux box...
That is probably because at connection time, telnets negotiate the capabilities between them. You can get very different behavior depending on what you have on each side.
I think it is related to the usage of UTF-8 in the unix machine... I
have reconfigured my ubuntu laptop to use ISO-8859-15 and it now _seems_
to work.
Ah. That is another issue. If your terminal (xterm in this case) is configured to use UTF-8, then you will not work well against a machine that do not use UTF-8 (it's a mess).
Johnny
Cory Smelosky <b4 at gewt.net> writes:
On 6 Mar 2013, at 21:48, "Brian Schenkenberger, VAXman-" =
<system at TMESIS.COM> wrote:
"Jerome H. Fine" <jhfinedp3k at compsys.to> writes:
=20
{...snip...}
Seriously, has anyone ever successfully developed a virus for
a VMS system? I think I heard that there was a yearly contest
to see if anyone could compromise a VMS system and it failed
every year.
=20
A few (2-3) years ago, there was a reported security elevation exploit =
that
involves a stupid buffer contamination exploit in =
SMG$READ_COMPOSED_LINE and
any VMS utility that employed it and that was installed with =
privileges. It
turned out that the INSTALL utility could be exploited. It was NOT =
simple
to do but it could be done. I implemented a weaponized PoC to exploit =
the
security vulnerabity. It was, happily, quickly addressed. =20
=20
There was also another exploit wherein one could send, via VMS mail, =
the
equivalent of an attachment using /FOREIGN. If the attachment was =
created
with SUBMIT-ON-CLOSE and the file was read by a privileged user, all =
bets
were off. Again, this was quickly subdued before it became a =
widespread
exploit. That, IIRC, was about a decade ago.
=20
Not a bad record at one vulnerability per decade. ;) The only real =
success
stories of infiltrating VMS all stemmed from social engineering and =
not, to
my knowledge, from security holes in the OS.
I was recently watching a DEFCON talk about breaking in to VMS=85no =
remote vulnerabilities were found. They all required human stupidity or =
an existing account.
http://www.youtube.com/watch?v=3DXf7gVma6_3g
The vulnerability I spoke to WRT the SMG$READ_COMPOSED_LINE is discussed
in this video; however, these VMS neophytes (and I still believe that the
fellow discussing the SMG$ issue was given information about this from a
disgruntled VMS engineer as he clearly does NOT know what he is speaking
about) were tutored by others. The nonsense about using a logical name
still makes me spew a mouthful of coffee, assuming I'm drinking it, upon
my screen and keyboard when I watch that video you've linked. To exploit
the security hole (now patched) required self-modifying Alpha code. It's
not very likely that these guys had the wherewithal to accomplish such a
feat with their neanderthal approach to the subject they presented.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Al 07/03/13 00:59, En/na Johnny Billquist ha escrit:
I hope you are aware of the fact that telnet by default is not 8-bit clean. :-)
Well, sort of. The same xterm configuration displays (and inputs) 8 bit characters if I telnet to a linux box...
I think it is related to the usage of UTF-8 in the unix machine... I have reconfigured my ubuntu laptop to use ISO-8859-15 and it now _seems_ to work.
On 6 Mar 2013, at 21:48, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
"Jerome H. Fine" <jhfinedp3k at compsys.to> writes:
{...snip...}
Seriously, has anyone ever successfully developed a virus for
a VMS system? I think I heard that there was a yearly contest
to see if anyone could compromise a VMS system and it failed
every year.
A few (2-3) years ago, there was a reported security elevation exploit that
involves a stupid buffer contamination exploit in SMG$READ_COMPOSED_LINE and
any VMS utility that employed it and that was installed with privileges. It
turned out that the INSTALL utility could be exploited. It was NOT simple
to do but it could be done. I implemented a weaponized PoC to exploit the
security vulnerabity. It was, happily, quickly addressed.
There was also another exploit wherein one could send, via VMS mail, the
equivalent of an attachment using /FOREIGN. If the attachment was created
with SUBMIT-ON-CLOSE and the file was read by a privileged user, all bets
were off. Again, this was quickly subdued before it became a widespread
exploit. That, IIRC, was about a decade ago.
Not a bad record at one vulnerability per decade. ;) The only real success
stories of infiltrating VMS all stemmed from social engineering and not, to
my knowledge, from security holes in the OS.
I was recently watching a DEFCON talk about breaking in to VMS no remote vulnerabilities were found. They all required human stupidity or an existing account.
http://www.youtube.com/watch?v=Xf7gVma6_3g
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
