HECnet

hecnet@lists.dfupdate.se

15556 discussions

by gregg.drwho8＠gmail.com

On Thu, May 16, 2013 at 9:27 PM, Cory Smelosky <b4 at gewt.net> wrote: On Thu, 17 May 2013, Paul_Koning wrote: On May 16, 2013, at 5:58 PM, Johnny Billquist wrote: On 2013-05-16 22:16, Jordi Guillaumes i Pons wrote: Al 15/05/13 22:52, En/na Cory Smelosky ha escrit: What does it use for network device? It's using the NI right now, as it's KLH10. Speaking of devices... has anyone been succesful configuring KLH10 to use a tap interface? I have not been able to do that, so I have to share the host real ethernet, thus making not posible to run two instances of KLH10 in the same host (unless I run those inside a VM, which is a little bit overkill). Oh, and a weird thing... I have a simulated TOPS-10 under KLH10 with DECNET up and running... but it can talk only to its adjacent nodes. It seems like the routing node (a simh 780 running VMS 4.7) does not route traffic (in either direction) when the destination or the source is the KLH10... Weird. Are you sure it talks ok with the routing node? I mean, have you actually used any protocol to test, or just noted the adjacency up messages? The reason I ask is that the adjacency up messages are not really enough to be sure that the link really is working. One thing to remember is that a router adjacency "up" transition does not make anything reachable (except on DECnet/E which doesn't quite do things according to the spec). Only when the routing messages are exchanged after the adjacency comes up is anything marked as reachable. Yes, that includes the neighbor router, by spec (this is the part that DECnet/E does differently). paul One amusing issue: I kept getting adjacency up notices about my TOPS-10 install...but no down notices. ;) -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments Hello! My doing. Now how come you, Cory, didn't react regarding my description of how your network for the TOPS-10 setup was arranged? Or that of stirring in the monster from the WB cartoons? ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

12 years

Re: TOPS-10 and DECnet Progress Update

by b4＠gewt.net

On Thu, 17 May 2013, Paul_Koning wrote: On May 16, 2013, at 5:58 PM, Johnny Billquist wrote: On 2013-05-16 22:16, Jordi Guillaumes i Pons wrote: Al 15/05/13 22:52, En/na Cory Smelosky ha escrit: What does it use for network device? It's using the NI right now, as it's KLH10. Speaking of devices... has anyone been succesful configuring KLH10 to use a tap interface? I have not been able to do that, so I have to share the host real ethernet, thus making not posible to run two instances of KLH10 in the same host (unless I run those inside a VM, which is a little bit overkill). Oh, and a weird thing... I have a simulated TOPS-10 under KLH10 with DECNET up and running... but it can talk only to its adjacent nodes. It seems like the routing node (a simh 780 running VMS 4.7) does not route traffic (in either direction) when the destination or the source is the KLH10... Weird. Are you sure it talks ok with the routing node? I mean, have you actually used any protocol to test, or just noted the adjacency up messages? The reason I ask is that the adjacency up messages are not really enough to be sure that the link really is working. One thing to remember is that a router adjacency "up" transition does not make anything reachable (except on DECnet/E which doesn't quite do things according to the spec). Only when the routing messages are exchanged after the adjacency comes up is anything marked as reachable. Yes, that includes the neighbor router, by spec (this is the part that DECnet/E does differently). paul One amusing issue: I kept getting adjacency up notices about my TOPS-10 install...but no down notices. ;) -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years

Re: TOPS-10 and DECnet Progress Update

by Paul_Koning＠Dell.com

On May 16, 2013, at 5:58 PM, Johnny Billquist wrote: On 2013-05-16 22:16, Jordi Guillaumes i Pons wrote: Al 15/05/13 22:52, En/na Cory Smelosky ha escrit: What does it use for network device? It's using the NI right now, as it's KLH10. Speaking of devices... has anyone been succesful configuring KLH10 to use a tap interface? I have not been able to do that, so I have to share the host real ethernet, thus making not posible to run two instances of KLH10 in the same host (unless I run those inside a VM, which is a little bit overkill). Oh, and a weird thing... I have a simulated TOPS-10 under KLH10 with DECNET up and running... but it can talk only to its adjacent nodes. It seems like the routing node (a simh 780 running VMS 4.7) does not route traffic (in either direction) when the destination or the source is the KLH10... Weird. Are you sure it talks ok with the routing node? I mean, have you actually used any protocol to test, or just noted the adjacency up messages? The reason I ask is that the adjacency up messages are not really enough to be sure that the link really is working. One thing to remember is that a router adjacency "up" transition does not make anything reachable (except on DECnet/E which doesn't quite do things according to the spec). Only when the routing messages are exchanged after the adjacency comes up is anything marked as reachable. Yes, that includes the neighbor router, by spec (this is the part that DECnet/E does differently). paul

12 years

Another sillyness. More information in the nodename database on MIM.

by Paul_Koning＠Dell.com

On May 16, 2013, at 6:15 PM, Johnny Billquist wrote: On 2013-05-16 23:12, Paul_Koning at Dell.com wrote: ... The routing part looks pretty good right now. I don't have it active all the time yet, but I hooked it into Multinet and it appeared to be stable. The main issue is that point to point DECnet over UDP is architecturally invalid; the initialization state machine isn't designed for that. The result is that it takes a while for both sides to agree that the circuit is "Up". I've been thinking of workaround for the misbehavior. A cleaner solution is to run Multinet over TCP, which appears to exist -- if someone can figure out how to do that and what the packet formats look like for that case, I'll implement it. Alternatively, the SIMH DMC11 protocol works very well, it would clearly be a superior solution for Hecnet. I haven't looked enough to really make sensible comments, but in which way is point-to-point over UDP invalid? I would have thought that wouldn't be any different than if you had an ethernet segment with just two nodes on it (I'm assuming Multinet UDP tunnels act like ethernet, but I might be wrong on that one as well...) No, the Multinet UDP tunnel uses the point to point datalink dependent sublayer of DECnet. Quoting from the Phase IV routing spec: The required Data Link Layer guarantees for point-to-point links are: 1. Provision that both source and destination nodes complete start-up before message exchange can occur 2. Detection of remote start-up 3. Provision that no old messages be received after start-up is complete 4. Masking of transient errors in order to prevent packet data corruption 5. Provision for not duplicating or corrupting packets 6. Packet sequentiality ensuring that, if a packet has been received, all previously sent packets have been received 7. Reporting of failures and degraded circuit conditions The required Data Link Layer guarantees for Ethernets are: 1. Provision for not corrupting packets 2. Packet sequentiality ensuring that, if a packet has been received, no previously sent packet will be subsequently received So the expectations on the datalink layer are dramatically different. And as a result, the algorithms in the routing layer are, also. In particular, the circuit initialization state machine in the routing layer (chapter 7 of the spec) relies quite strongly on many of the stated requirements. The DMC emulation in SIMH implements all of those requirements, which is why it works very well indeed. On the other hand, UDP implements requirements 4 and 5, but none of the rest. The lack of properties 1, 2, and 3 completely invalidates the circuit initialization state machine (its design is very much dependent on those properties being satisfied). I can see the proof of this all the time if I trace what happens on a Multinet link. It keeps cycling because one end or the other receives an init message while in run state. That happens when the other end restarts, but since #2 is missing, the state machine sees that as an unexpected message in run state rather than a preceding datalink restart when that message is expected to be seen next. With enough retries (and, perhaps, some luck) the two ends eventually come to the right conclusion, but it takes a lot of cycling. I think I can make some nonstandard changes to the state machine to work around this issue. After all, it's obvious enough that one can design a datalink dependent sublayer for UDP -- it's just that there isn't one in the DECnet Phase IV architecture. And whoever contrapted the UDP based Multilink tunnel either didn't care about that or didn't understand what he was doing wrong. paul

12 years

Another sillyness. More information in the nodename database on MIM.

by bqt＠softjar.se

On 2013-05-17 02:56, G. wrote: On Thu, 16 May 2013 20:30:33 +0200, you wrote: Being border, I actually created a simple web page for it now. http://madame.update.uu.se/~bqt/nodedb Very nice! So, there is another Italian who is not part of our group, the world's so small... :o G. (border, aren't you? :D) Meh. ;-) Actually, the whole web-interface thingy was pretty easy. In total, it is 82 lines of IND, along with about 10 lines of Datatrieve function. I'm almost having fun... 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

12 years

Another sillyness. More information in the nodename database on MIM.

by Paul_Koning＠Dell.com

On May 16, 2013, at 5:43 PM, Robert Jarratt wrote: ... YOu can see the work in progress at svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet . No documentation to speak of yet, I should work on that... paul You seem to have got much further than I have. Although I do have enough of NSP and NICE to allow SH KNOWN CIRCUIT and SH ADJACENT NODES. I don't have any real NSP at all yet, so in that part you're clearly way ahead. NSP is a fair chunk of work (especially since I don't know it nearly as well as I do routing). On the other hand, Python makes a lot of what needs to be done a great deal easier than it is in C, especially once I put some infrastructure together. Packet parsing is an example. paul

12 years

DECserver software collection

by gerry77＠mail.com

On Thu, 16 May 2013 17:04:36 +0200, you wrote: Thanks. That was a great summary. We should just make them all available on HECnet as well. Care to send me copies? Or do someone already have all of them available? Like I said before, a few of them are already on MIM. You have mail. :) Compared to the summary I posted here, the archive I've sent you contains one more file and a couple corrections in the accompanying text. HTH, G.

12 years

Another sillyness. More information in the nodename database on MIM.

by gerry77＠mail.com

On Thu, 16 May 2013 20:30:33 +0200, you wrote: Being border, I actually created a simple web page for it now. http://madame.update.uu.se/~bqt/nodedb Very nice! So, there is another Italian who is not part of our group, the world's so small... :o G. (border, aren't you? :D)

12 years

Another sillyness. More information in the nodename database on MIM.

by wonko＠4amlunch.net

On May 16, 2013, at 18:07, Sampsa Laine <sampsa at mac.com> wrote: On 16 May 2013, at 23:06, Paul_Koning at Dell.com wrote: On May 16, 2013, at 4:38 PM, Sampsa Laine wrote: DECnet/Python? What's this exactly? sampsa A project of mine, inspired by the user mode router project Rob Jarratt is doing. It's the DECnet protocol stack implemented in Python. So it should be portable (right now it runs on Mac OS and Linux). And it's easy to implement because of the power of Python (for example, the on-NI cache is about 10 lines of code). Right now I have datalink (Ethernet, SIMH DMC11 emulation, Multinet over UDP), Routing (Phase IV endnode, L1 router, L2 router, over both datalink types), MOP (Ethernet only, including console carrier), primitive monitoring via HTTP, and about 3% of NSP. My goal is to make this a pretty complete DECnet implementation (Phase II through IV all in one). Ideally, that will include an API so you can write DECnet applications that use this stack as the protocol implementation. In other words, something that looks similar to DECnet sockets API, but inside the library it talks to the DECnet/Python daemon, NSP and below live there. YOu can see the work in progress at svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet . No documentation to speak of yet, I should work on that... paul Oh cool, was just thinking about writing stuff in Python for DECNET. Let me know when the stack is stable. Yeah, I'm very excited for this. The DECnet mapping project is going to be a ton easier once he finishes NCP (and I get the chance to test his moprc stuff against my cisco router). -brian

12 years

Another sillyness. More information in the nodename database on MIM.

by bqt＠softjar.se

On 2013-05-16 23:12, Paul_Koning at Dell.com wrote: On May 16, 2013, at 5:07 PM, Sampsa Laine wrote: On 16 May 2013, at 23:06, Paul_Koning at Dell.com wrote: On May 16, 2013, at 4:38 PM, Sampsa Laine wrote: DECnet/Python? What's this exactly? sampsa A project of mine, inspired by the user mode router project Rob Jarratt is doing. It's the DECnet protocol stack implemented in Python. ... Oh cool, was just thinking about writing stuff in Python for DECNET. Let me know when the stack is stable. The routing part looks pretty good right now. I don't have it active all the time yet, but I hooked it into Multinet and it appeared to be stable. The main issue is that point to point DECnet over UDP is architecturally invalid; the initialization state machine isn't designed for that. The result is that it takes a while for both sides to agree that the circuit is "Up". I've been thinking of workaround for the misbehavior. A cleaner solution is to run Multinet over TCP, which appears to exist -- if someone can figure out how to do that and what the packet formats look like for that case, I'll implement it. Alternatively, the SIMH DMC11 protocol works very well, it would clearly be a superior solution for Hecnet. I haven't looked enough to really make sensible comments, but in which way is point-to-point over UDP invalid? I would have thought that wouldn't be any different than if you had an ethernet segment with just two nodes on it (I'm assuming Multinet UDP tunnels act like ethernet, but I might be wrong on that one as well...) 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

12 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet