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 r...@generic:~# echo "HEAD / HTTP/1.1\nHost: git.open-mesh.net\n\n"|nc git.open-mesh.net 80 r...@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 <[email protected]> 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 <[email protected]> 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 >> >
