The plot thickens..
i started producing the tcp dumps that you requested to take a look at and noticed the following.
On the main internet node, if i ping google.com everything is fine. However if i ping -s 1464 google.com i do not get a reply, this isn't even going over the batman interface. So it looks like i have more of a local problem.
To clarify
ping -s 1464 google.com
results in ping requests being sent and recieved on ETH1, but not being returned to br-lan
ping google.com
results in ping requests being sent and recieved on ETH1, and being returned on br-lan
ping -s 84 google.com will work ping -s 85 google.com will not work.
I've never encountered these issues before, but i think they are the route cause of my problem? As was initially stated an MTU issue, i just need to find where!
echo "HEAD / HTTP/1.1\nHost: git.open-mesh.net\n\n"|nc git.open-mesh.net 80
from the mesh node brings no results, although works as expected on the internet node.
On Mon, Aug 16, 2010 at 7:32 PM, Sven Eckelmann sven.eckelmann@gmx.de wrote:
David Beaumont wrote:
Sorry for the late reply, a few things came up over the weekend that i had to attend to.
Here are three tcp dump files from the internet node on bat0 and one on eth1 (the internet port)
Really don't understand what is wrong here :-(
Ok, test plan:
* Find the machine and interface were a response from google.com could be received but which will not forward it to the other interface * take a real dump on all interfaces (wan and lan) tcpdump -s 0 -i eth1 -w eth1.dump * when the response packet is forwarded over the lan/bat0 interface but doesn't get to the final machine than please also create a tcpdump on the receiving machine (real interface and maybe bat0) * Go to your router and check mtu of your wan interface * Try to ping google.com with the maximum size (mtu - 28 bytes, for example mtu 1492): ping -M do -s 1464 google.com * Send small tcp packet with small tcp response: echo "HEAD / HTTP/1.1\nHost: git.open-mesh.net\n\n"|nc git.open-mesh.net 80
Best regards, Sven