0

I was redirected from Network Engineering, hopefully below is in scope of on-topics.

I have a TCP server, its properties are the following:

  • It runs within a virtual machine (VMware).
  • The host OS is Windows 10.
  • The guest OS is Debian 9.
  • The TCP server listens on a port on the IP of 169.254.1.1.
  • In VMware, I bridged the Ethernet adapter of the host with the network adapter of the guest OS. I did this, because as far as I know, link-local addresses do not traverse NAT. So, I think my only option is to bridge the network devices.
  • In Windows, I set static IP for the Ethernet adapter, 169.254.1.20/16. The reason behind is that I wanted to have an exact IP address for this device, because there is no DHCP server present in the network. I was afraid that it would have got an arbitrary link-local address due to the failure of the DHCP request.
  • In the guest OS (Debian), I set 169.254.1.1/16 as IP for the ens33 device.
  • I let incoming connections through the firewall of the host OS.
  • I issued iptables --flush on the guest OS to temporarily accept all incoming connections.
  • Wireshark runs as administrator on the host OS.

I have a TCP client, its properties are the following:

  • It runs under a Debian 9 (native, not virtual machine).
  • Static IP is set, 169.254.1.2/16.
  • It tries to connect to a port on 169.254.1.1.
  • I issued iptables --flush.

The server and the client was connected by means of an Ethernet cable.

With above settings the behaviour is the following. The client sends an ARP request to the server, the server answers the ARP request by sending the MAC address of the network device of the guest OS (MAC address of ens33). Then I was checking the output of Wireshark, but I have not seen any incoming TCP SYN packets. I started to debug the client and I observed that connect function sets errno global variable to EINPROGRESS and the mentioned function returns -1 after each call. I set errno to zero before each call.

Then I repeated almost the same test with a slight change, I restored configuration of iptables on the client in order to count the packages in the OUTPUT chain. The behavior was the same, TCP SYN was not sent at all, but the counter was increasing which marked the NEW TCP connections towards the destination port. According to this, I assume the kernel wishes to initiate a TCP handshake, but after a certain point "it changes its mind" and packets with TCP SYNs are not created.

What should I do to make the client establish connection with the server? At which step did I make a mistake? Did I miss something?

Update

I checked the ARP table of the client by running arp command. The output of the command contains the MAC address of ens33 interface of the guest OS of the server and this ARP entry is associated with 169.254.1.1.

I cannot change the IP of the server due to constraints.

7
  • 1
    Does the client create an actual arp entry or a route for 169.254? The 169.254/16 prefix SHOULD NOT be configured manually (RFC 3927), there are mechanisms to auto-configure it, including adding the required on-link routes. Is there a reason to use it over a private address space like 172.16.0.0/16?
    – Cpt.Whale
    Commented May 21 at 21:54
  • You might also try capturing from either of the debian machines instead - wireshark can be awkward about capturing on a bridged interface, especially for traffic not addressed to the host
    – Cpt.Whale
    Commented May 21 at 21:57
  • Thank you for your comment! I added the missing information to the post. Regarding your second comment, do you suggest to try eg. tcpdump instead of Wireshark? Or do you suggest another tool for this purpose?
    – user94749
    Commented May 21 at 22:53
  • Please add the output of iptables-save (from the client). Btw, I assume you do see the ARP reply from the server (VM) in the wireshark capture?
    – Tom Yan
    Commented May 22 at 4:01
  • The IPv4LL subnet is not supposed to be manually configured. Use any RFC 1918 private subnet instead. If you DO have to manually configure something on that subnet, use 0 or 255 in the third octet, because those values are reserved and shouldn't conflict with self-assigned addresses, which use 1-254 in the third octet.
    – Spiff
    Commented May 22 at 4:32

0

You must log in to answer this question.

Browse other questions tagged .