Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a TCP server listening on, port 2000, running on a Windows 7 machine. Below is the corresponding output line for the command netstat -aon:


I also have an FPGA which sends a TCP SYN packet every second until the server responds.

The FPGA physically connects to the directly to a network interface on the Windows 7 machine, which has been configured to have a static IP address of The source IP address of the SYN packets is

I can see the SYN packets being received on the network interface using WireShark, but the TCP server does not reply a SYN/ACK. My assumption is that the TCP server is not seeing the SYN packets because of routing issues.

I have manually added two routes as follows (IF 16 refers to the interface with static IP

route add MASK METRIC I IF 16

route add MASK METRIC I IF 16

Have I correctly added the routes? How can I confirm that the TCP server is indeed not being forwarded the IP packets with the TCP SYN? What can I do to gain more insight into what is going wrong?

share|improve this question
Surely if Wireshark is seeing the packets it's not a routing issue? Are you sure your TCP server is bound to that port / interface correctly? What happens if you try sending from another machine on the network? – Jon Cage Jul 2 '13 at 12:39
@JonCage: My TCP server is correctly bound as confirmed by the netstat command (see updated question). Also, when using a different network interface (with a different IP address), the TCP server works as expected, even from another machine on the network. – Randomblue Jul 2 '13 at 12:44
it seems weird to send syn's repeatedly, and syn flooding is a common DOS vector. do you think its possible that a device in the middle is dropping the packets to prevent a DOS attack? – Frank Thomas Jul 2 '13 at 12:50
@FrankThomas: The FPGA is directly connected to the machine hosting the TCP server. There is no device in the middle. Also, WireShark is seeing all the SYNs. – Randomblue Jul 2 '13 at 12:52
Could windows firewall be dropping the packets after wireshark sees them? Seems odd that would work from another machine if you're able to successfully send the same information from another machine(?) mind you... – Jon Cage Jul 2 '13 at 12:59
up vote 2 down vote accepted

My bet is the server has no ARP entry for the IP address the SYN is coming from, so it has no way to put a reply packet on the Ethernet wire because it doesn't know what Ethernet hardware address to send the reply to.

share|improve this answer
You got it right, congratulations! Adding a new entry in the ARP table fixed it! Cheers. – Randomblue Jul 2 '13 at 19:34

Based on what you've said in your post, my money would be that the server you're running is bound to the wrong interface.

If you have the option, try disabling the interface you've tested that works from other machines and then re-start your server software.

If you can't disable or disconnect the other interface because you're using that to remote desktop into the server machine, how about plugging the FPGA into that interface and your remote desktop connection into the interface the FPGA is currently connected to?

If you're able to modify the server software I'd suggest checking what interface(s) it's being bound to - I've had issues along those lines before when using windows network bindings (sending / receiving UDP broadcasts on the wrong interface)..

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.