- HECnet - lists @ Update

FYI - Guys, I'm back from the desert, areas 8 and 47 are alive again...

by jg＠jordi.guillaumes.name

El 08/09/2014, a les 23.20, Sampsa Laine <sampsa at mac.com> va escriure: Just thought I'd let you know that CHIMPY:: and HILANT:: are finally back up again, had some hardware trouble with my hosting box, but was stuck in the Sinai desert... All is well now, and CHIMPY, GORVAX and HILANT are back online.. sampsa Hello, desert man! Hve you changed your IP addresses? My multinet links to GORVAX and SG1 are both down at this moment. Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES

10 years, 10 months

1
0
0 0

FYI - Guys, I'm back from the desert, areas 8 and 47 are alive again...

by mark＠wickensonline.co.uk

Well done Sampsa. Your life is still an enigma to me - but it sounds fun (for the most part!) M. On 08/09/14 22:20, Sampsa Laine wrote: Just thought I'd let you know that CHIMPY:: and HILANT:: are finally back up again, had some hardware trouble with my hosting box, but was stuck in the Sinai desert... All is well now, and CHIMPY, GORVAX and HILANT are back online.. sampsa

10 years, 10 months

1
0
0 0

FYI - Guys, I'm back from the desert, areas 8 and 47 are alive again...

by sampsa＠mac.com

Just thought I'd let you know that CHIMPY:: and HILANT:: are finally back up again, had some hardware trouble with my hosting box, but was stuck in the Sinai desert... All is well now, and CHIMPY, GORVAX and HILANT are back online.. sampsa

10 years, 10 months

1
0
0 0

Network change stuff

by b4＠gewt.net

Hello all, Hey Brian...in the next week or so I'll be simplifying the tunnel and moving to a (mostly) static IP through cable. I will also be replacing the current DECnet router (a Cisco 2524) with a much more recent 1841 running IOS 15.1. ;) Maybe tftp will work now? ;););) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

10 years, 11 months

1
0
0 0

Adjacencies Keep Bouncing

by robert.jarratt＠ntlworld.com

Ah, the changes once per second would explain those sequences one second apart coming from 8.400. I had not noticed that in the specs. I guess those updates could be coming because 8.400 is not seeing some packets (or they are being delayed), so it is changing its mind about the liveness of some adjacencies and so sending out updates. My router does not send updates as they change, it waits for the hello timer. As for my pacing of the Level 1 Router updates, the spec does anticipate some issues because it wants you to stagger the starting point (para 6 of section 4.8.1). My pacing should not affect other nodes, the problem seems to occur when I *send* a lot of packets all at once, it seems to affect the receive side. If other nodes send me lots of updates in a burst, that seems to be OK. Regards Rob From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 30 June 2014 21:56 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Adjacencies Keep Bouncing A few notes below paul On Jun 29, 2014, at 5:04 AM, Robert Jarratt <robert.jarratt at ntlworld.com> wrote: I think this was discussed not too long ago, but I can t find the email thread. Sorry, this is quite a long email. ... So here are some interesting things about the above information. 1. I am supposed to send out the Ethernet Router Hello every 15 seconds. From my router log, that is exactly what happens (at :18, :33, :48 etc). However the packet sniffer sees extra packets inserted. I have no idea where these packets are coming from (although my suspicion is winpcap, see later). 2. 8.400 seems to send its Ethernet Router Hello every 15 seconds, but repeats them several times at 1-second intervals. In the extract above it is repeated 3 times, then 3 times, then 5 times. The rule is that router hellos are sent every hello time, or whenever the content of the message changes (different DR, different router list, change in router priority, etc.). Hellos sent when a change occurs are limited to one per second. 3. For a node to decide to drop an adjacency (ie to exclude it from the Ethernet Router Hello message), it must fail to see an Ethernet Router Hello for 3xHello Timer (Hello Timer is 15 seconds by default, so 45 seconds). Clearly my side has sent several Ethernet Router Hello messages in that time. If this was UDP dropping packets, then I would have hoped that it would not drop my particular ones 3 times in a row over a period of 45 seconds. So, somehow, my Ethernet Router Hello messages are being dropped on their way to 8.400. However, this can t be outbound from 5.1023, because if that was the case then all my adjacencies would all go down at the same time. At any one time, only adjacency goes down. This suggests that the packet is somehow getting lost towards the end of its journey to 8.400. What kind of node is 8.400? 47.556 is another one that appears to have this problem, I see that one is SIMH. I am wondering if pcap/winpcap might be implicated here. The reason is that I noticed winpcap seems to drop incoming packets if you have sent a burst of outbound packets. In my router I was sending all the DECnet Level 1 Routing messages, all at the same time and getting some problems similar to this with a node local to my network, because my router did not see the packets coming from the other node, even though the sniffer could see them. I changed my router code to send the Level 1 Routing messages with a 1-second delay between them, and that problem went away. So, I am wondering if the remote nodes I have this problem with are SIMH nodes? Yikes. DECnet assumes that data links don t have defects like that. If you need a workaround like that, chances are things won t work anyway, because the nodes you re talking to will not do packet pacing like that. paul

11 years

1
0
0 0

Adjacencies Keep Bouncing

by Paul_Koning＠Dell.com

A few notes below paul On Jun 29, 2014, at 5:04 AM, Robert Jarratt <robert.jarratt at ntlworld.com> wrote: I think this was discussed not too long ago, but I can t find the email thread. Sorry, this is quite a long email. ... So here are some interesting things about the above information. 1. I am supposed to send out the Ethernet Router Hello every 15 seconds. From my router log, that is exactly what happens (at :18, :33, :48 etc). However the packet sniffer sees extra packets inserted. I have no idea where these packets are coming from (although my suspicion is winpcap, see later). 2. 8.400 seems to send its Ethernet Router Hello every 15 seconds, but repeats them several times at 1-second intervals. In the extract above it is repeated 3 times, then 3 times, then 5 times. The rule is that router hellos are sent every hello time, or whenever the content of the message changes (different DR, different router list, change in router priority, etc.). Hellos sent when a change occurs are limited to one per second. 3. For a node to decide to drop an adjacency (ie to exclude it from the Ethernet Router Hello message), it must fail to see an Ethernet Router Hello for 3xHello Timer (Hello Timer is 15 seconds by default, so 45 seconds). Clearly my side has sent several Ethernet Router Hello messages in that time. If this was UDP dropping packets, then I would have hoped that it would not drop my particular ones 3 times in a row over a period of 45 seconds. So, somehow, my Ethernet Router Hello messages are being dropped on their way to 8.400. However, this can t be outbound from 5.1023, because if that was the case then all my adjacencies would all go down at the same time. At any one time, only adjacency goes down. This suggests that the packet is somehow getting lost towards the end of its journey to 8.400. What kind of node is 8.400? 47.556 is another one that appears to have this problem, I see that one is SIMH. I am wondering if pcap/winpcap might be implicated here. The reason is that I noticed winpcap seems to drop incoming packets if you have sent a burst of outbound packets. In my router I was sending all the DECnet Level 1 Routing messages, all at the same time and getting some problems similar to this with a node local to my network, because my router did not see the packets coming from the other node, even though the sniffer could see them. I changed my router code to send the Level 1 Routing messages with a 1-second delay between them, and that problem went away. So, I am wondering if the remote nodes I have this problem with are SIMH nodes? Yikes. DECnet assumes that data links don t have defects like that. If you need a workaround like that, chances are things won t work anyway, because the nodes you re talking to will not do packet pacing like that. paul

11 years

1
0
0 0

Adjacencies Keep Bouncing

by hvlems＠zonnet.nl

My A44RTR is a Van server 3900 simh host on top of a fedora 14 Linux system. I only see occasionally an adjacency down message . Verzonden vanaf mijn BlackBerry 10-smartphone. Origineel bericht Van: Robert Jarratt Verzonden: maandag 30 juni 2014 21:46 Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: RE: [HECnet] Adjacencies Keep Bouncing I wouldn't exclude that possibility at all. Basically there seems to be a problem with packets getting lost somewhere between Sampsa's nodes and whatever machine he is peering with. Pcap/winpcap is a possibility based on some experience I have had with winpcap. But it would be good to hear if there is anything else that is unusual in his setup that might cause this. I am guessing that there are many other nodes on HECnet that are also SIMH, if there are, they do not bounce nearly as often. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Gregg Levine Sent: 29 June 2014 23:50 To: hecnet at update.uu.se Subject: Re: [HECnet] Adjacencies Keep Bouncing Hello! Now this is straight out into deep space, and probably aiming for a cloaked starship, but what if the problem is how the network is connected to what Sampsa runs? Sampsa how about some input from you please? ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Sun, Jun 29, 2014 at 12:38 PM, Johnny Billquist <bqt at softjar.se> wrote: Just a few comments... 8.400 (GORVAX) is a SIMH VAX, according to the nodename database. http://madame.update.uu.se/~bqt/nodedb?search=gorvax&field=0&sort=0 I see the same issues with GORVAX and KUHAVX (47.556) also on MIM. Both machines (and areas) are run by Sampsa. Not sure how relevant that is... I have not done any further looking at actual packets yet. I might if I find some time. But it do seem there is some kind of problem/issue here. Johnny On 2014-06-29 02:04, Robert Jarratt wrote: I think this was discussed not too long ago, but I can t find the email thread. Sorry, this is quite a long email. Here at 5.1023 I keep experiencing certain adjacencies going up and down. At the bottom of this email is an extract of several hours of my log (all times are UK local time, current GMT+1). Last night I investigated one of these, when 8.400 went down at 2014-06-28 22:04:03. I used a packet sniffer and could see that my Ethernet Router Hello message went out, with 8.400 in it, at the following times: 22:03:18 22:03:23 22:03:33 22:03:38 22:03:48 22:03:53 I did not send any Ethernet Router Hello messages in that period that excluded 8.400. Conversely, from 8.400 I received Ethernet Router Hello messages, with 5.1023 included except where noted at the following times: 22:03:28 22:03:29 22:03:30 22:03:45 22:03:46 22:03:47 22:04:03 (5.1023 missing) 22:04:04 22:04:07 22:04:08 22:04:09 22:04:25 22:04:26 So here are some interesting things about the above information. 1. I am supposed to send out the Ethernet Router Hello every 15 seconds.

