[Stuart Kendrick <stuart.kendrick.sea@xxxxxxxxx>]

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?

I've found this neat diagram of the functions called as a frame wends its way toward hardware (Figure 4 in Section 2.3 in http://kernelnewbies.org/Networking?action="">)

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