Validating WIFI subnet

DRoscoe

I have written an app for iOS which connects to a remote host at a static IP address which is configured in the settings bundle. The problem is that I want to know if the currently connected WIFI is on the same subnet as the configured IP, or if the remote host is up and running. If I reflexively try to make a connection to my remote app, and the WIFI is connected to a different subnet or the host is down, it takes a long time for the connection attempt to time out. Ideally, I would like to detect this situation before attempting a connection, so I can inform the user to change their WIFI configuration.

I could check my current IP address from the WIFI connection against the IP address in the settings bundle, but that would not address situation of being on the correct subnet, but the remote host is down. Something like a ping would work in both cases, but I am not sure I can do this programmatically. Is there a way for me to "ping" or something analogous from within my app?

Thanks!

? Offline

Hi! I guess you're using a TCP socket. So you can make a connection attempt using a timeout shorter than the default; bool QAbstractSocket::waitForConnected(int msecs = 30000).

DRoscoe

@Wieland I am using signals/slots. I'm not waiting for a connection, but rather the signal from the socket when the connection is made (or fails)

kshegunov

@DRoscoe said in Validating WIFI subnet:

I am using signals/slots. I'm not waiting for a connection, but rather the signal from the socket when the connection is made (or fails)

It doesn't matter, you can use a QTimer to signify timeout. E.g:

QTcpSocket * socket;
MySocketHandler * handler;

QTimer * timer = new QTimer(handler);
timer->setSingleShot(true);
timer->start(1000);
socket->connectToHost( ... );

QObject::connect(socket, &QTcpSocket::connected, handler, &MySocketHandler::connected);
QObject::connect(socket, &QTcpSocket::error, handler, &MySocketHandler::timeout);

QObject::connect(socket, &QTcpSocket::connected, timer, &QTimer::deleteLater);

QObject::connect(timer, &QTimer::timeout, handler, &MySocketHandler::timeout);
QObject::connect(timer, &QTimer::timeout, timer, &QTimer::deleteLater);

DRoscoe

@kshegunov Thanks for this solution. It's not ideal because I am trying to accomplish two things:

Determine if the remote host device is up and able to communicate
Determine if a connection can be made to the service running on the remote host

Failure to make a connection could be due to the host device being unable to respond, either due to incorrect TCP/IP configuration of the iPad or the remote host hardware being down, or the daemon service running on the remote host not running/responding. I want to know both of these things so I can give the user more information about why the system is not running. In the former case, they can remedy it by fixing their iPad configuration. In the latter, its a more systemic issue that will need to be handled by the aircraft maintenance crew (the system is deployed in an aircraft cockpit).

raven-worx

@DRoscoe said in Validating WIFI subnet:

Determine if the remote host device is up and able to communicate

how would you define this condition?
Ping is enough?

Determine if a connection can be made to the service running on the remote host

how can this be checked other than connecting to it?

Failure to make a connection could be due to the host device being unable to respond, either due to incorrect TCP/IP configuration of the iPad or the remote host hardware being down, or the daemon service running on the remote host not running/responding. I want to know both of these things so I can give the user more information about why the system is not running. In the former case, they can remedy it by fixing their iPad configuration. In the latter, its a more systemic issue that will need to be handled by the aircraft maintenance crew (the system is deployed in an aircraft cockpit).

for this you can actually listen to the returned error code and assemble your message from it.
You won't always get the exact cause of the error. For example a blocked port (yb the firewall) might result in the same error like there is no application listening on the port.

DRoscoe

@raven-worx something like a ping to the remote host would be what I am looking for. If that test passes, then a failure in connecting to the daemon running on the remote host can only be something external to the iPad app, which cannot be remedied by the crew in the cockpit.

DRoscoe

We found a way around the problem. Turns out we can use a variation of @kshegunov 's approach and judicious use of error codes returned from Qt.