I want to better understand the path a frame takes as it approaches the Ethernet NIC
I have a problem in which a client is unable to NFS-mount a server
On the wire (SPAN port off the local Ethernet switch), I can see the DNS look-up, the ARP exchange ... and then silence. Capturing on the client itself, I can see the DNS look-up, the ARP exchange, and then a TCP SYN to port 2049 (repeated TCP SYNs across many minutes ... the NFS client is patient)
ftp, sftp, and http from the client to the server works fine, and I can see the TCP SYN (plus the ensuing TCP stream) in both packet traces
OK, so something is dropping the outbound TCP SYN after sending a copy to libpcap and before sending it to the NIC driver. [Sounds like a job for IPTABLES ... but I installed this client, and I've never configured an iptables rule ... just for grins, I uninstalled both the ufw and the iptables packages ... or a job for libwrap .. but /etc/hosts.allow and /etc/hosts.deny are vanilla ... no mention of rpcbind]
What is capable of doing that?
ending in rtl8169_start_xmit()
From the text, I'm guessing that various 'hooks' can dink with the frame: NF_IP_PRE_ROUTING, NF_IP_LOCAL_IN, NF_IP_POST_ROUTING
nowhere in there do I see where libpcap gets its copy ... nor do I see where iptables might insert its paws ...
I haven't gone to source yet (I'm skeptical that I'm smart enough) ..
==> What functions can mess with a frame as it approaches hardware? Obviously, libpcap can register a request for a copy ... what functions can discard the frame after libpcap gets its copy?
[In many ways, I'm pursuing a thread on AskWireshark.org around who sends libpcap frames
http://ask.wireshark.org/questions/22956/where-exactly-wireshark-does-captures-packets]
--sk
