HECnet

hecnet@lists.dfupdate.se

15556 discussions

New node - 1.408, VAXPLS, running DECNET Plus!

by sampsa＠mac.com

Guys, I've managed to get DECNET plus going on a SIMH VAX running OpenVMS 7.3-1. It was quite straightforward actually and everything seems to be running fine. The only thing that required a bit of hacking was importing the nodes database into the local name resolver but even that wasn't TOO painful. Let me know if anyone wants a guest account to play around with. Sampsa

15 years, 3 months

VMS question - clearing the SECURITY.AUDIT$JOURNAL security log

by sampsa＠mac.com

Another thing: Anyone know how to make the standard SSHD (TCP/IP services 5.4, I think) report login failures into the security journal? At the moment the Telnet and DECNET login stuff is logged, but now SSH. Any ideas? Sampsa On 11 Jan 2010, at 16:05, gerry77 at mail.com wrote: On Mon, 11 Jan 2010 13:18:42 +0000, you wrote: Gents, I'm in the process of installing ArcSight on my network, and basically it works by running an ANALYZE/AUDIT/FULL command on SECURITY.AUDIT $JOURNAL and then importing the output file on a separate Unix for log processing. I'm trying to find a way of clearing the current audit log (since I'm extracting the events out of it, i don't want duplicates, /SINCE risks missing events that happen within the delta). What is the proper way of clearing the security audit log? What about SET AUDIT/SERVER=NEW_LOG to create a new version of the journal before processing (i.e.: create new log then analyze the old one)? :-) HTH, G.

15 years, 3 months

VMS question - clearing the SECURITY.AUDIT$JOURNAL security log

by sampsa＠mac.com

Yup, discovered that. So what I do now is to analyze the old one, put the results in the file that gets grabbed by the Unix box, and then run that SET command. Seems to work OK so far. Sampsa On 11 Jan 2010, at 16:05, gerry77 at mail.com wrote: On Mon, 11 Jan 2010 13:18:42 +0000, you wrote: Gents, I'm in the process of installing ArcSight on my network, and basically it works by running an ANALYZE/AUDIT/FULL command on SECURITY.AUDIT $JOURNAL and then importing the output file on a separate Unix for log processing. I'm trying to find a way of clearing the current audit log (since I'm extracting the events out of it, i don't want duplicates, /SINCE risks missing events that happen within the delta). What is the proper way of clearing the security audit log? What about SET AUDIT/SERVER=NEW_LOG to create a new version of the journal before processing (i.e.: create new log then analyze the old one)? :-) HTH, G.

15 years, 3 months

VMS question - clearing the SECURITY.AUDIT$JOURNAL security log

by gerry77＠mail.com

On Mon, 11 Jan 2010 13:18:42 +0000, you wrote: Gents, I'm in the process of installing ArcSight on my network, and basically it works by running an ANALYZE/AUDIT/FULL command on SECURITY.AUDIT $JOURNAL and then importing the output file on a separate Unix for log processing. I'm trying to find a way of clearing the current audit log (since I'm extracting the events out of it, i don't want duplicates, /SINCE risks missing events that happen within the delta). What is the proper way of clearing the security audit log? What about SET AUDIT/SERVER=NEW_LOG to create a new version of the journal before processing (i.e.: create new log then analyze the old one)? :-) HTH, G.

15 years, 3 months

VMS question - clearing the SECURITY.AUDIT$JOURNAL security log

by sampsa＠mac.com

Gents, I'm in the process of installing ArcSight on my network, and basically it works by running an ANALYZE/AUDIT/FULL command on SECURITY.AUDIT$JOURNAL and then importing the output file on a separate Unix for log processing. I'm trying to find a way of clearing the current audit log (since I'm extracting the events out of it, i don't want duplicates, /SINCE risks missing events that happen within the delta). What is the proper way of clearing the security audit log? Sampsa

15 years, 3 months

DECnet session control specification

by gerry77＠mail.com

On Thu, 7 Jan 2010 11:46:38 -0500, you wrote: I'm pretty sure there was a Session 1.1 spec. For that matter, there were (of course) Phase V specs. The problem is that none of these seem to have been preserved. The specs we do have are on-line because Matt had the foresight to put them online way back when, and that stuck. Various other specs were published, or were supposed to be published, but that doesn't mean they are online. I suspect there are some paper specs that could be scanned, if someone wanted to do the work. Then there are some cases where the intent was to publish the specs -- Phase V, Phase IV+ (which is where Session 1.1 might show up) -- but I know of no evidence that this intent was ever carried out. For example, I've never seen any trace of the Phase V specs. I'm wondering if someone like Al Kossow from Bitsavers has something yet to be scanned and (re-)published. From time to time his archive has made available very interesting things. Just to cite one, he surfaced the LAT specification (AA-NL26A-TE) which was not available when Christine Caulfield reverse-egineered the LAT protocol to write her latd daemon for Linux. Yet another archive which sometimes may have interesting documents is Manx. Speaking about protocols, one I'd like to read about is LAST (Local Area System Transport), for which nothing appears to be available on the Internet besides an ASCII text handbook with formatting all screwed up and just some high level details of the protocol (that indeed resembles a glorified LAT). By the way, the handbook part number is EK-LADLA-AS-001, and something about DECnet-Plus is at ftp://ftp.radio-msu.net/.1/ftp.cisco.com/pub/rfc/DEC/ The names in format 1 and format 2 destination descriptors are one example of something that was explicitly left as platform dependent. For example, I think in VMS and RSX it is a program name, but in RSTS (DECnet/E) it's something quite different that doesn't tie directly to a program name at all. In my last message I made a mistake and reversed the names: I wrote about the destination, but I meant the source end user name. Sorry. :-P If I'm right with my findings, the format 2 thing sent from OpenVMS V7.2 to another identical system has the GRPCODE and USRCODE fields used as a big four-bytes field containing the EPID of the "calling" process. And this is not present in the V1.0 specification for the "source end user name". :-) Bye, G.

15 years, 3 months

GORVAX is up...for now..

by bqt＠softjar.se

Hmm. I haven't tried the bridge on MacOSX myself. Maybe I should. Not nice with crashes. If you were running some Unix, I would have a simple test for you to check if the problems were as I observed, but with VMS I don't have a good suggestion for a tool to test it. What I observed (running 2.11BSD on simh here) was that the ethernet input was buffering a whole bunch of packets before delivering them to the emulator. Running ping, I could observe that about 30 packets were sent before I got any replies, and then I got all 30 replies at once. The VMS ping command only sends four pings, so that can probably not be used to test this. Another problem with simh is that the DEUNA/DELUA emulation is slightly wrong. But I don't know if you are running an 11/780 or a 3900, but I suspect a 3900 in which case that bug wont bite you. Looking from the outside with tcpdump (or similar program) things do look right. You can see traffic coming out, and replies going back in, but the emulated system don't seem to be receiving. Sounds like your problem? Johnny Sampsa Laine wrote: That would be very useful, care to elaborate on what the problem was, and/or link me to your fixed source/binaries? BTW, I've noticed that binaries are wonderfully portable across OS X systems, for example, when I recompiled your bridge on Snow Leopard with the latest Xcode, it kept stack dumping. However the binary compiled on Tiger Server works fine and doesn't have any problems. Sampsa On 6 Jan 2010, at 22:56, Johnny Billquist wrote: Sampsa Laine wrote: Gentlemen, GORVAX and it's associated MULTINET pipe are up again. There is something about either my new iMac or Snow Leopard that breaks the networking on SIMH, so I've momentarily put it on my (already overloaded) Mac mini. This stops me from using the mini as a media centre however, so I need to find another box for it to run on. Doh. Maybe I can help. I just fixed a "problem" or two in simh, which prevented the networking to work right on my macbook pro with snow leopard. Contact me off list to investigate this further... 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 -- 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

15 years, 3 months

DECnet session control specification

by Paul_Koning＠Dell.com

On Wed, 6 Jan 2010 11:50:05 -0500, you wrote: "Reserved" means "send zero, ignore on receipt". It most definitely does NOT mean "check on receive that this is zero", that's a silly mistake all too often make in protocol design. This too is for mixed version handling. If a new flag can safely be ignored by an older system, then the newer system can simply send that flag in what used to be a reserved field, and the right thing happens. Sure, but I'm not trying to implement something nor to make different DECnet versions cooperate. I'm just studying the actual content of some packets and have noticed some discrepancies between the standard specifications and the actual data on wire, sent from a VMS V7.2 box to another V7.2 system. :-) Finally, proxy was originally a VMS specific enhancement and was adopted in some other implementations (I know DECnet/E picked it up, at least in a semi-compatible form). I'm not sure that it was ever specified in an architecture spec. See above. What I'm looking at is the data exchange between two VMS boxes, both at V7.2, so it's not strange to see something about proxies. Sure. Actually, proxies did get implemented in a number of places, so you might see it even cross-platform. Speaking about specifications, I was thinking that DEC was quite strict about this and I was hoping that somewhere there was at least an update if not an entire new specification, or that someone would know who to ask for. DEC was fairly strict, indeed. Sometimes things did get implemented that weren't well documented. Also, some sections of DECnet were much more platform-dependent than others, by design. Session Control is an example, and the old network terminal protocols even more so. By contrast, things like NSP and, especially, the routing layer were much more rigidly controlled. I'm pretty sure there was a Session 1.1 spec. For that matter, there were (of course) Phase V specs. The problem is that none of these seem to have been preserved. The specs we do have are on-line because Matt had the foresight to put them online way back when, and that stuck. Various other specs were published, or were supposed to be published, but that doesn't mean they are online. I suspect there are some paper specs that could be scanned, if someone wanted to do the work. Then there are some cases where the intent was to publish the specs -- Phase V, Phase IV+ (which is where Session 1.1 might show up) -- but I know of no evidence that this intent was ever carried out. For example, I've never seen any trace of the Phase V specs. Maybe some former DEC person has copies of these documents tucked away somewhere. If so, one might hope that those could be found, in which case they can be put online. (Permission was already given to do that -- permission is NOT the issue in this case.) BTW, all the differences I've found are in the session control protocol and the one about proxies is just one of them: another is in the contents of the format 2 "destination end user name". The names in format 1 and format 2 destination descriptors are one example of something that was explicitly left as platform dependent. For example, I think in VMS and RSX it is a program name, but in RSTS (DECnet/E) it's something quite different that doesn't tie directly to a program name at all. paul

15 years, 3 months

DECnet session control specification

by gerry77＠mail.com

15 years, 3 months

We're (sort of ) back up again.

by sampsa＠mac.com

Steve, As discussed on the list, the problem was with SIMH on Snow Leopard specifically and Johnny seems to have fixed whatever it was. Thanks for the offer though. Sampsa On 2 Jan 2010, at 19:46, Steve Davidson wrote: I use simh all the time. If I can help I will be around most of the weekend. My only task this weekend is dealing with the snow on the driveway. So far we have had 5+ inches. They expect another 5-7 more. The snow blower went through this last pass in 90 minutes. -Steve From: Sampsa Laine [mailto:sampsa at mac.com] Sent: Sat 1/2/2010 14:31 To: Steve Davidson Subject: Re: [HECnet] We're (sort of ) back up again. It's not a VMS issue per se I think - something to do with SIMH and the network interface. I might have a play later. Sampsa On 2 Jan 2010, at 19:06, Steve Davidson wrote: Sampsa, If you need any help with this - let me know. I'm around all weekend. Most of this time will be spent hacking!!! -Steve From: owner-hecnet at Update.UU.SE on behalf of Sampsa Laine Sent: Sat 1/2/2010 13:16 To: hecnet at Update.UU.SE Subject: [HECnet] We're (sort of ) back up again. I've replaced the server that ran my bridge and GORVAX, unfortunately there's something REALLY broken with GORVAX that I just can't figure out right now (and don't really have the time to, either). Anyway, RHESUS and CHIMPY are up, CHIMP should be up RSN. GORVAX will be down for a little while longer, as will the Fidonet mail gateway. Sampsa

15 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet