Here's how I measured this, with netcat:
On my Unix host (Mac OS X Darwin), no firewall (or on a Windows machine where the Windows firewall allows the netcat "nc" executable to listen on UDP ports), I run a UDP server with variable delay supplied by remote clients:
WINHOST=10.116.140.69
mkfifo f
nc -u -p 2222 $WINHOST 6666 < f | \
(while read secs; do for sec in $secs; do echo sleep $sec 1>&2; sleep $sec; echo SLEPT $sec; echo SLEPT $sec 1>&2; done; done) > f
On my Windows host (Windows 7 Professional SP1 64-bit), Windows Firewall, with cygwin installed to provide shell and netcat, I run a UDP client interactively:
UNIXHOST=192.168.181.1
nc -u -p 6666 $UNIXHOST 2222
You don't have to use cygwin; a Windows netcat should work fine, but the command lines may vary.
Then into that client I type a series of test intervals, observe the server sleeping then responding, observe whether the client gets the response. These worked: 1, 2, 10, 60, 120, 180. Then this failed: 240. Proceed with a binary search between 180 and 240.
Example 1: On the client side, I type:
10
60
120
180
240
and observe that request-response delay of up to 180 works, 240 doesn't.
Example 2: On the client side, I type:
180
181
182
182
and observe that request-response delay of up to 181 works, 182 doesn't.
Example 3: On the client side, I type (all on the same line):
180 180 180 181 181 181 182 182 182 183 183 183
which generates one UDP request from client, then a series of responses separated by 180, 181, 182, or 183 second intervals. It was observed that request-response delay of up to 181 worked, and in addition, continued responses (without new requests) at intervals up to 181 seconds worked also.
So the firewall hole has an inactivity timer, without regard to whether the inactivity is delay in initial response, or in subsequent additional traffic.
Results on multiple machines:
- On that Windows 7 Professional SP1 64-bit desktop, the UDP response hole is open for 181 seconds. It's possible that I'm also measuring a network firewall between the two systems, since they are on separate networks -- but I think they are routed not firewalled. In any event, the Windows firewall hole is at least 181 seconds on this system.
- Another Windows 7 Professional SP1 64-bit laptop, same network segment (so definitely no intervening firewall), the UDP response hole is open for 64 seconds.
I'd be interested in seeing similar measurements on other Windows machines at various OS levels and firewall configurations.
