-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable NCP; make Arpanet great again #2348
Comments
FYI @Quantx |
Turning on NCPP, I noticed SYSTEM;CORE uses DMI in conditionals. That needs to be updated to use KAIMP or DMIMP. EDIT: Adding NCP to the already big KA ITS makes it necessary to move up SALV even higher. |
Maybe the KS10 can't do Arpanet since the new IMP code doesn't have NCP. The KA10 and KL10 use the "IMPOLD WTHNCP" code. |
Various updates to the KA10 and H316 are emulators are needed. With things fixed, I can attempt to make a TELNET connection back to the same ITS host.
What's going on here is that before making the TELNET connection, ITS sends a RST (reset) message to the peer. This is probably because ITS hasn't had any contact with the peer since booting. However, there's a timeout waiting for the RRP (reset reply) acknowledgement. The RRP is sent, but somewhat later. Then there's a complaint that there was an RRP received but no RST in progress. |
Note to self: check if this works for incoming Arpanet connections. The IMPUS (Arpanet) address is unconditionally commented out and replaced with IMPUS3 (IP address).
|
See also #2349 "ITS code duplicated between NET and NCP." There are assembler errors if NCPP=1 and INETP=0. |
Work in progress on these branches:
|
Note to self: look into #1475 |
I'm testing ITS together with the "Linux NCP" (need a better name?) I was "pinging" from the Linux host to ITS, i.e. sending an ECO (echo) and expecting an ERP (echo reply) back. I see the UDP packets arriving safely on the ITS side, but I wasn't seeing any replies. I checked the code, and indeed ITS is supposed to reply. After a few reruns and several pings later, I checked the logs by chance and did see one ERP in the IMP and Linux logs. So similar to the very late RRP (reset reply) I mentioned above, there seems to be some delay going on. I put breakpoints on the IMP interrupt handlers and didn't see anything. Strangely, when I TELNET from ITS to itself, I do hit the breakpoints. The ITS messages are about 24 bits longer, for some unknown reason. The Host-Host protocol specification says there is an "M3" field after an NCP message, with 0 or more bits of padding. I figured 0 would be ok, but maybe not. |
Indeed there was no interrupt raised for incoming data, because I had missed to handle a corner case. Now that I do, ITS will reply to the ECO messages from "Linux NCP". Testing with two ITS hosts on the network, I get a reaction to a TELNET connection: Still, clearly a step forward. The hosts successfully exchange RST (reset) and RRP (reset reply) messages. |
I rebuilt NETRFC with DEMONP=0 and made the LBSIGN links for RFC027 (telnet). This seems to have done the trick. I made a prototype TELNET client to tickle ITS, and I'm getting some data back. |
Various updates to my NCP and TELNET client later, I get this session. It's not perfect, e.g. no echo handling or cbreak mode yet, but it shows promise.
|
The text was updated successfully, but these errors were encountered: