1

I'm trying to figure out why my MacBook is unable to reach the web page served by my Raspberry Pi while other computers on my local network (or on external networks) have no problems seeing the web page. So I set up tcpdump on both the Mac and Pi and captured an attempt from both sides.

My first question is the following: (in two parts)

A) If an outgoing packet shows up in tcpdump, does that guarantee that the packet was actually transmitted? (i.e. can there be anything downstream of the tap point that could prevent the packet from being sent?)

B) If an expected incoming packet doesn't show up in tcpdump, does that guarantee that the packet was never received? (i.e. can there be anything upstream of the tap point that could discard a received packet before tcpdump sees it?)

These questions come from my observations of the tcpdump logs:

  1. The Mac sends a short packet to the Pi
  2. The Pi receives that packet and sends a short packet back to the Mac
  3. The Mac receives that packet and sends two packets to the Pi; the 2nd packet has the browser info etc.
  4. Neither of those packets is ever received by the Pi.

If both my assumptions A & B above are correct, then this means my router is for some reason treating packets for the Mac differently from, e.g., packets for my WinXP machine. (I'm assuming it must be at my router because, outside of there there's no way of knowing what machine on the internal network the packet belongs to and therefore no way to treat different machines differently.)

So if all of my assumptions are correct, any ideas on what's going wrong, or what I should look at next?

0

A) If an outgoing packet shows up in tcpdump, does that guarantee that the packet was actually transmitted? (i.e. can there be anything downstream of the tap point that could prevent the packet from being sent?)

This means that the packet flowed out of your network interface, but not much more than that. To know if a packet reached it's destination, you'd need to run tcpdump on the receiving side.

A firewall would be the likely culprit (either outgoing or incoming).

B) If an expected incoming packet doesn't show up in tcpdump, does that guarantee that the packet was never received? (i.e. can there be anything upstream of the tap point that could discard a received packet before tcpdump sees it?)

Yes, if tcpdump is watching the correct interface and you see no packet showing up that was confirmed as sent from the outside, then the packet was likely never sent.

default route

If the default routes aren't specified correctly then the packets wouldn't be able to get to the correct gateway network device, so that they could be delivered to a device on that particular subnet.

I would make sure that the default routes are set correctly for your Mac.

Example

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 wlp3s0
192.168.1.0     0.0.0.0         255.255.255.0   U     9      0        0 wlp3s0

NOTE: The above is from my Fedora 19 system, but your Mac should have something similar. Make sure the default route is set correctly for your network.

firewall

I would also make sure that there isn't a firewall getting in the way. On the Pi device you should be able to shutoff any iptables related service.

$ /etc/init.d/iptables stop

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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