gaurav-narula commented on PR #22971:
URL: https://github.com/apache/kafka/pull/22971#issuecomment-5399253111
> > SslSelectorTest/SelectorTest have test methods which attempt to bind a
socket on all interfaces. This is excessive and interferes on dev machines with
full tunnel VPNs.
>
> Our integration tests also attempt to bind a socket on all interfaces. Do
they cause the same issue for you? If not, could you share more details on why
only these two tests are affected?
Sorry, I should've clarified more. These tests stall for me at
`ss.accept()`. I performed a TCP dump with the VPN and observed multiple SYNs
from the client as follows:
```
route get 0.0.0.0
route to: default
destination: default
mask: default
interface: utun24
flags: <UP,DONE,CLONING,STATIC,GLOBAL>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu
expire
0 0 0 0 0 0 1390 0
```
```
$ sudo tcpdump -i utun24 -n port 50733
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on utun24, link-type RAW (Raw IP), snapshot length 524288 bytes
18:39:53.274860 IP <vpn-ip-client>.50739 > <vpn-ip-server>.50733: Flags
[SEW], seq 1025114755, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
273795359 ecr 0,sackOK,eol], length 0
18:39:53.274870 IP <vpn-ip-client>.50740 > <vpn-ip-server>.50733: Flags
[SEW], seq 1031755007, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
3658847604 ecr 0,sackOK,eol], length 0
18:39:54.274739 IP <vpn-ip-client>.50740 > <vpn-ip-server>.50733: Flags [S],
seq 1031755007, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
3658848604 ecr 0,sackOK,eol], length 0
18:39:54.274753 IP <vpn-ip-client>.50739 > <vpn-ip-server>.50733: Flags [S],
seq 1025114755, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
273796359 ecr 0,sackOK,eol], length 0
18:39:55.274714 IP <vpn-ip-client>.50740 > <vpn-ip-server>.50733: Flags [S],
seq 1031755007, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
3658849604 ecr 0,sackOK,eol], length 0
18:39:55.274728 IP <vpn-ip-client>.50739 > <vpn-ip-server>.50733: Flags [S],
seq 1025114755, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
273797359 ecr 0,sackOK,eol], length 0
18:39:56.274657 IP <vpn-ip-client>.50740 > <vpn-ip-server>.50733: Flags [S],
seq 1031755007, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
3658850604 ecr 0,sackOK,eol], length 0
18:39:56.274661 IP <vpn-ip-client>.50739 > <vpn-ip-server>.50733: Flags [S],
seq 1025114755, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
273798359 ecr 0,sackOK,eol], length 0
18:39:57.274702 IP <vpn-ip-client>.50740 > <vpn-ip-server>.50733: Flags [S],
seq 1031755007, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
3658851604 ecr 0,sackOK,eol], length 0
18:39:57.274719 IP <vpn-ip-client>.50739 > <vpn-ip-server>.50733: Flags [S],
seq 1025114755, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
273799359 ecr 0,sackOK,eol], length 0
18:39:58.275334 IP <vpn-ip-client>.50740 > <vpn-ip-server>.50733: Flags [S],
seq 1031755007, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
3658852605 ecr 0,sackOK,eol], length 0
18:39:58.275350 IP <vpn-ip-client>.50739 > <vpn-ip-server>.50733: Flags [S],
seq 1025114755, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
273800360 ecr 0,sackOK,eol], length 0
18:40:00.275815 IP <vpn-ip-client>.50740 > <vpn-ip-server>.50733: Flags [S],
seq 1031755007, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
3658854605 ecr 0,sackOK,eol], length 0
18:40:00.275826 IP <vpn-ip-client>.50739 > <vpn-ip-server>.50733: Flags [S],
seq 1025114755, win 65535, options [mss 1350,nop,wscale 6,nop,nop,TS val
273802360 ecr 0,sackOK,eol], length 0
```
That shows the client is sending multiple SYNs and the SYN-ACK from the
server is getting dropped by the VPN's utun interface.
As to why this doesn't happen for the integration tests, I think it's
because the client's deliberately connect to localhost as the tests advertise
that in their listener
https://github.com/apache/kafka/blob/61e0b5b04f5195c5721a1bc0fe116979a19c7586/test-common/test-common-runtime/src/main/java/org/apache/kafka/common/test/KafkaClusterTestKit.java#L397.
In my case, the VPN's routing table doesn't interfere with `127.0.0.1`.
An equivalent fix would've been to modify the IP that the client connects to
in these tests to be 127.0.0.1 by doing something like:
```diff
- InetSocketAddress serverAddress = (InetSocketAddress) ss.getLocalAddress();
+ InetSocketAddress serverAddress = new InetSocketAddress("localhost",
((InetSocketAddress) ss.getLocalAddress()).getPort());
```
but I figured binding on loopback is cleaner and results in the same
behaviour.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
