Malformed syn-ack
-
No switching issues or IP conflicts. I am able to get to the management UI of pfsense on that same nic. Which tells me TCP works on the RPI. UDP and ICMP work perfectly to destinations on the other side of the firewall.
This is the only node on this network aside from pfsense.
-
@KOM said in Malformed syn-ack:
TCP retransmissions are a symptom of the problem and not the cause. It could be cable, port, duplex mismatch...
Your capture shows the initial SYN from your server, and the top capture shows that it gets a SYN ACK back, but it doesn't reply with an ACK to finish the handshake (or at least not in the snippet you showed), so each end starts retransmitting. Do you have an IP address conflict, packet storm or switch loop going on? He's retransmitting his SYN ACKs, and you're replying with SYNs as if you're trying to start the handshake.
Those syn-acks are becoming rx_errors on the RPI which makes me think they are malformed packets.
-
Do a capture on pfSense LAN to see how those packets are leaving the interface to your Pi. Try and find where the breakdown happens.
-
@KOM I already did. :) The syn-ack makes it to the switchport that the RPI is connected to. The RPI doesn't like the packet for some reason. Something is wrong with it.
-
So the packets are fine out LAN, but are seen as bad after being processed by the Pi NIC...? The traces you showed don't show any bad packets but your NIC stats show receive errors.
-
I am beginning to wonder if it is the el'cheapo usb nic that I am using for the LAN interface. I've got a pcie nic arriving tonight.
The bottom line is this should work with all of the default settings out of the box right?
-
Yes.
-
It was that miserable USB nic. I put the new pcie nic in and as soon as I powered it back on I was online.
-
For what its worth it was a Sabernet 10/100 USB nic.
-
"Don't use USB NICs."
"Why?"
"Reasons."
-
Yes, if you would have mentioned that the NIC was USB we would have zeroed in on it immediately. I just assumed you were using the NIC on your Pi.