Network drop and firewall

[kupferstecher]

Hi,

I'd need some advice on how to setup a stable, fail safe TCP network connection. The client is a PLC and the server a Lazarus/freepascal program using the network library Synapse. By now the connection works fine, but it can get stuck when the network cable is unplugged while running. My first attempt was to do an automatic reconnect, when a timeout/error state is detected. As for the new connection this would work, but then I don't know whether or which data was lost in the meantime.

Storing and tracing the sent data seems redundant, so I thought it is probably better to rely on the mechanisms of TCP, that should try to resend dropped/corrupted IP packages. And I found out that this works when the windows firewall is disabled. Unplugging and replugging the network cable for like half a second even repeatedly will continue delivering all packets in both directions. I could make proper timeouts to cut of the connection, in case the data is not transfered in time. But once the firewall is enabled with rules to allow the traffic, a short unplugging of the cable will stop all traffic, the server doesn't receive any more data. In wireshark I can see the first incoming packet and some retransmission trials, while the programm doesn't receive it. The firewall logs don't show any blocked TCP packets. There are some UDP and ICMP packets that are blocked, but it doesn't seem related.

The network traffic is realtime data, so if the connection is down for several seconds I could give up and go into error state. But very short network drops should not lead to a reset.

How is it normally done?

What could be the reason, that the connection gets stuck only when the firewall is enabled?

The unplugging of the cable is just a simulation for a real live network problem, perhaps this is a wrong approach?

Thanks and Regards

[Thaddy]

Set up an exception rule in the (Windows?) firewall and application name and the port(s) you connect with. The traffic should then become unadultered/unaffected. This is usually enough.

Also more things I use for my Raspberry Pi's (Like remote camera's, live streams) may apply:
- Setup secure connections with (self signed) certificates and/or even create your own CA.
- My traffic then goes over https on the internet and the firewall will not complain.

Note for the latter to apply: I am on high speed - but still consumer grade -  fiber and connections over TCP are *very* stable in the Netherlands anyway. If your connections are not stable, I would use UDP but you will risk minor data loss at the client side, but without loosing any client integrity. This is usually not a problem for real-time streams.

But first a firewall rule...

[LeP]

The problem with sw firewalls is that they filter packets and "retransmit" them to the recipient, and this process is software and not part of the TCP/IP stack. Therefore, the stack's generic mechanisms (retransmission/error checking, etc.) work when they are direct, but not when they are managed by software.
When the cable is "unplugged" and "reconnected," all connection data (including temporary firewall ports) must be renegotiated, and therefore cannot guarantee the correctness of the negotiation that occurred before the disconnection.

However, when you use an application that uses a specific socket (without a software firewall), it maintains the socket's connection data (not the socket itself) regardless of the connection, so when communications resume, the stack can continue where it left off.

[Thaddy]

That will not happen with a firewall rule: its is pass-through, not resend as in reverse proxies.

[LeP]

That will not happen with a firewall rule: its is pass-through, not resend as in reverse proxies.

@Thaddy, that's not true. The mechanisms during a connection with an active firewall are designed to verify the network type.
Until the network type is identified, ALL PACKETS are discarded. This is part of the WFP (Windows Filtering Platform) specifications. Furthermore, WFP has other rules that actually alter the correct functioning of the TCP stack under these conditions in order to ensure security.

So, if the firewall software is active, it will discard everything until a complete reconnection, renegotiation, and identification of the network type.

[kupferstecher]

Thanks for the replies!

However, when you use an application that uses a specific socket (without a software firewall), it maintains the socket's connection data (not the socket itself) regardless of the connection, so when communications resume, the stack can continue where it left off.

@LeP: Can you elaborate on that a bit more? Did you talk about the case where there is no software firewall involved, or is it possible to define a socket that is not covered by the windows firewall?

Set up an exception rule in the (Windows?) firewall and application name and the port(s) you connect with. The traffic should then become unadultered/unaffected. This is usually enough.

Yes, I already have a rule in the windows firewall to allow all incoming and outgoing connections (so actually 2 rules) for that program. Otherwise not any communication would be possible. With enabled rules it still behaves different to a disabled firewall, as with disabled firewall unplugging and replugging the cable doesn't require a reconnect of the TCP connection, keeps receiving. I guess with enabled firewall (and rules) the firewall recognises the link-down and goes into an offline state that can only be left by an new connection.

[Thaddy]

That will not happen with a firewall rule: its is pass-through, not resend as in reverse proxies.

@Thaddy, that's not true.

You are probably right, but my complete approach works as suggested.

[LeP]

However, when you use an application that uses a specific socket (without a software firewall), it maintains the socket's connection data (not the socket itself) regardless of the connection, so when communications resume, the stack can continue where it left off.

@LeP: Can you elaborate on that a bit more? Did you talk about the case where there is no software firewall involved, or is it possible to define a socket that is not covered by the windows firewall?

You cannot bypass WFP (I mean windows firewall) without a kernel filter driver (and if you use this you cannot use the normal sockets of course, you need to use its apis or IOCTL).
You can only disable the firewall (at all) to use a "pure" socket not filtered by WFP.

I use some specific filter drivers for lot of TCP / UDP communications, but that for best performance only (and because I don't mind about protocols). Normal comms go with normal sockets.

[krolikbest]

I’m not sure if my answer is exactly on topic, but when it comes to physical network freezes/crashes I create on the TCP server side a 'heartbit' thread that pings the client and the client pongs back. In receving procedure (like RecevStr(timeout)) set some timeout so if LastError<>0 you catch an unusual situation. I'm actually developing something similar right now (Synapse TCP server and Arduino+WizNet W5500 as a client)

[kupferstecher]

You can only disable the firewall (at all) to use a "pure" socket not filtered by WFP.

OK, so I won't go that direction.

On server side now I just disconnect the client when the cable is unplugged and on client side I have a timeout for critical messages via TCP. If the reply of those messages is not received by the client within the timeout, then the connection is closed. If it is not stable enough in the long term, I'll reconsider auto reconnects and perhaps an own message queue to store the critical messages until receival is confirmed. But that all involves quite some effort.

[...] when it comes to physical network freezes/crashes I create on the TCP server side a 'heartbit' thread that pings the client and the client pongs back.

I do it the other way round. The client sends requests, that the server returns. But I guess it depends on the actual application, which way is more suitable.

In receving procedure (like RecevStr(timeout)) set some timeout so if LastError<>0 you catch an unusual situation.

The error catching gave me some headache, as well. I want to receive non-blocking so the "high-level" procedures from Synapse like RecvStr are not suitable. Instead I use the WaitingData function to query whether enough data is available and then read it with RecvBuffer. It took me quite some time to figure out how to detect a disconnected socket. I found when the connection is disconnected, then WaitingData returns 0 and CanRead returns true. If the connection is ok but no data, then WaitingData returns 0 and CanRead false. If there is data than WaitingData returns the number of bytes and CanRead true.

Code: Pascal  [Select][+][-]

1.   Function TFoo.ReadBlock: Integer;
2. var
3.   cnt: Integer;
4. begin
5.   Result:= 0;
6.  
7.   cnt:= fSocket.WaitingData;
8.  
9.   if cnt < 1 then begin
10.     if not fSocket.CanRead(0) then EXIT; //No data available
11.     cnt:= fSocket.WaitingData;
12.     if cnt = 0 then begin xAbort:= true; EXIT; end; //Connection dropped (CanRead is true)
13.   end;
14.  
15.   Result:= fSocket.RecvBuffer(@rxBuffer[0],cnt);