11 years

1
0
0 0

Adjacencies Keep Bouncing

by robert.jarratt＠ntlworld.com

I wouldn't exclude that possibility at all. Basically there seems to be a problem with packets getting lost somewhere between Sampsa's nodes and whatever machine he is peering with. Pcap/winpcap is a possibility based on some experience I have had with winpcap. But it would be good to hear if there is anything else that is unusual in his setup that might cause this. I am guessing that there are many other nodes on HECnet that are also SIMH, if there are, they do not bounce nearly as often. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Gregg Levine Sent: 29 June 2014 23:50 To: hecnet at update.uu.se Subject: Re: [HECnet] Adjacencies Keep Bouncing Hello! Now this is straight out into deep space, and probably aiming for a cloaked starship, but what if the problem is how the network is connected to what Sampsa runs? Sampsa how about some input from you please? ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Sun, Jun 29, 2014 at 12:38 PM, Johnny Billquist <bqt at softjar.se> wrote: Just a few comments... 8.400 (GORVAX) is a SIMH VAX, according to the nodename database. http://madame.update.uu.se/~bqt/nodedb?search=gorvax&field=0&sort=0 I see the same issues with GORVAX and KUHAVX (47.556) also on MIM. Both machines (and areas) are run by Sampsa. Not sure how relevant that is... I have not done any further looking at actual packets yet. I might if I find some time. But it do seem there is some kind of problem/issue here. Johnny On 2014-06-29 02:04, Robert Jarratt wrote: I think this was discussed not too long ago, but I can t find the email thread. Sorry, this is quite a long email. Here at 5.1023 I keep experiencing certain adjacencies going up and down. At the bottom of this email is an extract of several hours of my log (all times are UK local time, current GMT+1). Last night I investigated one of these, when 8.400 went down at 2014-06-28 22:04:03. I used a packet sniffer and could see that my Ethernet Router Hello message went out, with 8.400 in it, at the following times: 22:03:18 22:03:23 22:03:33 22:03:38 22:03:48 22:03:53 I did not send any Ethernet Router Hello messages in that period that excluded 8.400. Conversely, from 8.400 I received Ethernet Router Hello messages, with 5.1023 included except where noted at the following times: 22:03:28 22:03:29 22:03:30 22:03:45 22:03:46 22:03:47 22:04:03 (5.1023 missing) 22:04:04 22:04:07 22:04:08 22:04:09 22:04:25 22:04:26 So here are some interesting things about the above information. 1. I am supposed to send out the Ethernet Router Hello every 15 seconds.

11 years

1
0
0 0

Adjacencies Keep Bouncing

by gregg.drwho8＠gmail.com

Hello! Now this is straight out into deep space, and probably aiming for a cloaked starship, but what if the problem is how the network is connected to what Sampsa runs? Sampsa how about some input from you please? ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Sun, Jun 29, 2014 at 12:38 PM, Johnny Billquist <bqt at softjar.se> wrote: Just a few comments... 8.400 (GORVAX) is a SIMH VAX, according to the nodename database. http://madame.update.uu.se/~bqt/nodedb?search=gorvax&field=0&sort=0 I see the same issues with GORVAX and KUHAVX (47.556) also on MIM. Both machines (and areas) are run by Sampsa. Not sure how relevant that is... I have not done any further looking at actual packets yet. I might if I find some time. But it do seem there is some kind of problem/issue here. Johnny On 2014-06-29 02:04, Robert Jarratt wrote: I think this was discussed not too long ago, but I can t find the email thread. Sorry, this is quite a long email. Here at 5.1023 I keep experiencing certain adjacencies going up and down. At the bottom of this email is an extract of several hours of my log (all times are UK local time, current GMT+1). Last night I investigated one of these, when 8.400 went down at 2014-06-28 22:04:03. I used a packet sniffer and could see that my Ethernet Router Hello message went out, with 8.400 in it, at the following times: 22:03:18 22:03:23 22:03:33 22:03:38 22:03:48 22:03:53 I did not send any Ethernet Router Hello messages in that period that excluded 8.400. Conversely, from 8.400 I received Ethernet Router Hello messages, with 5.1023 included except where noted at the following times: 22:03:28 22:03:29 22:03:30 22:03:45 22:03:46 22:03:47 22:04:03 (5.1023 missing) 22:04:04 22:04:07 22:04:08 22:04:09 22:04:25 22:04:26 So here are some interesting things about the above information. 1. I am supposed to send out the Ethernet Router Hello every 15 seconds.

11 years

1
0
0 0

Adjacencies Keep Bouncing

by bqt＠softjar.se

