I see that if while sending file to other device with teraterm kermit the other devise disconnect/stops receiving the file, the teraterm freeze (with kermit window opened).
I would expect there will be some timeout option but I couldn't find such. is there is such option or other ways to fix it?
Optional solution is to send teraterm the kermit error (E) packet which will cause teraterm to stop kermit. The packet structure can be found at https://www.kermitproject.org/kproto.pdf 4.1.
This is the right way to cause teraterm stop session if you are the other device and decided to stop receiving, but in case that the device disconnected it may also be workaround to open new connection with teraterm and send it the error pcket.
Related
As we know the messages in buffer shall be still sent out even after socket closed. this is usefull, but there's a use case that we want to wait the messages is sent and acked by peer,
e.g. in embeded device, a firmware upgrade function in web ui. after upgrade done a message is sent to web ui then reboot the device. we want the message is sent and acked, or reboot may drop messages. then web ui lost reply.
so, is there a way in linux wait a socket (closed or not closed) sent out and acked all messages ?
As we know, when the ssh connection is gone, the bash will receive a SIGHUP, and forward this signal to all its children.
I wonder who is the original sender of this SIGHUP, is it ssh client, ssh server, OS or something else?
I read the code of openssh-portabal, and I found only here uses the SIGHUP: https://github.com/openssh/openssh-portable/blob/master/sshconnect.c#L285
And the caller seems to be client:
https://github.com/openssh/openssh-portable/blob/master/ssh.c#L1533
I didn't find any sender code in the server-side sshd.c
Does this mean that the sender is client? In this case, the SIGHUP will not be received by the server if the connection was interrupted. I'm not pretty sure about this, but in my experience this doesn't seem to be true.
So I'm curious about who is supposed to be the original sender. Is there a standard for this?
The bash process on the server side of the connection is running with its controlling terminal set to the slave side of a pseudo-terminal pair, with the master side attached to the sshd process.
When the connection is terminated, the sshd process closes the master side of the pseudo-terminal, which results in the kernel pseudo-terminal driver hanging up the slave side of the pseudo-terminal. When the slave side is hung up, the kernel tty core sends SIGHUP and SIGCONT signals to the terminal's session leader (which is usually that bash process) and every process in the session leader's process group.
This isn't specific to pseudo-terminals and ssh - the same thing happens if you are dialled in to the server over a modem attached to a serial port and the modem hangs up (which is where the "hang up" / SIGHUP naming originates). As you can tell, this is historical behaviour of very long standing.
I'm using node.js, websockets/ws.
In my site sometimes a random client loses connection without losing connection to other internet stuff. Less then a second later they connect back, with a new socket. (There is a code that calls socket.onClose, which tries to reconnect back to server)
On the server side I can't see or log anything wrong. Everything looks like a normal disconnect, same as closing the browser tab.
I am guessing the reason is either socket related or client related but I don't know where to begin to debug this problem.
I got ping/pong responses with 60 second timer, this isn't it. The user usually loses connection while active.
How can I debug this problem and find the reason?
I keep all the session info, data, within the socket and that is why I do not want people to lose their connection.
Thanks
I have a production app that uses socket.io (node.js back-end)to distribute messages to all the logged in clients. Many of my users are experiencing disconnections from the socket.io server. The normal use case for a client is to keep the web app open the entire working day. Most of the time on the app in a work day time is spent idle, but the app is still open - until the socket.io connection is lost and then the app kicks them out.
Is there any way I can make the connection more reliable so my users are not constantly losing their connection to the socket.io server?
It appears that all we can do here is give you some debugging advice so that you might learn more about what is causing the problem. So, here's a list of things to look into.
Make sure that socket.io is configured for automatic reconnect. In the latest versions of socket.io, auto-reconnect defaults to on, but you may need to verify that no piece of code is turning it off.
Make sure the client is not going to sleep such that all network connections will become inactive get disconnected.
In a working client (before it has disconnected), use the Chrome debugger, Network tab, webSockets sub-tab to verify that you can see regular ping messages going between client and server. You will have to open the debug window, get to the network tab and then refresh your web page with that debug window open to start to see the network activity. You should see a funky looking URL that has ?EIO=3&transport=websocket&sid=xxxxxxxxxxxx in it. Click on that. Then click on the "Frames" sub-tag. At that point, you can watch individual websocket packets being sent. You should see tiny packets with length 1 every once in a while (these are the ping and pong keep-alive packets). There's a sample screen shot below that shows what you're looking for. If you aren't seeing these keep-alive packets, then you need to resolve why they aren't there (likely some socket.io configuration or version issue).
Since you mentioned that you can reproduce the situation, one thing you want to know is how is the socket getting closed (client-end initiated or server-end initiated). One way to gather info on this is to install a network analyzer on your client so you can literally watch every packet that goes over the network to/from your client. There are many different analyzers and many are free. I personally have used Fiddler, but I regularly hear people talking about WireShark. What you want to see is exactly what happens on the network when the client loses its connection. Does the client decide to send a close socket packet? Does the client receive a close socket packet from someone? What happens on the network at the time the connection is lost.
webSocket network view in Chrome Debugger
The most likely cause is one end closing a WebSocket due to inactivity. This is commonly done by load balancers, but there may be other culprits. The fix for this is to simply send a message every so often (I use 30 seconds, but depending on the issue you may be able to go higher) to every client. This will prevent it from appearing to be inactive and thus getting closed.
I have programmed a D-Link GSM modem on a windows machine to send and receive SMS, for testing I used Hyperterminal.
In windows the connection manager initiates the COMx ports, modem uses one unlisted COMx port through which I can send an SMS, and through a listed NMEA port I receive incoming SMS, calls like +CMTI: "ME", 11 or RING +CLIP: XXXXXXXXXXXX
I'm successfully interpreting the message and programming it to my requirements in windows. While trying the same in linux(Fedora), I see the modem initialises /dev/ttyUSB0 and /dev/ttyUSB1 as the two newly identified devices. I use minicom to set the device ports and communicate AT commands to the same.
In both the devices (/dev/ttyUSB0 and /dev/ttyUSB1) I'm not receiving unsolicited AT result code like +CMTI indication whenever I'm expecting a new SMS. FYI I've set the CNMI setting according to the manual and several other combinations.
A strange thing is that I'm able to see RING when I'm calling but not +CLIP: <callerinfo>. Similarly I'm not getting ++PSBEARER: XX, Y or +CMTI: "ME", XX
The only alternative solution is to poll the UNREAD messages at regular intervals, which is generally a bad design. Please tell me if I'm doing anything wrong with regards to the configuration, should I change some thing else apart from these?
RING is the only UR code you can assume that will always come without any specific configuration (just because this is such an old relic that it just behaves that way...). For all other UR codes, you must explicit enable each and every one of them, e.g. AT+CLIP=1, etc, otherwise they will not be enabled. And enabling those are per serial interface, e.g. running AT+CLIP=1 on /dev/ttyUSB0 will not make +CPLIP: ... be printed on /dev/ttyUSB1.
So when you get them on windows the connection manager, it must be because it has those included in it init strings. Minicom I think defaults to no init string or possibly just a very classical one like ATS0=0 E1Q0V1.