Sorry previous message got cut off...
I've been busy trying to track down these ping issues and it appears to be a problem with the actual ping program supplied with open rather than a network problem.
I know get the following results from the mesh router
Generic:~# /usr/bin/ping -M do -s 1472 google.com PING google.com (74.125.39.105) 1472(1500) bytes of data. 72 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=1 ttl=53 (truncated) 72 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=2 ttl=53 (truncated)
Generic:~# /usr/bin/ping -M do -s 1473 google.com PING google.com (74.125.39.99) 1473(1501) bytes of data.
From 192.168.1.123 icmp_seq=1 Frag needed and DF set (mtu = 1500) From 192.168.1.123 icmp_seq=1 Frag needed and DF set (mtu = 1500)
So large pings appear to be going over the batman interface.
However still not getting any web traffic through
root@Generic:~# echo "HEAD / HTTP/1.1\nHost: git.open-mesh.net\n\n"|nc git.open-mesh.net 80
root@Generic:~# wget http://www.google.com Connecting to www.google.com (74.125.39.104:80)
What else can i provide to help track down the problem here :-(
Dave
On Tue, Aug 17, 2010 at 11:14 AM, David Beaumont djb31st@gmail.com wrote:
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