I'm using a ESP8266 with micropython. For script downloading I use webrepl. I would like to monitor the webrepl connections and want to stop the programm execution if there is a webrepl connection established. And after the connection is closed I would like to reset the ESP8266 by machine.reset()
The problem is, I use some micropython IRQs and a parallel webrepl connection and filetransfer eventually causes filesystem crashes.
My question: How do I read the webrepl connections and how may I evaluate them?
Thanks
I found the answer: According to https://github.com/micropython/micropython/blob/master/esp8266/modules/webrepl.py the webrepl.client_s variable needs to be checked. The variable can be read from outside of webrepl as soons as you have imported webrepl module.
Some difficulty: In the current implementation the client_s will keep a closed client socket connection for infinity
Thanks
It looks like you can simply call uos.dupterm() to find out if the webrepl is connected.
For Example:
if (uos.dupterm()):
print("webrepl is connected")
else:
print("webrepl is not connected")
Related
Is there a way to distinguish between a lost connection and an expected timeout on reading from a serial port (/dev/tty... file descriptor) in golang 1.16 on a linux host?
All I get from two different implementations of "serial" for go are a error string holding only "EOF" in both scenarios. I tried os.IsTimeout() but there is no type associated with that error from io.file.
I need to know if I lost connection so I can reconnect (close and reopen the port). Without it is reconnecting on every timeout.
Can someone hint me to a way to distinguish these to scenarios or a different approach for handling a disconnected device?
Our software (Nmap port scanner) needs to quickly determine the status of a non-blocking TCP socket connect(). We use select() to monitor a lot of sockets, and Windows is good at notifying us when one succeeds. But if the port is closed and the target sends a TCP RST, Windows will keep trying a few times before notifying the exceptfds, and the socket error is WSAECONNREFUSED as expected. Our application has its own timeout, though, and will usually mark the connection as timed-out before Windows gives up. We want to get as close as possible to the behavior of Linux, which is to notify with ECONNREFUSED immediately upon receipt of the first RST.
We have tried using the TCP_MAXRT socket option, and this works to get select() to signal us right away, but the result (for closed ports) is always WSAETIMEDOUT, which makes it impossible to distinguish closed (RST) from filtered/firewalled (network timeout), which puts us back at the original problem. Determining this distinction is a core feature of our application.
So what is the best way on Windows to find out if a non-blocking socket connect() has received a connection reset?
EDITED TO ADD: A core problem here is this line from Microsoft's documentation on the SO_ERROR socket option: "This per-socket error code is not always immediately set." If it were immediately set, we could check for it prior to the connect timeout.
In Windows 7 I'm trying to set up a PPP connection over a direct serial port connection to a remote device. The documentation of the remote device (as well as the documentation I've found for the Windows PPP) indicates that the process should start with a Link Control Protocol packet, but I've discovered (by sniffing the serial line) that the PC, before doing anything else, is transmitting the string "CLIENT" once per second for up to 5 seconds. Only if the PC receives the response "SERVER" will it continue with the LCP initialization.
Does anyone know what level of system functionality is sending this CLIENT string, and how I can disable it. My remote device does not recognize this and refuses to connect based on this.
Update: I have discovered that this string is being initiated by the modem driver mdmhayes.inf as a "DialPrefix", but I have no idea how to update this driver file to eliminate this dial prefix. Thoughts?
Update: I've figured out how to get Windows to stop spitting out the "CLIENT" string (it has to do with changing the DIALPREFIX setting in the mdmhayes.inf file) but I still can't figure out how to make Windows realize it is connected and just move on with establishing the PPP connection. The modem diagnostics keep indicating that unknown strings are received so it doesn't know how to proceed. There should be some setting in the mdmhayes.inf file that tells the system not to wait for anything; it's connected to a wire and that's all that is needed. I just can't figure out what setting to use to make the modem initialization get out of the way to allow the PPP stack to take over.
in options.ttyS0 add:
debug
#19200
115200
192.168.111.1:192.168.111.2
netmask 255.255.255.0
lock
auth
nodefaultroute
nocrtscts
connect /etc/ppp/msclient.sh
msclient.sh :
#!/bin/sh
read -n 5 i
echo "SERVER"
I am working on an FTP client for kicks and I am trying to understand the workflow of data connections.
As I understand, the initial (command) connection is permanent until you quit. However, I am unsure of the data connection - is it re-initiated per-command? So you call PORT ... or PASV, get a second connection, do a LIST, get the results, connection closes, start over?
Also, do you need to call PASV (or PORT ...) again after each connection closes? It seems that when I try to test some things out using a passive connection, I cannot re-connect to the same port after the first command has returned the results and closed the data connection. I can keep calling PASV -> Data Connect -> Run Command -> Get Results -> Data Connection closed -> PASV, but it seems like it's not how it's meant to run?
Also, if someone has a good material on FTP that is more terse than the RFC I really appreciate it.
You have to open a new connection every time. It's only the closing of the connection, how you (or the server) can tell that the transfer completed (at least in the common "stream mode").
You cannot even reuse the local/remote port number combination, as when a TCP connection is closed, it enters TIME_WAIT mode and the port number combination cannot be used for some time. So for two immediately consecutive transfers you have to use a different port number combination anyway.
Refer to RFC 959, section 3.3. Data management:
Reuse of the Data Connection: When using the stream mode of data
transfer the end of the file must be indicated by closing the
connection. This causes a problem if multiple files are to be
transfered in the session, due to need for TCP to hold the
connection record for a time out period to guarantee the reliable
communication. Thus the connection can not be reopened at once.
There are two solutions to this problem. The first is to
negotiate a non-default port. The second is to use another
transfer mode.
A comment on transfer modes. The stream transfer mode is
inherently unreliable, since one can not determine if the
connection closed prematurely or not. The other transfer modes
(Block, Compressed) do not close the connection to indicate the
end of file. They have enough FTP encoding that the data
connection can be parsed to determine the end of the file.
Thus using these modes one can leave the data connection open
for multiple file transfers.
See also:
Why does FTP passive mode require a port range as opposed to only one port?
How many data channel ports do I need for an FTPS server running behind NAT?
I am using boost asio for my TCP Server, in this I am using async_read_some for reading .
Application is working fine when network is connected, normal connection closing are handled correctly like (EOF,abrupt closing).
But my problem is I am not getting any error when network cable is unplugged. socket is open , and I get error when I am writing on socket. This is the way socket work.
Question: Can this is handled in Boost asio by any method?
You may want to set "keep alive" on the socket, see Socket closed notification. Try:
socket.set_option(boost::asio::socket_base::keep_alive(true));