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 Fri, Aug 20, 2010 at 12:57 PM, David Beaumont <[email protected]> wrote: > 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 >>> >> >
