Skip to content
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

Support for using Chaosnet streams (provided by cbridge). #23

Merged
merged 15 commits into from
Sep 24, 2020

Conversation

bictorv
Copy link
Contributor

@bictorv bictorv commented Sep 18, 2020

f the host parameter given can be on Chaosnet (based on DNS or that it's a valid 16-bit chaos address, and that cbridge allows a connection), connect using the stream interface of cbridge, else use Internet as usual.

Also send three extra Supdup variables (supported by ITS), and some minor things.

Don't translate it, just show it. See RFC 734, bottom of page 3.
Send input and output speeds, and the local userid (first 6 chars).

Plus don't crash when debug is turned on.
Clear the line for "Connection closed" and also after, to make the message more readable.
of the Chaosnet stuff.
...of the Chaos stuff. But really, the rest should also be cleaned up.
@larsbrinkhoff
Copy link
Member

I tested a regular TCP supdup to up.update.uu.se, and it didn't work. The old supdup works.

$ ./supdup up.update.uu.se
Trying 130.238.19.215 port 95 ...Connected to up.update.uu.se.
Escape character is "C-^".
UPdate KLH-10
Connection closed by up.update.uu.se.

@bictorv
Copy link
Contributor Author

bictorv commented Sep 19, 2020

"it works for me", so could you be more specific about what doesn't work? Possibly run with -d when it doesn't work?

@larsbrinkhoff
Copy link
Member

Here's the output when run with -d. If you like, you can get an account on my machine.

(Side note: Do we want SAIL characters or CR LF here?)

connect(server): No such file or directory
setsockopt (SO_DEBUG): Invalid argument
Trying 130.238.19.215 port 95 ...Connected to up.update.uu.se.
Escape character is "C-^".
State: 0, Incoming: 0125. Translation: U
State: 0, Incoming: 0120. Translation: P
State: 0, Incoming: 0144. Translation: d
State: 0, Incoming: 0141. Translation: a
State: 0, Incoming: 0164. Translation: t
State: 0, Incoming: 0145. Translation: e
State: 0, Incoming: 040. Translation:  
State: 0, Incoming: 0113. Translation: K
State: 0, Incoming: 0114. Translation: L
State: 0, Incoming: 0110. Translation: H
State: 0, Incoming: 055. Translation: -
State: 0, Incoming: 061. Translation: 1
State: 0, Incoming: 060. Translation: 0
State: 0, Incoming: 015. Translation: circled plus
State: 0, Incoming: 012. Translation: delta
UPdate KLH-10
Connection closed by up.update.uu.se.

@bictorv
Copy link
Contributor Author

bictorv commented Sep 19, 2020

It's gcc which treats a plain "char" declaration as "unsigned char". Changing inits from "char" to "signed char" makes it work also on Linux. (Why does it do that? Is it some new stupid standard?)

Sorry, not quite sufficient: being in a hurry, just #if 0 ... #endif around adding the new Supdup variables at the end of sup_term() makes it, for now.

(The translation is not actually done until the first TDNOP, as per one of my recent patches.)

Look more closely at this later.
@ams
Copy link
Contributor

ams commented Sep 19, 2020 via email

@larsbrinkhoff
Copy link
Member

Oh, a language lawyer thread!

It's certainly true that the signedness of char in C is unspecified, but an argument can be made that changing this choice on a particular platform isn't a good practice. Programs that once worked may suddenly break, potentially making lots of people unhappy or worse, silently hiding security problems.

Copy link
Member

@larsbrinkhoff larsbrinkhoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this now works for me too.

@ams
Copy link
Contributor

ams commented Sep 19, 2020 via email

@bictorv
Copy link
Contributor Author

bictorv commented Sep 20, 2020

Next time I have too much time, I'll rewrite everything in a high-level language...

Aaarg.

cfget[io]speed does not necessarily return the speed, but an identifier for the speed. How not-so-useful.

setupterm clobbers global variables [io]speed, so need to have private variables named differently.
@larsbrinkhoff
Copy link
Member

larsbrinkhoff commented Sep 20, 2020 via email

@larsbrinkhoff
Copy link
Member

I don't know if it's applicable here, but ITS also handles 40k, 50k, and 80k bits/s.

@bictorv
Copy link
Contributor Author

bictorv commented Sep 20, 2020

I know (now), but "unix" doesn't. And really, nobody seems to care. :-)

@bictorv bictorv merged commit a7683e1 into PDP-10:master Sep 24, 2020
@ams
Copy link
Contributor

ams commented Sep 25, 2020

FWIW, this breaks on OpenBSD. Mostly due to the fact that -lresolv doesn't exist there (nor on some other BSDs), normally these days the libresolv stuff is provided directly by libc both on BSDs and GNU systems but OS X seems to not have followed suite? Dynamically adding -lresolv to the linker line is slightly tricky to do in some form of portable Make -- since everyone wants to be special.

@bictorv
Copy link
Contributor Author

bictorv commented Sep 25, 2020

autoconf, anyone? Also, feel free to add some #ifdef to avoid the DNS code and just look for numeric chaos addresses?
But also, not all resolver libraries are equivalent, as I discovered implementing the DNS part of cbridge. I forgot the details, I'm afraid, but if you would try to get it working on OpenBSD you might discover?

@ams
Copy link
Contributor

ams commented Sep 25, 2020

I'd like to avoid autoconf/automake, mostly since this is such a tiny program. And it brings its own set of complications (generating the configure scripts, on OpenBSD one needs to export a few environment variables for it to work well, etc)... But I'll see what I can figure out both for supdup, and cbridge (where I think I have some autoconf hackery pending?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants