Can's use ssh-chat properly

[bsapwindows]

There's a tiny issue with the terminal window. After ssh-keygen, I tried to play with ssh-chat with ssh chat.shazow.net, I can join and see others talking but it seems I can not send any messages.

[s-macke]

I can reproduce the error. It works perfect with my own Linux system. So there might be indeed an error in jor1k. However I don't know what's the reason.
The console input stream is the same for both cases. So it might be a configuration problem in ssh or Linux.
The best way would be to run a ssh-chat server with debug output and see what happens.
Because there also might be an error in ssh-chat.

[bsapwindows]

I've set up an ssh-chat server and run with --verbose flag on my relay, no error showed up. And you may have noticed that ctrl + c will still kill the process after you join the chat, which normally it shouldn't, you have to use /exit instead.

Have you tried this: ssh into the jor1k instance then use ssh chat.shazow.net from there, it will work as intended. (I sshed through my own relay, I wish there's an ngrok port for OpenRISC, though due to my limited skill and knowledge, I don't know how to compile g++ and golang for OpenRISC...)

By the way, can we bind ctrl + w as well? I tried to use ctrl +w to search keywords in nano, it closed the window....

[s-macke]

Thanks for the detailed error description. I tried to run the ssh connection within tmux and it works. That means, that something is wrong with the terminal. I guess I have to ask some terminal experts.
I don't have a clue and actually I don't want to know (but I will find out) what is wrong this time. The terminal stuff is just a whole undocumented mess.

ngrok sounds like fun. Let's see. :)
I guess with the websocket script you can punch a hole automatically into your firewall, that each running instance of jor1k has a least one open port.

[s-macke]

http://unix.stackexchange.com/questions/102061/ctrl-c-handling-in-ssh-session
This website explains the differences for the ssh connection types and the behavior of the terminal.

It looks like ssh treats this session as non-interactive instead of interactive.

[s-macke]

I can force the problem with the "ssh -t" option. Looks like, he cannot open a pseudoterminal. I get the error "PTY allocation request failed on channel 0"
I guess ssh switches to the wrong mode after this error.

[s-macke]

Looks like the pty terminal size negotiation failed because the number of columns were not set. According to the busybox "stty -a" they were already set to 80. Looks like an error in busybox.

This one fixes the problem: 8aff35f

[bsapwindows]

Thanks! It fixed sending message issue. But it should be color enabled in the chat, which it isn't. Could you tell me what are the possible factors that cause this? I set TERM to xterm-256color, it says Error opening terminal: xterm-256color, set it to xterm, still no color, and it broke the layout of ncurses programs like htop.

[s-macke]

Yes, that's normal. The terminal is a basic one: TERM=linux which is supposed to be the one included in the Linux kernel for framebuffer terminals. You can try if you get color in this type of terminal.

The term variable is usually provided by ssh. the correct way for ssh-chat is to read the variable and to put it into ncurses to get the correct escape sequences for the specific terminals. Obviously this is not done here.
That you don't see color might mean, that ssh-chat uses extended escape sequences, which I don't support. Especially the 256 color support. I can take a look.
So officially the error is in ssh-chat. Unofficially there is an agreement, that the behavior of xterm is more or less standard nowadays. A monster with I think more than 50000 lines of code just for the terminal emulation part. My terminal has less than 1000 lines.

@shazow

[bsapwindows]

😄 Cool! I just looked into the code of ssh-chat, I think you are right. Thanks!

[shazow]

Yup, ssh-chat has multiple theme settings. Auto-detecting based on the TERM value is still something that needs to be done. :)

[s-macke]

btw. ngrok is based on the go language.
And there is no port of the backend for OpenRISC:
http://golang.org/doc/install/source#environment

[bsapwindows]

@s-macke sadly yes. But because of that I tried to find an alternative, and I found a C port of ngrok a few days back. The reason of its existence is very considerate. The usage of it is not as elegant as original ngrok's though. And before the day I post this issue here, I found ngrok-c contains cpp code that requires g++ to compile, so... can't have that either at the moment...

You did mention about punching a hole into the relay's firewall, I think it's a very good and much simpler workaround 😃 Nothing so different from using ngrok if we focus on tunneling feature, a public server is needed in both ways anyway.

[s-macke]

I can cross compile C++ code. This is no problem.
However it is not included in the filesystem in https://github.com/s-macke/jor1k-sysroot because of its size.