Just a few comments... 8.400 (GORVAX) is a SIMH VAX, according to the nodename database. http://madame.update.uu.se/~bqt/nodedb?search=gorvax&field=0&sort=0 I see the same issues with GORVAX and KUHAVX (47.556) also on MIM. Both machines (and areas) are run by Sampsa. Not sure how relevant that is... I have not done any further looking at actual packets yet. I might if I find some time. But it do seem there is some kind of problem/issue here. Johnny On 2014-06-29 02:04, Robert Jarratt wrote: I think this was discussed not too long ago, but I can t find the email thread. Sorry, this is quite a long email. Here at 5.1023 I keep experiencing certain adjacencies going up and down. At the bottom of this email is an extract of several hours of my log (all times are UK local time, current GMT+1). Last night I investigated one of these, when 8.400 went down at 2014-06-28 22:04:03. I used a packet sniffer and could see that my Ethernet Router Hello message went out, with 8.400 in it, at the following times: 22:03:18 22:03:23 22:03:33 22:03:38 22:03:48 22:03:53 I did not send any Ethernet Router Hello messages in that period that excluded 8.400. Conversely, from 8.400 I received Ethernet Router Hello messages, with 5.1023 included except where noted at the following times: 22:03:28 22:03:29 22:03:30 22:03:45 22:03:46 22:03:47 22:04:03 (5.1023 missing) 22:04:04 22:04:07 22:04:08 22:04:09 22:04:25 22:04:26 So here are some interesting things about the above information. 1. I am supposed to send out the Ethernet Router Hello every 15 seconds.

11 years

1
0
0 0

Adjacencies Keep Bouncing

by robert.jarratt＠ntlworld.com

I think this was discussed not too long ago, but I can t find the email thread. Sorry, this is quite a long email. Here at 5.1023 I keep experiencing certain adjacencies going up and down. At the bottom of this email is an extract of several hours of my log (all times are UK local time, current GMT+1). Last night I investigated one of these, when 8.400 went down at 2014-06-28 22:04:03. I used a packet sniffer and could see that my Ethernet Router Hello message went out, with 8.400 in it, at the following times: 22:03:18 22:03:23 22:03:33 22:03:38 22:03:48 22:03:53 I did not send any Ethernet Router Hello messages in that period that excluded 8.400. Conversely, from 8.400 I received Ethernet Router Hello messages, with 5.1023 included except where noted at the following times: 22:03:28 22:03:29 22:03:30 22:03:45 22:03:46 22:03:47 22:04:03 (5.1023 missing) 22:04:04 22:04:07 22:04:08 22:04:09 22:04:25 22:04:26 So here are some interesting things about the above information. 1. I am supposed to send out the Ethernet Router Hello every 15 seconds. From my router log, that is exactly what happens (at :18, :33, :48 etc). However the packet sniffer sees extra packets inserted. I have no idea where these packets are coming from (although my suspicion is winpcap, see later). 2. 8.400 seems to send its Ethernet Router Hello every 15 seconds, but repeats them several times at 1-second intervals. In the extract above it is repeated 3 times, then 3 times, then 5 times. 3. For a node to decide to drop an adjacency (ie to exclude it from the Ethernet Router Hello message), it must fail to see an Ethernet Router Hello for 3xHello Timer (Hello Timer is 15 seconds by default, so 45 seconds). Clearly my side has sent several Ethernet Router Hello messages in that time. If this was UDP dropping packets, then I would have hoped that it would not drop my particular ones 3 times in a row over a period of 45 seconds. So, somehow, my Ethernet Router Hello messages are being dropped on their way to 8.400. However, this can t be outbound from 5.1023, because if that was the case then all my adjacencies would all go down at the same time. At any one time, only adjacency goes down. This suggests that the packet is somehow getting lost towards the end of its journey to 8.400. What kind of node is 8.400? 47.556 is another one that appears to have this problem, I see that one is SIMH. I am wondering if pcap/winpcap might be implicated here. The reason is that I noticed winpcap seems to drop incoming packets if you have sent a burst of outbound packets. In my router I was sending all the DECnet Level 1 Routing messages, all at the same time and getting some problems similar to this with a node local to my network, because my router did not see the packets coming from the other node, even though the sniffer could see them. I changed my router code to send the Level 1 Routing messages with a 1-second delay between them, and that problem went away. So, I am wondering if the remote nodes I have this problem with are SIMH nodes? I do also see, less frequently, timeouts on my side. These are when I fail to see an Ethernet Router Hello from the other node for 45 seconds. I have not analysed this scenario. Any ideas? Regards Rob 2014-06-28 15:00:50 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-28 15:42:04 Adjacency timeout 8.400 (Slot 23) 2014-06-28 15:42:04 Adjacency down 8.400 (Slot 23) 2014-06-28 15:42:06 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-28 16:37:12 Adjacency timeout 8.400 (Slot 23) 2014-06-28 16:37:12 Adjacency down 8.400 (Slot 23) 2014-06-28 16:37:17 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-28 18:11:46 Adjacency timeout 8.400 (Slot 23) 2014-06-28 18:11:46 Adjacency down 8.400 (Slot 23) 2014-06-28 18:12:04 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-28 18:15:11 Adjacency timeout 47.556 (Slot 25) 2014-06-28 18:15:11 Adjacency down 47.556 (Slot 25) 2014-06-28 18:15:14 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-28 18:33:15 Adjacency timeout 47.556 (Slot 25) 2014-06-28 18:33:15 Adjacency down 47.556 (Slot 25) 2014-06-28 18:33:18 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-28 18:33:19 Adjacency down 47.556 (Slot 25) 2014-06-28 18:33:42 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-28 18:54:37 Adjacency timeout 47.556 (Slot 25) 2014-06-28 18:54:37 Adjacency down 47.556 (Slot 25) 2014-06-28 18:54:43 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-28 19:36:02 Adjacency timeout 47.556 (Slot 25) 2014-06-28 19:36:02 Adjacency down 47.556 (Slot 25) 2014-06-28 19:36:20 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-28 19:44:36 Adjacency timeout 28.41 (Slot 24) 2014-06-28 19:44:36 Adjacency down 28.41 (Slot 24) 2014-06-28 19:53:04 Adjacency up 28.41 (Slot 24) on psilo.update.uu.se 2014-06-28 19:55:08 Adjacency timeout 28.41 (Slot 24) 2014-06-28 19:55:08 Adjacency down 28.41 (Slot 24) 2014-06-28 19:57:20 Adjacency up 28.41 (Slot 24) on psilo.update.uu.se 2014-06-28 20:00:03 Adjacency down 8.400 (Slot 23) 2014-06-28 20:00:03 Adjacency down 47.556 (Slot 25) 2014-06-28 20:00:04 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-28 20:00:05 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-28 20:18:08 Adjacency timeout 8.400 (Slot 23) 2014-06-28 20:18:08 Adjacency down 8.400 (Slot 23) 2014-06-28 20:18:12 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-28 20:47:46 Adjacency down 8.400 (Slot 23) 2014-06-28 20:47:46 Adjacency down 47.556 (Slot 25) 2014-06-28 20:47:49 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-28 20:47:49 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-28 22:04:03 Adjacency down 8.400 (Slot 23) 2014-06-28 22:04:04 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-28 23:10:26 Adjacency timeout 5.99 (Slot 30) 2014-06-28 23:10:26 Adjacency down 5.99 (Slot 30) 2014-06-28 23:18:28 Adjacency down 8.400 (Slot 23) 2014-06-28 23:18:28 Adjacency down 47.556 (Slot 25) 2014-06-28 23:18:34 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-28 23:18:35 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-28 23:25:50 Adjacency timeout 47.556 (Slot 25) 2014-06-28 23:25:50 Adjacency down 47.556 (Slot 25) 2014-06-28 23:25:54 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-29 00:06:52 Adjacency timeout 8.400 (Slot 23) 2014-06-29 00:06:52 Adjacency down 8.400 (Slot 23) 2014-06-29 00:06:58 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-29 00:10:47 Adjacency timeout 47.556 (Slot 25) 2014-06-29 00:10:47 Adjacency down 47.556 (Slot 25) 2014-06-29 00:10:47 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-29 00:28:21 Adjacency timeout 8.400 (Slot 23) 2014-06-29 00:28:21 Adjacency down 8.400 (Slot 23) 2014-06-29 00:28:26 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-29 00:30:54 Adjacency down 8.400 (Slot 23) 2014-06-29 00:31:18 Adjacency timeout 47.556 (Slot 25) 2014-06-29 00:31:18 Adjacency down 47.556 (Slot 25) 2014-06-29 00:31:21 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-29 00:31:21 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-29 00:45:41 Adjacency timeout 8.400 (Slot 23) 2014-06-29 00:45:41 Adjacency down 8.400 (Slot 23) 2014-06-29 00:46:04 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-29 00:53:57 Adjacency down 11.2 (Slot 21) 2014-06-29 00:54:05 Adjacency up 11.2 (Slot 21) on psilo.update.uu.se 2014-06-29 04:45:36 Adjacency timeout 47.556 (Slot 25) 2014-06-29 04:45:36 Adjacency down 47.556 (Slot 25) 2014-06-29 04:45:38 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-29 04:49:49 Adjacency timeout 47.556 (Slot 25) 2014-06-29 04:49:49 Adjacency down 47.556 (Slot 25) 2014-06-29 04:53:19 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-29 06:46:04 Adjacency up 62.637 (Slot 29) on psilo.update.uu.se 2014-06-29 08:01:32 Adjacency timeout 47.556 (Slot 25) 2014-06-29 08:01:32 Adjacency down 47.556 (Slot 25) 2014-06-29 08:01:33 Adjacency timeout 8.400 (Slot 23) 2014-06-29 08:01:33 Adjacency down 8.400 (Slot 23) 2014-06-29 08:03:04 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-29 08:03:51 Adjacency timeout 8.400 (Slot 23) 2014-06-29 08:03:51 Adjacency down 8.400 (Slot 23) 2014-06-29 08:04:39 Adjacency timeout 47.556 (Slot 23) 2014-06-29 08:04:49 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se 2014-06-29 08:04:50 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-29 08:05:52 Adjacency timeout 47.556 (Slot 25) 2014-06-29 08:05:52 Adjacency down 47.556 (Slot 25) 2014-06-29 08:08:06 Adjacency up 47.556 (Slot 25) on psilo.update.uu.se 2014-06-29 08:10:02 Adjacency timeout 8.400 (Slot 23) 2014-06-29 08:10:02 Adjacency down 8.400 (Slot 23) 2014-06-29 08:10:18 Adjacency up 8.400 (Slot 23) on psilo.update.uu.se

11 years

1
0
0 0

Quick cluster question

by Dave＠TheLennons.Net

Cory, If you want to share the SYSUAF.DAT (and you technically don't have to in a VMS cluster, but it gets a bit hairy with multiple ones), you would put it on a common disk directly mounted by all nodes and pointed to by the SYSUAF system logical name, oh and usually a bunch of other files are included with this, There is a template command procedure in SYS$STARTUP that describes them, I believe SYLOGICALS. A quorum disk is only needed to provide a vote, and usually only used in a two node cluster. Recent VMS versions do have external authentication capabilities but you still have a SYSUAF.DAT as a backup... - Dave On 6/12/2014 5:40 PM, Cory Smelosky wrote: Got a (hopefully) quick question regarding clustering I've got a VAX<---->Alpha cluster rolling (VAX for booting VAX satellites, Alpha for Alpha satellites) and I'm running in to an issue with the SYS$UAF stuff. Only the password/user DB...nothing else needs shared. What's the easiest way to share it between the VAX and Alpha nodes WITHOUT a using a quorum disk? 1). Kerberos or something? (I could have both query active directory...) 2). Shove SYS$UAF on MOIRA$dka100, mount in SYLOGICALS on all nodes? 3). Other

11 years, 1 month

1
0
0 0

Quick cluster question

by b4＠gewt.net

Got a (hopefully) quick question regarding clustering I've got a VAX<---->Alpha cluster rolling (VAX for booting VAX satellites, Alpha for Alpha satellites) and I'm running in to an issue with the SYS$UAF stuff. Only the password/user DB...nothing else needs shared. What's the easiest way to share it between the VAX and Alpha nodes WITHOUT a using a quorum disk? 1). Kerberos or something? (I could have both query active directory...) 2). Shove SYS$UAF on MOIRA$dka100, mount in SYLOGICALS on all nodes? 3). Other -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

11 years, 1 month

1
0
0 0

Parallel computing using DECnet

by e.olofsen＠xs4all.nl

For those working on parallel computing: rullfs::[.parallel] contains some routines in Fortran for VMS, inspired by TCGMSG and the paper with the SEM routines. Erik

11 years, 1 month

1
0
0 0

Latest version of VWS

by b4＠gewt.net

I think I might just wipe the drive and install from scratch. It has gotten a bit full of cruft over time. ;) Sent from my mobile^Wcorporate advertising device On 11 Jun 2014, at 05:40, Cory Smelosky <b4 at gewt.net> wrote: On Wed, 11 Jun 2014, Hans Vlems wrote: What is the value for intstackpages? May be as low as 4 and must be at least 6 (iirc) 25. Also: progress: MOIRA::CSMELOSKY$ type sys$manager:DECW$SERVER_0_ERROR.LOG 11-JUN-2014 05:35:07.0 Hello, this is the X server This is the DECwindows X11 display server for OpenVMS VAX V7.1-010215 compiled on Feb 15 2001 at 08:53:03 Dixmain address=00019c58 Server is running in bug-compatible mode Now attach all known txport images Can't start transports Yet: $ decw$device == "GAA0,GAB0,WSA1,WSA2,WSA3,WSA4,WSA4" $ ! decw$default_keyboard_map == "US_LK401AA" $ decw$server_transports == "DECNET,LOCAL,TCPIP" -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

11 years, 1 month

1
0
0 0

Latest version of VWS

by b4＠gewt.net

On Wed, 11 Jun 2014, Hans Vlems wrote: What is the value for intstackpages? May be as low as 4 and must be at least 6 (iirc) 25. Also: progress: MOIRA::CSMELOSKY$ type sys$manager:DECW$SERVER_0_ERROR.LOG 11-JUN-2014 05:35:07.0 Hello, this is the X server This is the DECwindows X11 display server for OpenVMS VAX V7.1-010215 compiled on Feb 15 2001 at 08:53:03 Dixmain address=00019c58 Server is running in bug-compatible mode Now attach all known txport images Can't start transports Yet: $ decw$device == "GAA0,GAB0,WSA1,WSA2,WSA3,WSA4,WSA4" $ ! decw$default_keyboard_map == "US_LK401AA" $ decw$server_transports == "DECNET,LOCAL,TCPIP" -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

11 years, 1 month

1
0
0 0

Latest version of VWS

by hvlems＠zonnet.nl

What is the value for intstackpages? May be as low as 4 and must be at least 6 (iirc) Verzonden vanaf mijn BlackBerry 10-smartphone. Origineel bericht Van: Brian Schenkenberger, VAXman- Verzonden: woensdag 11 juni 2014 03:12 Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Latest version of VWS Cory Smelosky <b4 at gewt.net> writes: On Tue, 10 Jun 2014, Brian Schenkenberger, VAXman- wrote: 8192. Looks like SET FILE/ATTRIB=LRL:8192 EWS012.A allowed BACKUP/LIST EWS012.A/SAVE to succeed. VMS DUMP the first block. You should see the BACKUP command in the ASCII translation. If there's a /BLOCK listed, use that value; otherwise, there are defaults as you have discovered. Didn't even need to DUMP it. VMSINSTAL didn't complain. Don't feel bad, I've been dealing with this for 20 years when trying to get VMS crash dump files from customers sent to me in tact via the internet. ;) I'm impressed I figured out that LRL was the value I wanted. ;) Luck. ;) Yup. ;) Next battle: anything graphical logs this: %%%%%%%%%%% OPCOM 10-JUN-2014 19:25:19.33 %%%%%%%%%%% Message from user AUDIT$SERVER on MOIRA Security alarm (SECURITY) and security audit (SECURITY) on MOIRA, system id: 9217 Auditable event: Detached process login failure Event time: 10-JUN-2014 19:25:19.32 PID: 20200149 Process name: _WSA3: Username: SYSTEM Process owner: [SYSTEM] Image name: MOIRA$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE Status: %DECW-F-NOMSG, Message number 02DB8204 Which makes no sense. $ SET MESSAGE SYS$MESSAGE:DECW$XLIBMSG.EXE $ EXIT %X02DB8204 %XLIB-F-CANTOPEN, cannot open display Do you, indeed, have the DECWindows server started? Is there a Gxx0: device? Configured? Channels assigned? Try setting SYSGEN parameter STARTUP_P2 to "VDC" in a conversational boot and then continue. You will find a STARTUP.LOG file in SYS$SYSTEM which might hold some clues. ;) -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.

11 years, 1 month

1
0
0 0

Latest version of VWS

by b4＠gewt.net

On Tue, 10 Jun 2014, Cory Smelosky wrote: I put the graphics board in the VS4000/60 (boot node) Device GFA0:, device type DECwindows output device, is online, enabled as operator terminal. Error count 0 Operations completed 4 Owner process "" Owner UIC [SYSTEM] Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL Reference count 0 Default buffer size 80 MOIRA::CSMELOSKY$ %%%%%%%%%%% OPCOM 11-JUN-2014 03:19:42.61 %%%%%%%%%%% Message from user AUDIT$SERVER on MOIRA Security alarm (SECURITY) and security audit (SECURITY) on MOIRA, system id: 9217 Auditable event: Detached process login failure Event time: 11-JUN-2014 03:19:42.60 PID: 20200127 Username: SYSTEM Process owner: [SYSTEM] Image name: MOIRA$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE Status: %DECW-F-NOMSG, Message number 02DB8204 No change. Other ideas? ;) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

11 years, 1 month

1
0
0 0

Latest version of VWS

by mcguire＠neurotica.com

On 06/10/2014 10:39 PM, Lee Gleason wrote: I'd do the same...except the cable doesn't provide an internal SCSI port...does it? I don't have any cables spare that would work I don't think. You'd need the expansion plate, I believe, because it provided the interface to the external disk and the rudimentary SCSI for the TK50Z. Connection-wise, all it takes is a 50 pin cable from the 50 pin IDC connector on the motherboard to a 50 pin narrow SCSI disk. I bolted the disk into the compartment in the unit where the RD54 was (used rubber spacers under it to suppress the noise even more). ...but it still goes "rrrrRRRRRRRRRRRRRR!" when it loads heads! ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

11 years, 1 month

1
0
0 0

Latest version of VWS

by lee.gleason＠comcast.net

I'd do the same...except the cable doesn't provide an internal SCSI port...does it? I don't have any cables spare that would work I don't think. You'd need the expansion plate, I believe, because it provided the interface to the external disk and the rudimentary SCSI for the TK50Z. Connection-wise, all it takes is a 50 pin cable from the 50 pin IDC connector on the motherboard to a 50 pin narrow SCSI disk. I bolted the disk into the compartment in the unit where the RD54 was (used rubber spacers under it to suppress the noise even more). -- Lee K. Gleason N5ZMR Control-G Consultants lee.gleason at comcast.net

11 years, 1 month

1
0
0 0

Announcing HECnetNT! (It's HECnet ported to Windows)

by jsteve＠superglobalmegacorp.com

For the two or three people that may care, I ported the latest version of the HECnet bridge to Windows. This isn't a MinGW or Cygwin port, but a native Win32 console version. I've been able to use it with Windows NT 4.0 Terminal Server, and binding Pathworks 7 on a loopback interface, and then using HECnetNT to bridge it to a Linux box with HECnet, that had a SIMH VAX. Memory and CPU utilization seems to be pretty small. As an added bonus I added support for Ethernet_II so you can build NetWare networks, and added in LZSS if desired to make compressed bridges. However it'll parse original configurations, and operate in a normal uncompressed manner by default. I uploaded it to sourceforge here: http://sourceforge.net/projects/hecnetnt/ Thanks! Jason

11 years, 1 month

1
0
0 0

Latest version of VWS

by b4＠gewt.net

On Tue, 10 Jun 2014, Cory Smelosky wrote: Doesn't make sense. MOIRA::CSMELOSKY$ @sys$startup:decw$startup %DECW-W-NODEVICE, No graphics device found on this system -DECW-I-NODECW, DECwindows graphics drivers will not be loaded MOIRA::CSMELOSKY$ MOIRA::CSMELOSKY$ @sys$startup:ews$startup MOIRA::CSMELOSKY$ %%%%%%%%%%% OPCOM 10-JUN-2014 20:06:57.19 %%%%%%%%%%% Message from user DECNET on MOIRA DECnet event 0.3, automatic line service

11 years, 1 month

1
0
0 0

Latest version of VWS

by b4＠gewt.net

On Tue, 10 Jun 2014, Brian Schenkenberger, VAXman- wrote: $ SET MESSAGE SYS$MESSAGE:DECW$XLIBMSG.EXE $ EXIT %X02DB8204 %XLIB-F-CANTOPEN, cannot open display Do you, indeed, have the DECWindows server started? Is there a Gxx0: device? Configured? Channels assigned? DECWindows is started and I do NOT have a Gxx0: device. Try setting SYSGEN parameter STARTUP_P2 to "VDC" in a conversational boot and then continue. You will find a STARTUP.LOG file in SYS$SYSTEM which might hold some clues. ;) I would...except the error is generated from VAXELN. ;) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

11 years, 1 month

1
0
0 0

Latest version of VWS

by system＠TMESIS.COM

Cory Smelosky <b4 at gewt.net> writes: On Tue, 10 Jun 2014, Brian Schenkenberger, VAXman- wrote: 8192. Looks like SET FILE/ATTRIB=LRL:8192 EWS012.A allowed BACKUP/LIST EWS012.A/SAVE to succeed. VMS DUMP the first block. You should see the BACKUP command in the ASCII translation. If there's a /BLOCK listed, use that value; otherwise, there are defaults as you have discovered. Didn't even need to DUMP it. VMSINSTAL didn't complain. Don't feel bad, I've been dealing with this for 20 years when trying to get VMS crash dump files from customers sent to me in tact via the internet. ;) I'm impressed I figured out that LRL was the value I wanted. ;) Luck. ;) Yup. ;) Next battle: anything graphical logs this: %%%%%%%%%%% OPCOM 10-JUN-2014 19:25:19.33 %%%%%%%%%%% Message from user AUDIT$SERVER on MOIRA Security alarm (SECURITY) and security audit (SECURITY) on MOIRA, system id: 9217 Auditable event: Detached process login failure Event time: 10-JUN-2014 19:25:19.32 PID: 20200149 Process name: _WSA3: Username: SYSTEM Process owner: [SYSTEM] Image name: MOIRA$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE Status: %DECW-F-NOMSG, Message number 02DB8204 Which makes no sense. $ SET MESSAGE SYS$MESSAGE:DECW$XLIBMSG.EXE $ EXIT %X02DB8204 %XLIB-F-CANTOPEN, cannot open display Do you, indeed, have the DECWindows server started? Is there a Gxx0: device? Configured? Channels assigned? Try setting SYSGEN parameter STARTUP_P2 to "VDC" in a conversational boot and then continue. You will find a STARTUP.LOG file in SYS$SYSTEM which might hold some clues. ;) -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG I speak to machines with the voice of humanity.

11 years, 1 month

1
0
0 0

Latest version of VWS

by b4＠gewt.net

On Tue, 10 Jun 2014, Brian Schenkenberger, VAXman- wrote: 8192. Looks like SET FILE/ATTRIB=LRL:8192 EWS012.A allowed BACKUP/LIST EWS012.A/SAVE to succeed. VMS DUMP the first block. You should see the BACKUP command in the ASCII translation. If there's a /BLOCK listed, use that value; otherwise, there are defaults as you have discovered. Didn't even need to DUMP it. VMSINSTAL didn't complain. Don't feel bad, I've been dealing with this for 20 years when trying to get VMS crash dump files from customers sent to me in tact via the internet. ;) I'm impressed I figured out that LRL was the value I wanted. ;) Luck. ;) Yup. ;) Next battle: anything graphical logs this: %%%%%%%%%%% OPCOM 10-JUN-2014 19:25:19.33 %%%%%%%%%%% Message from user AUDIT$SERVER on MOIRA Security alarm (SECURITY) and security audit (SECURITY) on MOIRA, system id: 9217 Auditable event: Detached process login failure Event time: 10-JUN-2014 19:25:19.32 PID: 20200149 Process name: _WSA3: Username: SYSTEM Process owner: [SYSTEM] Image name: MOIRA$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE Status: %DECW-F-NOMSG, Message number 02DB8204 Which makes no sense. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

11 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet