* [B.A.T.M.A.N.] Nat Question [not found] ` <AANLkTim-RfupM1iHH-dFwtDiN5RLFVaP=AWK9=MH-dGK@mail.gmail.com> @ 2010-08-11 11:48 ` David Beaumont [not found] ` <AANLkTinhcpamuMGApH9D5SPn3VNkEi9BDCYwGkRcDdJq@mail.gmail.com> 2010-08-12 9:31 ` Marek Lindner 0 siblings, 2 replies; 27+ messages in thread From: David Beaumont @ 2010-08-11 11:48 UTC (permalink / raw) To: b.a.t.m.a.n I have a B.A.T.M.A.N mesh successfully configured on x86 hardware. I can currently ping the internet from the router that is connected via the mesh, however i can't download or connect to any webpages. I see the request for the page going over the bat0 interface and being received at the other end. I've a feeling this is a basic nat problem, but have been unable to find a solution. I am using OpenWRT software. Any advice? or hints? Thanks ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <AANLkTinhcpamuMGApH9D5SPn3VNkEi9BDCYwGkRcDdJq@mail.gmail.com>]
* Re: [B.A.T.M.A.N.] Nat Question [not found] ` <AANLkTinhcpamuMGApH9D5SPn3VNkEi9BDCYwGkRcDdJq@mail.gmail.com> @ 2010-08-11 12:50 ` David Beaumont 0 siblings, 0 replies; 27+ messages in thread From: David Beaumont @ 2010-08-11 12:50 UTC (permalink / raw) To: b.a.t.m.a.n Hmm i was hoping it would be that simple.. but alas it wasn't. Here is the output from tcpdump on the bat0 interface tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bat0, link-type EN10MB (Ethernet), capture size 96 bytes 14:19:43.356750 IP 192.168.1.189.52560 > fx-in-f99.1e100.net.80: SWE 4246115553: 4246115553(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4> 14:19:43.464324 IP fx-in-f99.1e100.net.80 > 192.168.1.189.52560: S 1693892836:16 93892836(0) ack 4246115554 win 5720 <mss 1430,nop,nop,sackOK,nop,wscale 6> 14:19:43.467474 IP 192.168.1.189.52560 > fx-in-f99.1e100.net.80: . ack 1 win 365 14:19:43.467776 IP 192.168.1.189.52560 > fx-in-f99.1e100.net.80: P 1:78(77) ack 1 win 365 14:19:45.737534 IP 192.168.1.189.58552 > fx-in-f147.1e100.net.80: P 3961995538:3 961995615(77) ack 1025796129 win 365 14:19:46.467535 IP 192.168.1.189.52560 > fx-in-f99.1e100.net.80: P 1:78(77) ack 1 win 365 and my network interfaces are configured as follows ath0 Link encap:Ethernet HWaddr 00:0C:42:3A:75:A2 inet addr:100.10.17.3 Bcast:100.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1524 Metric:1 RX packets:894 errors:0 dropped:68 overruns:0 frame:0 TX packets:362 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:55386 (54.0 KiB) TX bytes:20256 (19.7 KiB) bat0 Link encap:Ethernet HWaddr 00:FF:D0:24:1D:30 inet addr:10.0.1.1 Bcast:10.0.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:52 errors:0 dropped:0 overruns:0 frame:0 TX packets:35 errors:0 dropped:1 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5461 (5.3 KiB) TX bytes:3942 (3.8 KiB) br-lan Link encap:Ethernet HWaddr 00:0D:B9:19:0E:98 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:52 errors:0 dropped:0 overruns:0 frame:0 TX packets:36 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4733 (4.6 KiB) TX bytes:4344 (4.2 KiB) Can still ping, and also resolve DNS but no traffic on TCP or UDP will send On Wed, Aug 11, 2010 at 3:28 PM, Outback Dingo <outbackdingo@gmail.com> wrote: > or its a basic MTU problem, might want to try searching google for openwrt > batman MTU issues > > On Wed, Aug 11, 2010 at 7:48 AM, David Beaumont <djb31st@gmail.com> wrote: >> >> I have a B.A.T.M.A.N mesh successfully configured on x86 hardware. >> >> I can currently ping the internet from the router that is connected >> via the mesh, however i can't download or connect to any webpages. >> >> I see the request for the page going over the bat0 interface and being >> received at the other end. >> >> I've a feeling this is a basic nat problem, but have been unable to >> find a solution. >> >> I am using OpenWRT software. >> >> Any advice? or hints? >> >> Thanks > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-11 11:48 ` [B.A.T.M.A.N.] Nat Question David Beaumont [not found] ` <AANLkTinhcpamuMGApH9D5SPn3VNkEi9BDCYwGkRcDdJq@mail.gmail.com> @ 2010-08-12 9:31 ` Marek Lindner 2010-08-12 9:38 ` David Beaumont 1 sibling, 1 reply; 27+ messages in thread From: Marek Lindner @ 2010-08-12 9:31 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking Hi, > I see the request for the page going over the bat0 interface and being > received at the other end. > > I've a feeling this is a basic nat problem, but have been unable to > find a solution. how is the routing (especially bat0) configured on the node that is connected to the internet ? Are you bridging bat0 or doing something else ? Regards, Marek ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 9:31 ` Marek Lindner @ 2010-08-12 9:38 ` David Beaumont 2010-08-12 9:50 ` Sven Eckelmann 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-12 9:38 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking The bat0 interface is currently bridged as follows On the router with internet going into the WAN port (ETH1), BAT0 is bridged with the LAN (ETH0) Internet works correctly though the lan, so i would assume NAT routing to the WAN is setup correctly? On the router on the other end of the mesh, BAT0 is bridged with the WAN port (ETH1) so that the router will route WAN traffic though BAT0? Have i got some of the basics confused somewhere? I had BATMAN (not advanced) working fine, although was experiencing i think a known problem with openwrt, whereas when traffic was sent over the TUN interface for the captive portal the gate0 interface would collapse. Lets stay on topic with batman advanced for now though i guess :-) On Thu, Aug 12, 2010 at 12:31 PM, Marek Lindner <lindner_marek@yahoo.de> wrote: > > Hi, > > > I see the request for the page going over the bat0 interface and being > > received at the other end. > > > > I've a feeling this is a basic nat problem, but have been unable to > > find a solution. > > how is the routing (especially bat0) configured on the node that is connected > to the internet ? Are you bridging bat0 or doing something else ? > > > Regards, > Marek ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 9:38 ` David Beaumont @ 2010-08-12 9:50 ` Sven Eckelmann 2010-08-12 10:11 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: Sven Eckelmann @ 2010-08-12 9:50 UTC (permalink / raw) To: b.a.t.m.a.n; +Cc: David Beaumont [-- Attachment #1: Type: Text/Plain, Size: 811 bytes --] David Beaumont wrote: > The bat0 interface is currently bridged as follows > > On the router with internet going into the WAN port (ETH1), BAT0 is > bridged with the LAN (ETH0) Internet works correctly though the lan, > so i would assume NAT routing to the WAN is setup correctly? so you have eth0 and bat0(ath0) in a bridge br0 -> eth1 uses nat to translate packets for/from eth1? > On the router on the other end of the mesh, BAT0 is bridged with the > WAN port (ETH1) so that the router will route WAN traffic though BAT0? What? Why a different internet gateway and why do you bridge the bat0(ath0) interface with the wan interface instead of using nat here? Maybe there is a misunderstanding somewhere... At least I am extremely confused about your setup. Best regards, Sven [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 9:50 ` Sven Eckelmann @ 2010-08-12 10:11 ` David Beaumont 2010-08-12 10:16 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-12 10:11 UTC (permalink / raw) To: b.a.t.m.a.n > > The bat0 interface is currently bridged as follows > > > > On the router with internet going into the WAN port (ETH1), BAT0 is > > bridged with the LAN (ETH0) Internet works correctly though the lan, > > so i would assume NAT routing to the WAN is setup correctly? > > so you have eth0 and bat0(ath0) in a bridge br0 -> eth1 uses nat to translate > packets for/from eth1? Yes this is correct, bat0 and eth0 are bridged to form br-lan, which uses nat to translate things over to eth1 > > > On the router on the other end of the mesh, BAT0 is bridged with the > > WAN port (ETH1) so that the router will route WAN traffic though BAT0? > > What? Why a different internet gateway and why do you bridge the bat0(ath0) > interface with the wan interface instead of using nat here? > Not sure what you mean by a "a different internet gateway" The way openWRT is setup, the WAN network is actually a bridge of bat0 and wifi0 (which is the card that bat0 is running on) Talking this though its looking like this might be the bit where the problem lies. Its setup currently like this as i was initially trying to run OLSR and BATMAN simultaneously (although have since simplified to just batman). My theory was that if bat0 is the WAN, the NAT rules built into openwrt would take control and internet would be routed though bat0. I have also attempted to setup nat myself at this end, but am so far unsuccessful and loose the ability to even ping the internet. I think i am close to the solution as i can ping things, there is just something missing. Will try un-bridging wifi0 and report on what happens. > Maybe there is a misunderstanding somewhere... At least I am extremely > confused about your setup. > > Best regards, > Sven ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 10:11 ` David Beaumont @ 2010-08-12 10:16 ` David Beaumont 2010-08-12 10:33 ` Marek Lindner 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-12 10:16 UTC (permalink / raw) To: b.a.t.m.a.n No luck :-( root@Generic:/# cat /proc/net/batman-adv/originators Originator (#/255) Nexthop [outgoingIF]: Potential nexthops .. . [B.A.T.M.A.N. Adv 0.1 rv1176, MainIF/MAC: ath0/00:0c:42:60:12:cf] 00:0c:42:3a:75:a2 (229) 00:0c:42:3a:75:a2 [ ath0]: 00:0c:42:3a:75:a2 (229) root@Generic:/# ping google.com PING google.com (74.125.39.105): 56 data bytes 64 bytes from 74.125.39.105: seq=0 ttl=53 time=124.425 ms ^C --- google.com ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 124.425/124.425/124.425 ms root@Generic:/# wget http://www.google.com Connecting to www.google.com (209.85.135.147:80) Pings work fine, a wget just pauses and waits indefinitely On Thu, Aug 12, 2010 at 1:11 PM, David Beaumont <djb31st@gmail.com> wrote: >> > The bat0 interface is currently bridged as follows >> > >> > On the router with internet going into the WAN port (ETH1), BAT0 is >> > bridged with the LAN (ETH0) Internet works correctly though the lan, >> > so i would assume NAT routing to the WAN is setup correctly? >> >> so you have eth0 and bat0(ath0) in a bridge br0 -> eth1 uses nat to translate >> packets for/from eth1? > > Yes this is correct, bat0 and eth0 are bridged to form br-lan, which > uses nat to translate things over to eth1 > >> >> > On the router on the other end of the mesh, BAT0 is bridged with the >> > WAN port (ETH1) so that the router will route WAN traffic though BAT0? >> >> What? Why a different internet gateway and why do you bridge the bat0(ath0) >> interface with the wan interface instead of using nat here? >> > > Not sure what you mean by a "a different internet gateway" > > The way openWRT is setup, the WAN network is actually a bridge of bat0 > and wifi0 (which is the card that bat0 is running on) Talking this > though its looking like this might be the bit where the problem lies. > Its setup currently like this as i was initially trying to run OLSR > and BATMAN simultaneously (although have since simplified to just > batman). > > My theory was that if bat0 is the WAN, the NAT rules built into > openwrt would take control and internet would be routed though bat0. > > I have also attempted to setup nat myself at this end, but am so far > unsuccessful and loose the ability to even ping the internet. > > I think i am close to the solution as i can ping things, there is just > something missing. > > Will try un-bridging wifi0 and report on what happens. > >> Maybe there is a misunderstanding somewhere... At least I am extremely >> confused about your setup. >> >> Best regards, >> Sven > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 10:16 ` David Beaumont @ 2010-08-12 10:33 ` Marek Lindner 2010-08-12 10:41 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: Marek Lindner @ 2010-08-12 10:33 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking On Thursday 12 August 2010 12:16:29 David Beaumont wrote: > nexthops .. . [B.A.T.M.A.N. Adv 0.1 rv1176, MainIF/MAC: FYI: You use a very old version of batman-adv ... > Pings work fine, a wget just pauses and waits indefinitely That sounds like a MTU problem. What is the mtu of your wifi interfaces ? Here is a document describing the issue: http://www.open-mesh.org/wiki/batman-adv-quick-start-guide Cheers, Marek ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 10:33 ` Marek Lindner @ 2010-08-12 10:41 ` David Beaumont 2010-08-12 10:50 ` Marek Lindner 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-12 10:41 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking I originally had my MTU values set incorrectly, but believe i have them correct now router with internet ath0 - MTU 1524 (physical wifi device) bat0 - MTU 1500 br-lan - MTU 1500 (bridged with bat0/eth1) wifi0 - MTU 1500 (should this be 1524 also) router on otherside of mesh ath0 - MTU 1524 (physical wifi device) bat0 - MTU 1500 br-lan - MTU 1500 wifi0 - MTU 1500 (should this be 1524 also) I am aware that it is quite an old verison, although this is the version that is currently in the openwrt repo. I will compile a more recent version once i have the basics working i think. Thanks for you help so far guys, two people have suggested MTU issues now, so fingers crossed someone can see something wrong with the output above? On Thu, Aug 12, 2010 at 1:33 PM, Marek Lindner <lindner_marek@yahoo.de> wrote: > On Thursday 12 August 2010 12:16:29 David Beaumont wrote: >> nexthops .. . [B.A.T.M.A.N. Adv 0.1 rv1176, MainIF/MAC: > > FYI: You use a very old version of batman-adv ... > > >> Pings work fine, a wget just pauses and waits indefinitely > > That sounds like a MTU problem. What is the mtu of your wifi interfaces ? Here > is a document describing the issue: > http://www.open-mesh.org/wiki/batman-adv-quick-start-guide > > Cheers, > Marek > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 10:41 ` David Beaumont @ 2010-08-12 10:50 ` Marek Lindner 2010-08-12 11:08 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: Marek Lindner @ 2010-08-12 10:50 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking On Thursday 12 August 2010 12:41:41 David Beaumont wrote: > I originally had my MTU values set incorrectly, but believe i have > them correct now > > router with internet > > ath0 - MTU 1524 (physical wifi device) > > router on otherside of mesh > > ath0 - MTU 1524 (physical wifi device) Yes, that looks good. The problems you describe sound like MTU or firewall issues which is why I was asking. > wifi0 - MTU 1500 (should this be 1524 also) You should ignore the wifi0 interface and not include it in any configuration. It is of no relevance in your setup. > I am aware that it is quite an old verison, although this is the > version that is currently in the openwrt repo. I will compile a more > recent version once i have the basics working i think. Ok. > Thanks for you help so far guys, two people have suggested MTU issues > now, so fingers crossed someone can see something wrong with the > output above? Could you post the config of both nodes ? That includes: * ifconfig * brctl show * ip route / route -n * cat /proc/net/batman-adv/interfaces * iptables (-t nat) -vnL [on the internet-router] Regards, Marek ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 10:50 ` Marek Lindner @ 2010-08-12 11:08 ` David Beaumont 2010-08-12 11:29 ` Sven Eckelmann 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-12 11:08 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking [-- Attachment #1: Type: text/plain, Size: 1398 bytes --] Hopefully attachments come though ok? net_ is from the router connected to the internet mesh_ is the other side of the mesh On Thu, Aug 12, 2010 at 1:50 PM, Marek Lindner <lindner_marek@yahoo.de> wrote: > On Thursday 12 August 2010 12:41:41 David Beaumont wrote: >> I originally had my MTU values set incorrectly, but believe i have >> them correct now >> >> router with internet >> >> ath0 - MTU 1524 (physical wifi device) >> >> router on otherside of mesh >> >> ath0 - MTU 1524 (physical wifi device) > > Yes, that looks good. > The problems you describe sound like MTU or firewall issues which is why I was > asking. > > >> wifi0 - MTU 1500 (should this be 1524 also) > > You should ignore the wifi0 interface and not include it in any configuration. > It is of no relevance in your setup. > > >> I am aware that it is quite an old verison, although this is the >> version that is currently in the openwrt repo. I will compile a more >> recent version once i have the basics working i think. > > Ok. > > >> Thanks for you help so far guys, two people have suggested MTU issues >> now, so fingers crossed someone can see something wrong with the >> output above? > > Could you post the config of both nodes ? That includes: > * ifconfig > * brctl show > * ip route / route -n > * cat /proc/net/batman-adv/interfaces > * iptables (-t nat) -vnL [on the internet-router] > > Regards, > Marek > [-- Attachment #2: mesh_route.txt --] [-- Type: text/plain, Size: 500 bytes --] Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.2.4.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 bat0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br-wan 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 ath0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 br-wan [-- Attachment #3: net_bat_int.txt --] [-- Type: text/plain, Size: 7 bytes --] ath0 [-- Attachment #4: net_brctl.txt --] [-- Type: text/plain, Size: 96 bytes --] bridge name bridge id STP enabled interfaces br-lan 8000.000db9190e98 no bat0 eth0 [-- Attachment #5: net_ifconfig.txt --] [-- Type: text/plain, Size: 2923 bytes --] ath0 Link encap:Ethernet HWaddr 00:0C:42:3A:75:A2 inet addr:100.10.17.3 Bcast:100.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1524 Metric:1 RX packets:11668 errors:0 dropped:0 overruns:0 frame:0 TX packets:5843 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:479638 (468.3 KiB) TX bytes:283781 (277.1 KiB) bat0 Link encap:Ethernet HWaddr 00:FF:2E:BD:B6:7A inet addr:10.0.1.1 Bcast:10.0.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:299 errors:0 dropped:0 overruns:0 frame:0 TX packets:288 errors:0 dropped:1 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:24634 (24.0 KiB) TX bytes:26340 (25.7 KiB) br-lan Link encap:Ethernet HWaddr 00:0D:B9:19:0E:98 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:299 errors:0 dropped:0 overruns:0 frame:0 TX packets:289 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:20448 (19.9 KiB) TX bytes:26742 (26.1 KiB) eth0 Link encap:Ethernet HWaddr 00:0D:B9:19:0E:98 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:10 Base address:0xa000 eth1 Link encap:Ethernet HWaddr 00:0D:B9:19:0E:99 inet addr:192.168.0.117 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:826 errors:0 dropped:0 overruns:0 frame:0 TX packets:251 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:76111 (74.3 KiB) TX bytes:23895 (23.3 KiB) Interrupt:15 Base address:0x4000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:730 (730.0 B) TX bytes:730 (730.0 B) wifi0 Link encap:UNSPEC HWaddr 00-0C-42-3A-75-A2-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:38633 errors:0 dropped:0 overruns:0 frame:19 TX packets:5844 errors:1 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:195 RX bytes:3196920 (3.0 MiB) TX bytes:412355 (402.6 KiB) Interrupt:9 [-- Attachment #6: net_iptables.txt --] [-- Type: text/plain, Size: 8084 bytes --] Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 32 5332 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 4 224 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 syn_flood tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 484 41238 input_rule all -- * * 0.0.0.0/0 0.0.0.0/0 484 41238 input all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 172 14441 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 151 12653 forwarding_rule all -- * * 0.0.0.0/0 0.0.0.0/0 151 12653 forward all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 87 8790 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 4 224 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 31 2314 output_rule all -- * * 0.0.0.0/0 0.0.0.0/0 31 2314 output all -- * * 0.0.0.0/0 0.0.0.0/0 Chain forward (1 references) pkts bytes target prot opt in out source destination 151 12653 zone_lan_forward all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 zone_wan_forward all -- eth1 * 0.0.0.0/0 0.0.0.0/0 Chain forwarding_lan (1 references) pkts bytes target prot opt in out source destination Chain forwarding_rule (1 references) pkts bytes target prot opt in out source destination Chain forwarding_wan (1 references) pkts bytes target prot opt in out source destination Chain input (1 references) pkts bytes target prot opt in out source destination 85 5366 zone_lan all -- br-lan * 0.0.0.0/0 0.0.0.0/0 399 35872 zone_wan all -- eth1 * 0.0.0.0/0 0.0.0.0/0 Chain input_lan (1 references) pkts bytes target prot opt in out source destination Chain input_rule (1 references) pkts bytes target prot opt in out source destination Chain input_wan (1 references) pkts bytes target prot opt in out source destination Chain output (1 references) pkts bytes target prot opt in out source destination 31 2314 zone_lan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 28 1610 zone_wan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain output_rule (1 references) pkts bytes target prot opt in out source destination Chain reject (4 references) pkts bytes target prot opt in out source destination 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain syn_flood (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain zone_lan (1 references) pkts bytes target prot opt in out source destination 85 5366 input_lan all -- * * 0.0.0.0/0 0.0.0.0/0 85 5366 zone_lan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain zone_lan_ACCEPT (3 references) pkts bytes target prot opt in out source destination 236 18019 ACCEPT all -- br-lan * 0.0.0.0/0 0.0.0.0/0 3 704 ACCEPT all -- * br-lan 0.0.0.0/0 0.0.0.0/0 Chain zone_lan_DROP (0 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * br-lan 0.0.0.0/0 0.0.0.0/0 Chain zone_lan_MSSFIX (0 references) pkts bytes target prot opt in out source destination 0 0 TCPMSS tcp -- * br-lan 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Chain zone_lan_REJECT (0 references) pkts bytes target prot opt in out source destination 0 0 reject all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 reject all -- * br-lan 0.0.0.0/0 0.0.0.0/0 Chain zone_lan_forward (1 references) pkts bytes target prot opt in out source destination 151 12653 forwarding_lan all -- * * 0.0.0.0/0 0.0.0.0/0 151 12653 zone_lan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain zone_wan (1 references) pkts bytes target prot opt in out source destination 399 35872 input_wan all -- * * 0.0.0.0/0 0.0.0.0/0 399 35872 zone_wan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain zone_wan_ACCEPT (3 references) pkts bytes target prot opt in out source destination 399 35872 ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 28 1610 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0 Chain zone_wan_DROP (0 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- eth1 * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * eth1 0.0.0.0/0 0.0.0.0/0 Chain zone_wan_MSSFIX (0 references) pkts bytes target prot opt in out source destination 0 0 TCPMSS tcp -- * eth1 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Chain zone_wan_REJECT (0 references) pkts bytes target prot opt in out source destination 0 0 reject all -- eth1 * 0.0.0.0/0 0.0.0.0/0 0 0 reject all -- * eth1 0.0.0.0/0 0.0.0.0/0 Chain zone_wan_forward (1 references) pkts bytes target prot opt in out source destination 0 0 forwarding_wan all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 zone_wan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 [-- Attachment #7: net_route.txt --] [-- Type: text/plain, Size: 496 bytes --] Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 bat0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 100.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 ath0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1 [-- Attachment #8: mesh_bat_int.txt --] [-- Type: text/plain, Size: 7 bytes --] ath0 [-- Attachment #9: mesh_brctl.txt --] [-- Type: text/plain, Size: 145 bytes --] bridge name bridge id STP enabled interfaces br-lan 8000.00026f5ff579 no ath1 eth0 eth1 br-wan 8000.00ff6cf3df21 no bat0 [-- Attachment #10: mesh_ifconfig.txt --] [-- Type: text/plain, Size: 4024 bytes --] ath0 Link encap:Ethernet HWaddr 00:0C:42:60:12:CF inet addr:10.1.1.99 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1524 Metric:1 RX packets:12434 errors:0 dropped:21 overruns:0 frame:0 TX packets:6210 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:517016 (504.8 KiB) TX bytes:298735 (291.7 KiB) ath1 Link encap:Ethernet HWaddr 00:02:6F:5F:F5:79 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:172 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:18551 (18.1 KiB) bat0 Link encap:Ethernet HWaddr 00:FF:6C:F3:DF:21 inet addr:10.0.1.2 Bcast:10.0.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:309 errors:0 dropped:0 overruns:0 frame:0 TX packets:320 errors:0 dropped:8 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:28221 (27.5 KiB) TX bytes:26263 (25.6 KiB) br-lan Link encap:Ethernet HWaddr 00:02:6F:5F:F5:79 inet addr:10.2.4.99 Bcast:10.2.4.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:172 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16143 (15.7 KiB) TX bytes:0 (0.0 B) br-wan Link encap:Ethernet HWaddr 00:FF:6C:F3:DF:21 inet addr:192.168.1.180 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:309 errors:0 dropped:0 overruns:0 frame:0 TX packets:328 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:23895 (23.3 KiB) TX bytes:29479 (28.7 KiB) eth0 Link encap:Ethernet HWaddr 00:0D:B9:1A:16:04 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:172 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:18551 (18.1 KiB) TX bytes:0 (0.0 B) Interrupt:10 Base address:0x2000 eth1 Link encap:Ethernet HWaddr 00:0D:B9:1A:16:05 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:15 Base address:0x4000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:428 errors:0 dropped:0 overruns:0 frame:0 TX packets:428 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:30670 (29.9 KiB) TX bytes:30670 (29.9 KiB) wifi0 Link encap:UNSPEC HWaddr 00-0C-42-60-12-CF-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:34913 errors:0 dropped:0 overruns:0 frame:7 TX packets:6211 errors:1 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:195 RX bytes:2877961 (2.7 MiB) TX bytes:435383 (425.1 KiB) Interrupt:9 wifi1 Link encap:UNSPEC HWaddr 00-02-6F-5F-F5-79-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:41257 errors:0 dropped:0 overruns:0 frame:6321 TX packets:172 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:195 RX bytes:4206382 (4.0 MiB) TX bytes:22335 (21.8 KiB) Interrupt:11 [-- Attachment #11: mesh_iptables.txt --] [-- Type: text/plain, Size: 3269 bytes --] Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4305 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4306 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4307 462 40769 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT tcp -- ath0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT udp -- ath0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:698 0 0 ACCEPT tcp -- ath0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:698 0 0 ACCEPT udp -- ath0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- ath0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:888 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 0 0 ACCEPT tcp -- ath0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 REJECT all -- ath0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 ACCEPT tcp -- br-lan * 0.0.0.0/0 10.2.4.99 tcp dpt:22 0 0 ACCEPT tcp -- br-lan * 0.0.0.0/0 10.2.4.99 tcp dpt:888 0 0 ACCEPT udp -- br-lan * 0.0.0.0/0 0.0.0.0/0 udp dpt:698 0 0 ACCEPT tcp -- br-lan * 0.0.0.0/0 0.0.0.0/0 tcp dpt:698 0 0 ACCEPT udp -- br-lan * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- br-lan * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 70 6092 DROP all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3990 flags:0x17/0x02 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:698 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:698 218 12060 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * br-lan 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 695 packets, 50721 bytes) pkts bytes target prot opt in out source destination ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 11:08 ` David Beaumont @ 2010-08-12 11:29 ` Sven Eckelmann 2010-08-12 11:41 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: Sven Eckelmann @ 2010-08-12 11:29 UTC (permalink / raw) To: b.a.t.m.a.n; +Cc: David Beaumont [-- Attachment #1: Type: Text/Plain, Size: 544 bytes --] David Beaumont wrote: > Hopefully attachments come though ok? > > net_ is from the router connected to the internet > mesh_ is the other side of the mesh to the mesh thing: * Why has ath0 an IP... which also conflicts with the ip range of bat0 and br-lan? * Why has bat0 an ip when it is part of br-wan. * Why has the ath0 device iptables entries? to the net thing: * why has bat0 an ip when it is part of br-lan? Why don't I see masquerade anywhere in the iptables output (-t nat)? Best regards, Sven [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 11:29 ` Sven Eckelmann @ 2010-08-12 11:41 ` David Beaumont 2010-08-12 13:14 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-12 11:41 UTC (permalink / raw) To: b.a.t.m.a.n It does appear that i have got somewhat confused with my ip ranges and addresses, let me try and clear that up now as ath0 and bat0 certainly doesn't need an ip address. Sorry for my oversight on this, i've gotten myself in a bit of a mess trying to resolve this by the looks of things. Ah, sorry i missed the nat information here it is mesh_ Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain luci_splash_leases (1 references) target prot opt source destination REDIRECT tcp -- anywhere anywhere tcp dpt:80 redir ports 8082 DROP all -- anywhere anywhere Chain luci_splash_portal (0 references) target prot opt source destination RETURN udp -- anywhere anywhere udp dpts:33434:33523 RETURN icmp -- anywhere anywhere RETURN udp -- anywhere anywhere udp dpt:53 luci_splash_leases all -- anywhere anywhere Chain luci_splash_prerouting (0 references) target prot opt source destination Chain natfix_ath0 (0 references) target prot opt source destination ACCEPT all -- 10.0.0.0/8 10.0.0.0/8 Chain natfix_br-lan (0 references) target prot opt source destination ACCEPT all -- 10.2.4.0/24 10.2.4.0/24 Chain natfix_br-wan (0 references) target prot opt source destination ACCEPT all -- 192.168.1.0/24 192.168.1.0/24 net_ Chain PREROUTING (policy ACCEPT) target prot opt source destination zone_wan_prerouting all -- anywhere anywhere zone_lan_prerouting all -- anywhere anywhere prerouting_rule all -- anywhere anywhere Chain POSTROUTING (policy ACCEPT) target prot opt source destination postrouting_rule all -- anywhere anywhere zone_wan_nat all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain postrouting_rule (1 references) target prot opt source destination Chain prerouting_lan (1 references) target prot opt source destination Chain prerouting_rule (1 references) target prot opt source destination Chain prerouting_wan (1 references) target prot opt source destination Chain zone_lan_nat (0 references) target prot opt source destination MASQUERADE all -- anywhere anywhere Chain zone_lan_prerouting (1 references) target prot opt source destination prerouting_lan all -- anywhere anywhere Chain zone_wan_nat (1 references) target prot opt source destination MASQUERADE all -- anywhere anywhere Chain zone_wan_prerouting (1 references) target prot opt source destination prerouting_wan all -- anywhere anywhere On Thu, Aug 12, 2010 at 2:29 PM, Sven Eckelmann <sven.eckelmann@gmx.de> wrote: > David Beaumont wrote: >> Hopefully attachments come though ok? >> >> net_ is from the router connected to the internet >> mesh_ is the other side of the mesh > > to the mesh thing: > > * Why has ath0 an IP... which also conflicts with the ip range of bat0 and > br-lan? > > * Why has bat0 an ip when it is part of br-wan. > > * Why has the ath0 device iptables entries? > > to the net thing: > > * why has bat0 an ip when it is part of br-lan? > > > Why don't I see masquerade anywhere in the iptables output (-t nat)? > > Best regards, > Sven > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 11:41 ` David Beaumont @ 2010-08-12 13:14 ` David Beaumont 2010-08-12 13:19 ` Marek Lindner 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-12 13:14 UTC (permalink / raw) To: b.a.t.m.a.n I have removed the extra ip addresses that where not needed and tried to simplify a few other things, however i am still in the same position where i can ping but not transfer. Can anybody see anything wrong with my NAT rules that could be causing this? On Thu, Aug 12, 2010 at 2:41 PM, David Beaumont <djb31st@gmail.com> wrote: > It does appear that i have got somewhat confused with my ip ranges and > addresses, let me try and clear that up now as ath0 and bat0 certainly > doesn't need an ip address. > > Sorry for my oversight on this, i've gotten myself in a bit of a mess > trying to resolve this by the looks of things. > > Ah, sorry i missed the nat information here it is > > mesh_ > > Chain PREROUTING (policy ACCEPT) > target prot opt source destination > > Chain POSTROUTING (policy ACCEPT) > target prot opt source destination > MASQUERADE all -- anywhere anywhere > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > Chain luci_splash_leases (1 references) > target prot opt source destination > REDIRECT tcp -- anywhere anywhere tcp > dpt:80 redir ports 8082 > DROP all -- anywhere anywhere > > Chain luci_splash_portal (0 references) > target prot opt source destination > RETURN udp -- anywhere anywhere udp > dpts:33434:33523 > RETURN icmp -- anywhere anywhere > RETURN udp -- anywhere anywhere udp dpt:53 > luci_splash_leases all -- anywhere anywhere > > Chain luci_splash_prerouting (0 references) > target prot opt source destination > > Chain natfix_ath0 (0 references) > target prot opt source destination > ACCEPT all -- 10.0.0.0/8 10.0.0.0/8 > > Chain natfix_br-lan (0 references) > target prot opt source destination > ACCEPT all -- 10.2.4.0/24 10.2.4.0/24 > > Chain natfix_br-wan (0 references) > target prot opt source destination > ACCEPT all -- 192.168.1.0/24 192.168.1.0/24 > > > net_ > > Chain PREROUTING (policy ACCEPT) > target prot opt source destination > zone_wan_prerouting all -- anywhere anywhere > zone_lan_prerouting all -- anywhere anywhere > prerouting_rule all -- anywhere anywhere > > Chain POSTROUTING (policy ACCEPT) > target prot opt source destination > postrouting_rule all -- anywhere anywhere > zone_wan_nat all -- anywhere anywhere > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > Chain postrouting_rule (1 references) > target prot opt source destination > > Chain prerouting_lan (1 references) > target prot opt source destination > > Chain prerouting_rule (1 references) > target prot opt source destination > > Chain prerouting_wan (1 references) > target prot opt source destination > > Chain zone_lan_nat (0 references) > target prot opt source destination > MASQUERADE all -- anywhere anywhere > > Chain zone_lan_prerouting (1 references) > target prot opt source destination > prerouting_lan all -- anywhere anywhere > > Chain zone_wan_nat (1 references) > target prot opt source destination > MASQUERADE all -- anywhere anywhere > > Chain zone_wan_prerouting (1 references) > target prot opt source destination > prerouting_wan all -- anywhere anywhere > > > > On Thu, Aug 12, 2010 at 2:29 PM, Sven Eckelmann <sven.eckelmann@gmx.de> wrote: >> David Beaumont wrote: >>> Hopefully attachments come though ok? >>> >>> net_ is from the router connected to the internet >>> mesh_ is the other side of the mesh >> >> to the mesh thing: >> >> * Why has ath0 an IP... which also conflicts with the ip range of bat0 and >> br-lan? >> >> * Why has bat0 an ip when it is part of br-wan. >> >> * Why has the ath0 device iptables entries? >> >> to the net thing: >> >> * why has bat0 an ip when it is part of br-lan? >> >> >> Why don't I see masquerade anywhere in the iptables output (-t nat)? >> >> Best regards, >> Sven >> > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 13:14 ` David Beaumont @ 2010-08-12 13:19 ` Marek Lindner 2010-08-12 13:26 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: Marek Lindner @ 2010-08-12 13:19 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking On Thursday 12 August 2010 15:14:08 David Beaumont wrote: > I have removed the extra ip addresses that where not needed and tried > to simplify a few other things, however i am still in the same > position where i can ping but not transfer. > > Can anybody see anything wrong with my NAT rules that could be causing > this? Would you mind posting your new settings ? Regards, Marek ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 13:19 ` Marek Lindner @ 2010-08-12 13:26 ` David Beaumont 2010-08-12 13:27 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-12 13:26 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking [-- Attachment #1: Type: text/plain, Size: 632 bytes --] Here are the settings on the mesh node, will include internet node in next post Thank you for taking the time to try and work though this with me. On Thu, Aug 12, 2010 at 4:19 PM, Marek Lindner <lindner_marek@yahoo.de> wrote: > On Thursday 12 August 2010 15:14:08 David Beaumont wrote: >> I have removed the extra ip addresses that where not needed and tried >> to simplify a few other things, however i am still in the same >> position where i can ping but not transfer. >> >> Can anybody see anything wrong with my NAT rules that could be causing >> this? > > Would you mind posting your new settings ? > > > Regards, > Marek > [-- Attachment #2: mesh_iptables.txt --] [-- Type: text/plain, Size: 3270 bytes --] Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4305 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4306 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4307 856 79790 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT tcp -- ath0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT udp -- ath0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:698 0 0 ACCEPT tcp -- ath0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:698 0 0 ACCEPT udp -- ath0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- ath0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:888 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 0 0 ACCEPT tcp -- ath0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 REJECT all -- ath0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 3 1152 ACCEPT tcp -- br-lan * 0.0.0.0/0 10.2.4.99 tcp dpt:22 0 0 ACCEPT tcp -- br-lan * 0.0.0.0/0 10.2.4.99 tcp dpt:888 0 0 ACCEPT udp -- br-lan * 0.0.0.0/0 0.0.0.0/0 udp dpt:698 0 0 ACCEPT tcp -- br-lan * 0.0.0.0/0 0.0.0.0/0 tcp dpt:698 0 0 ACCEPT udp -- br-lan * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- br-lan * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 DROP all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3990 flags:0x17/0x02 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:698 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:698 383 21153 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * br-lan 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 1293 packets, 95720 bytes) pkts bytes target prot opt in out source destination [-- Attachment #3: mesh_iptables_t.txt --] [-- Type: text/plain, Size: 1453 bytes --] Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain luci_splash_leases (1 references) target prot opt source destination REDIRECT tcp -- anywhere anywhere tcp dpt:80 redir ports 8082 DROP all -- anywhere anywhere Chain luci_splash_portal (0 references) target prot opt source destination RETURN udp -- anywhere anywhere udp dpts:33434:33523 RETURN icmp -- anywhere anywhere RETURN udp -- anywhere anywhere udp dpt:53 luci_splash_leases all -- anywhere anywhere Chain luci_splash_prerouting (0 references) target prot opt source destination Chain natfix_br-lan (0 references) target prot opt source destination ACCEPT all -- 10.2.4.0/24 10.2.4.0/24 Chain natfix_br-wan (0 references) target prot opt source destination ACCEPT all -- 192.168.1.0/24 192.168.1.0/24 [-- Attachment #4: mesh_route.txt --] [-- Type: text/plain, Size: 344 bytes --] Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.2.4.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br-wan 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 br-wan [-- Attachment #5: mesh_bat_int.txt --] [-- Type: text/plain, Size: 7 bytes --] ath0 [-- Attachment #6: mesh_brctl.txt --] [-- Type: text/plain, Size: 145 bytes --] bridge name bridge id STP enabled interfaces br-lan 8000.00026f5ff579 no ath1 eth0 eth1 br-wan 8000.00ff0a3145a1 no bat0 [-- Attachment #7: mesh_ifconfig.txt --] [-- Type: text/plain, Size: 3908 bytes --] ath0 Link encap:Ethernet HWaddr 00:0C:42:60:12:CF UP BROADCAST RUNNING MULTICAST MTU:1524 Metric:1 RX packets:22750 errors:0 dropped:0 overruns:0 frame:0 TX packets:11473 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:936478 (914.5 KiB) TX bytes:555386 (542.3 KiB) ath1 Link encap:Ethernet HWaddr 00:02:6F:5F:F5:79 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:445 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:44795 (43.7 KiB) bat0 Link encap:Ethernet HWaddr 00:FF:0A:31:45:A1 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:483 errors:0 dropped:0 overruns:0 frame:0 TX packets:517 errors:0 dropped:2 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:44684 (43.6 KiB) TX bytes:50591 (49.4 KiB) br-lan Link encap:Ethernet HWaddr 00:02:6F:5F:F5:79 inet addr:10.2.4.99 Bcast:10.2.4.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:547 errors:0 dropped:0 overruns:0 frame:0 TX packets:142 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:52761 (51.5 KiB) TX bytes:14335 (13.9 KiB) br-wan Link encap:Ethernet HWaddr 00:FF:0A:31:45:A1 inet addr:192.168.1.113 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:483 errors:0 dropped:0 overruns:0 frame:0 TX packets:519 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:37922 (37.0 KiB) TX bytes:51395 (50.1 KiB) eth0 Link encap:Ethernet HWaddr 00:0D:B9:1A:16:04 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:547 errors:0 dropped:0 overruns:0 frame:0 TX packets:142 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:60419 (59.0 KiB) TX bytes:14335 (13.9 KiB) Interrupt:10 Base address:0x2000 eth1 Link encap:Ethernet HWaddr 00:0D:B9:1A:16:05 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:15 Base address:0x4000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:758 errors:0 dropped:0 overruns:0 frame:0 TX packets:758 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:52903 (51.6 KiB) TX bytes:52903 (51.6 KiB) wifi0 Link encap:UNSPEC HWaddr 00-0C-42-60-12-CF-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:64484 errors:0 dropped:0 overruns:0 frame:11 TX packets:11473 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:195 RX bytes:5312379 (5.0 MiB) TX bytes:807792 (788.8 KiB) Interrupt:9 wifi1 Link encap:UNSPEC HWaddr 00-02-6F-5F-F5-79-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:71236 errors:0 dropped:0 overruns:0 frame:12053 TX packets:457 errors:4 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:195 RX bytes:7158643 (6.8 MiB) TX bytes:55965 (54.6 KiB) Interrupt:11 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 13:26 ` David Beaumont @ 2010-08-12 13:27 ` David Beaumont 2010-08-13 5:45 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-12 13:27 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking [-- Attachment #1: Type: text/plain, Size: 761 bytes --] internet node settings Dave On Thu, Aug 12, 2010 at 4:26 PM, David Beaumont <djb31st@gmail.com> wrote: > Here are the settings on the mesh node, will include internet node in next post > > Thank you for taking the time to try and work though this with me. > > On Thu, Aug 12, 2010 at 4:19 PM, Marek Lindner <lindner_marek@yahoo.de> wrote: >> On Thursday 12 August 2010 15:14:08 David Beaumont wrote: >>> I have removed the extra ip addresses that where not needed and tried >>> to simplify a few other things, however i am still in the same >>> position where i can ping but not transfer. >>> >>> Can anybody see anything wrong with my NAT rules that could be causing >>> this? >> >> Would you mind posting your new settings ? >> >> >> Regards, >> Marek >> > [-- Attachment #2: net_iptables.txt --] [-- Type: text/plain, Size: 8084 bytes --] Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 145 19828 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 1 52 syn_flood tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 1025 88330 input_rule all -- * * 0.0.0.0/0 0.0.0.0/0 1025 88330 input all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 311 25862 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 285 23909 forwarding_rule all -- * * 0.0.0.0/0 0.0.0.0/0 285 23909 forward all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 241 24588 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 51 3364 output_rule all -- * * 0.0.0.0/0 0.0.0.0/0 51 3364 output all -- * * 0.0.0.0/0 0.0.0.0/0 Chain forward (1 references) pkts bytes target prot opt in out source destination 285 23909 zone_lan_forward all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 zone_wan_forward all -- eth1 * 0.0.0.0/0 0.0.0.0/0 Chain forwarding_lan (1 references) pkts bytes target prot opt in out source destination Chain forwarding_rule (1 references) pkts bytes target prot opt in out source destination Chain forwarding_wan (1 references) pkts bytes target prot opt in out source destination Chain input (1 references) pkts bytes target prot opt in out source destination 95 5919 zone_lan all -- br-lan * 0.0.0.0/0 0.0.0.0/0 930 82411 zone_wan all -- eth1 * 0.0.0.0/0 0.0.0.0/0 Chain input_lan (1 references) pkts bytes target prot opt in out source destination Chain input_rule (1 references) pkts bytes target prot opt in out source destination Chain input_wan (1 references) pkts bytes target prot opt in out source destination Chain output (1 references) pkts bytes target prot opt in out source destination 51 3364 zone_lan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 48 2660 zone_wan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain output_rule (1 references) pkts bytes target prot opt in out source destination Chain reject (4 references) pkts bytes target prot opt in out source destination 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain syn_flood (1 references) pkts bytes target prot opt in out source destination 1 52 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain zone_lan (1 references) pkts bytes target prot opt in out source destination 95 5919 input_lan all -- * * 0.0.0.0/0 0.0.0.0/0 95 5919 zone_lan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain zone_lan_ACCEPT (3 references) pkts bytes target prot opt in out source destination 380 29828 ACCEPT all -- br-lan * 0.0.0.0/0 0.0.0.0/0 3 704 ACCEPT all -- * br-lan 0.0.0.0/0 0.0.0.0/0 Chain zone_lan_DROP (0 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * br-lan 0.0.0.0/0 0.0.0.0/0 Chain zone_lan_MSSFIX (0 references) pkts bytes target prot opt in out source destination 0 0 TCPMSS tcp -- * br-lan 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Chain zone_lan_REJECT (0 references) pkts bytes target prot opt in out source destination 0 0 reject all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 reject all -- * br-lan 0.0.0.0/0 0.0.0.0/0 Chain zone_lan_forward (1 references) pkts bytes target prot opt in out source destination 285 23909 forwarding_lan all -- * * 0.0.0.0/0 0.0.0.0/0 285 23909 zone_lan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain zone_wan (1 references) pkts bytes target prot opt in out source destination 930 82411 input_wan all -- * * 0.0.0.0/0 0.0.0.0/0 930 82411 zone_wan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain zone_wan_ACCEPT (3 references) pkts bytes target prot opt in out source destination 930 82411 ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 48 2660 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0 Chain zone_wan_DROP (0 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- eth1 * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * eth1 0.0.0.0/0 0.0.0.0/0 Chain zone_wan_MSSFIX (0 references) pkts bytes target prot opt in out source destination 0 0 TCPMSS tcp -- * eth1 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Chain zone_wan_REJECT (0 references) pkts bytes target prot opt in out source destination 0 0 reject all -- eth1 * 0.0.0.0/0 0.0.0.0/0 0 0 reject all -- * eth1 0.0.0.0/0 0.0.0.0/0 Chain zone_wan_forward (1 references) pkts bytes target prot opt in out source destination 0 0 forwarding_wan all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 zone_wan_ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 [-- Attachment #3: net_iptables_t.txt --] [-- Type: text/plain, Size: 1732 bytes --] Chain PREROUTING (policy ACCEPT) target prot opt source destination zone_wan_prerouting all -- anywhere anywhere zone_lan_prerouting all -- anywhere anywhere prerouting_rule all -- anywhere anywhere Chain POSTROUTING (policy ACCEPT) target prot opt source destination postrouting_rule all -- anywhere anywhere zone_wan_nat all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain postrouting_rule (1 references) target prot opt source destination Chain prerouting_lan (1 references) target prot opt source destination Chain prerouting_rule (1 references) target prot opt source destination Chain prerouting_wan (1 references) target prot opt source destination Chain zone_lan_nat (0 references) target prot opt source destination MASQUERADE all -- anywhere anywhere Chain zone_lan_prerouting (1 references) target prot opt source destination prerouting_lan all -- anywhere anywhere Chain zone_wan_nat (1 references) target prot opt source destination MASQUERADE all -- anywhere anywhere Chain zone_wan_prerouting (1 references) target prot opt source destination prerouting_wan all -- anywhere anywhere [-- Attachment #4: net_route.txt --] [-- Type: text/plain, Size: 340 bytes --] Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1 [-- Attachment #5: net_bat_int.txt --] [-- Type: text/plain, Size: 7 bytes --] ath0 [-- Attachment #6: net_brctl.txt --] [-- Type: text/plain, Size: 96 bytes --] bridge name bridge id STP enabled interfaces br-lan 8000.000db9190e98 no bat0 eth0 [-- Attachment #7: net_ifconfig.txt --] [-- Type: text/plain, Size: 2780 bytes --] ath0 Link encap:Ethernet HWaddr 00:0C:42:3A:75:A2 UP BROADCAST RUNNING MULTICAST MTU:1524 Metric:1 RX packets:23704 errors:0 dropped:12 overruns:0 frame:0 TX packets:11831 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:964278 (941.6 KiB) TX bytes:568445 (555.1 KiB) bat0 Link encap:Ethernet HWaddr 00:FF:7A:EC:B9:54 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:513 errors:0 dropped:0 overruns:0 frame:0 TX packets:503 errors:0 dropped:1 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:41892 (40.9 KiB) TX bytes:46343 (45.2 KiB) br-lan Link encap:Ethernet HWaddr 00:0D:B9:19:0E:98 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:513 errors:0 dropped:0 overruns:0 frame:0 TX packets:504 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:34710 (33.8 KiB) TX bytes:46745 (45.6 KiB) eth0 Link encap:Ethernet HWaddr 00:0D:B9:19:0E:98 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:10 Base address:0xa000 eth1 Link encap:Ethernet HWaddr 00:0D:B9:19:0E:99 inet addr:192.168.0.117 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1870 errors:0 dropped:0 overruns:0 frame:0 TX packets:606 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:176445 (172.3 KiB) TX bytes:53822 (52.5 KiB) Interrupt:15 Base address:0x4000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) wifi0 Link encap:UNSPEC HWaddr 00-0C-42-3A-75-A2-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:66684 errors:0 dropped:0 overruns:0 frame:0 TX packets:11831 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:195 RX bytes:5486567 (5.2 MiB) TX bytes:828727 (809.3 KiB) Interrupt:9 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-12 13:27 ` David Beaumont @ 2010-08-13 5:45 ` David Beaumont 2010-08-14 14:46 ` Marek Lindner 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-13 5:45 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking Anything that looks obviously out of place here? On Thu, Aug 12, 2010 at 4:27 PM, David Beaumont <djb31st@gmail.com> wrote: > internet node settings > > Dave > > On Thu, Aug 12, 2010 at 4:26 PM, David Beaumont <djb31st@gmail.com> wrote: >> Here are the settings on the mesh node, will include internet node in next post >> >> Thank you for taking the time to try and work though this with me. >> >> On Thu, Aug 12, 2010 at 4:19 PM, Marek Lindner <lindner_marek@yahoo.de> wrote: >>> On Thursday 12 August 2010 15:14:08 David Beaumont wrote: >>>> I have removed the extra ip addresses that where not needed and tried >>>> to simplify a few other things, however i am still in the same >>>> position where i can ping but not transfer. >>>> >>>> Can anybody see anything wrong with my NAT rules that could be causing >>>> this? >>> >>> Would you mind posting your new settings ? >>> >>> >>> Regards, >>> Marek >>> >> > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-13 5:45 ` David Beaumont @ 2010-08-14 14:46 ` Marek Lindner 2010-08-16 13:11 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: Marek Lindner @ 2010-08-14 14:46 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking On Friday 13 August 2010 07:45:07 David Beaumont wrote: > Anything that looks obviously out of place here? I see nothing obviously wrong here. The best next step is using tcpdump / batctl / wireshark to find out where the packets get dropped. Feel free to share the result with us. :-) Regards, Marek ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-14 14:46 ` Marek Lindner @ 2010-08-16 13:11 ` David Beaumont 2010-08-16 16:32 ` Sven Eckelmann 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-16 13:11 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking [-- Attachment #1: Type: text/plain, Size: 659 bytes --] 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 :-( On Sat, Aug 14, 2010 at 5:46 PM, Marek Lindner <lindner_marek@yahoo.de> wrote: > > On Friday 13 August 2010 07:45:07 David Beaumont wrote: > > Anything that looks obviously out of place here? > > I see nothing obviously wrong here. > The best next step is using tcpdump / batctl / wireshark to find out where the > packets get dropped. Feel free to share the result with us. :-) > > > Regards, > Marek [-- Attachment #2: tcpdump_ping.txt --] [-- Type: text/plain, Size: 983 bytes --] tcpdump -i bat0 (whilst ping http://www.google.com from mesh node) 14:25:23.578878 IP 192.168.1.119.37516 > 192.168.1.1.53: 41268+ AAAA? google.com . (28) 14:25:23.580815 IP 192.168.1.1.53 > 192.168.1.119.37516: 41268 0/0/0 (28) 14:25:23.581578 IP 192.168.1.119.64720 > 192.168.1.1.53: 63944+ AAAA? google.com . (28) 14:25:23.588693 IP 192.168.1.1.53 > 192.168.1.119.64720: 63944 0/0/0 (28) 14:25:23.593001 IP 192.168.1.119.37149 > 192.168.1.1.53: 18911+ AAAA? google.com . (28) 14:25:23.598676 IP 192.168.1.1.53 > 192.168.1.119.37149: 18911 0/0/0 (28) 14:25:23.603824 IP 192.168.1.119 > fx-in-f104.1e100.net: ICMP echo request, id 1 6134, seq 0, length 64 14:25:23.730452 IP fx-in-f104.1e100.net > 192.168.1.119: ICMP echo reply, id 161 34, seq 0, length 64 14:25:24.612730 IP 192.168.1.119 > fx-in-f104.1e100.net: ICMP echo request, id 1 6134, seq 1, length 64 14:25:24.740792 IP fx-in-f104.1e100.net > 192.168.1.119: ICMP echo reply, id 161 34, seq 1, length 64 [-- Attachment #3: tcpdump_wget.txt --] [-- Type: text/plain, Size: 1016 bytes --] tcpdump -i bat0 (whilst wget http://www.google.com from mesh node) 4:25:57.259453 IP 192.168.1.119.37746 > 192.168.1.1.53: 37899+ AAAA? www.google .com. (32) 14:25:57.304084 IP 192.168.1.1.53 > 192.168.1.119.37746: 37899 1/1/0 CNAME www.l .google.com. (102) 14:25:57.314561 IP 192.168.1.119.12656 > 192.168.1.1.53: 51848+ A? www.google.co m. (32) 14:25:57.321923 IP 192.168.1.1.53 > 192.168.1.119.12656: 51848 7/0/0 CNAME[|doma in] 14:25:57.323845 IP 192.168.1.119.54396 > fx-in-f147.1e100.net.80: SWE 576811426: 576811426(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4> 14:25:57.432719 IP fx-in-f147.1e100.net.80 > 192.168.1.119.54396: S 2862198252:2 862198252(0) ack 576811427 win 5720 <mss 1430,nop,nop,sackOK,nop,wscale 6> 14:25:57.433281 IP 192.168.1.119.54396 > fx-in-f147.1e100.net.80: . ack 1 win 36 5 14:25:57.433660 IP 192.168.1.119.54396 > fx-in-f147.1e100.net.80: P 1:78(77) ack 1 win 365 14:26:00.433415 IP 192.168.1.119.54396 > fx-in-f147.1e100.net.80: P 1:78(77) ack 1 win 365 [-- Attachment #4: tcpdump_wget_eth1.txt --] [-- Type: text/plain, Size: 819 bytes --] tcpdump -i eth1 (whilst wget http://www.google.com from mesh node) 14:26:36.409857 IP 192.168.0.117.35199 > fx-in-f99.1e100.net.80: SWE 1188618495: 1188618495(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 4> 14:26:36.410482 IP 192.168.0.117.14600 > 192.168.0.1.53: 48720+ PTR? 99.39.125.7 4.in-addr.arpa. (43) 14:26:36.524517 IP 192.168.0.1.53 > 192.168.0.117.14600: 48720 1/4/4 (222) 14:26:36.529445 IP fx-in-f99.1e100.net.80 > 192.168.0.117.35199: S 3729599604:37 29599604(0) ack 1188618496 win 5720 <mss 1430,nop,nop,sackOK,nop,wscale 6> 14:26:36.534416 IP 192.168.0.117.35199 > fx-in-f99.1e100.net.80: . ack 1 win 365 14:26:36.539747 IP 192.168.0.117.35199 > fx-in-f99.1e100.net.80: P 1:78(77) ack 1 win 365 14:26:39.537084 IP 192.168.0.117.35199 > fx-in-f99.1e100.net.80: P 1:78(77) ack 1 win 365 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-16 13:11 ` David Beaumont @ 2010-08-16 16:32 ` Sven Eckelmann 2010-08-17 8:14 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: Sven Eckelmann @ 2010-08-16 16:32 UTC (permalink / raw) To: b.a.t.m.a.n; +Cc: David Beaumont [-- Attachment #1: Type: Text/Plain, Size: 1075 bytes --] 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 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-16 16:32 ` Sven Eckelmann @ 2010-08-17 8:14 ` David Beaumont 2010-08-20 9:53 ` David Beaumont 2010-08-20 9:57 ` David Beaumont 0 siblings, 2 replies; 27+ messages in thread From: David Beaumont @ 2010-08-17 8:14 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-17 8:14 ` David Beaumont @ 2010-08-20 9:53 ` David Beaumont 2010-08-20 9:57 ` David Beaumont 1 sibling, 0 replies; 27+ messages in thread From: David Beaumont @ 2010-08-20 9:53 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking 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 root@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) root@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 > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-17 8:14 ` David Beaumont 2010-08-20 9:53 ` David Beaumont @ 2010-08-20 9:57 ` David Beaumont 2010-08-20 9:58 ` David Beaumont 1 sibling, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-20 9:57 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking 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 >> > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-20 9:57 ` David Beaumont @ 2010-08-20 9:58 ` David Beaumont 2010-08-20 11:27 ` Sven Eckelmann 0 siblings, 1 reply; 27+ messages in thread From: David Beaumont @ 2010-08-20 9:58 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking 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 Fri, Aug 20, 2010 at 12:57 PM, David Beaumont <djb31st@gmail.com> 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 > > 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 >>> >> > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-20 9:58 ` David Beaumont @ 2010-08-20 11:27 ` Sven Eckelmann 2010-08-23 7:05 ` David Beaumont 0 siblings, 1 reply; 27+ messages in thread From: Sven Eckelmann @ 2010-08-20 11:27 UTC (permalink / raw) To: b.a.t.m.a.n; +Cc: David Beaumont [-- Attachment #1: Type: Text/Plain, Size: 2808 bytes --] On Friday 20 August 2010 11:58:32 David Beaumont wrote: > So large pings appear to be going over the batman interface. So, first you say that all packets go over the bat interface and that this part works fine. Now you say that large packets will also work... which is no gain of information for the batman-adv related parts. > 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 :-( Create a real minimal setup. Minimal as possible. Get that working and then at parts to it (iptables, bridges, ...) until it doesn't work anymore. Check if that is real the part which makes the problem by reducing the complexity of other parts you already added. You already told us that it is not related to batman-adv and that the bridge makes problems. Actually nobody understands here what you are currently try to archive with your setup and why all the iptables or maybe ebtables stuff/bridges/... is needed to find a problem. And why have both mesh and net (for whatever they are used) a masquerade rule in postrouting? Simplest setup would be: * net is a nat router; everything in iptables to accept: iptables -F iptables -t nat -F iptables -t mangle -F iptables -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT masquerade enabled iptables -t nat -A POSTROUTING -o "${OUTIF}" -j MASQUERADE * configure outif (the thing which has globally routable address) * enable wired connection between net and mesh by adding them to the same subnet (eth0 on net 192.168.1.1, eth0 on mesh 192.168.1.2) * Try to ping each other * test if connection between net and internet works flawless * test if connection between mesh and indirectly to the internet over net works flawless * set mtu of eth0 on both sides to 1530 * check if `ping -M do -s 1500` works between both net and mesh * remove ip addresses of eth0 on both ends (but keep devices up) * add eth0 on both sides using `batctl if add` to bat0 * set mtu of bat0 to 1500 on both hosts * give bat0 the same ips which were used before by eth0 * set bat0 up * check if both hosts finds each other using `batctl o` * try to ping other host * try if internet works flawless indirectly from mesh over net * remove ip from bat0 devices * add bat0 to a bridge on both ends * set ips which were used by bat0 to the bridge devices * set mtu of bridge to 1500 * try to.... I think you can guess the next 1000 steps by yourself Regards, Sven [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [B.A.T.M.A.N.] Nat Question 2010-08-20 11:27 ` Sven Eckelmann @ 2010-08-23 7:05 ` David Beaumont 0 siblings, 0 replies; 27+ messages in thread From: David Beaumont @ 2010-08-23 7:05 UTC (permalink / raw) To: b.a.t.m.a.n Hi Sven, Thanks so much for your patience with this matter and for holding my hand though the process. I have gone back to basics (i think trying to adapt my current olsr platform over to this was the root cause of the issue) and now i am able to retrieve webpages over the bat interface. I'll briefly outline the steps i took to get batman working with openwrt Kamikaze *net router* configure wan vi /etc/config/network config interface wan option ifname "eth1" option proto dhcp *the following should be done on both the net and mesh router* set the ip address of eth0 to 192.168.1.1 (.2 on the mesh) configure wireless cards in /etc/config/wireless so that they have the same BSSID and channel. opkg update opkg install kmod-batman-advanced reboot bridge the eth0 and bat0 interfaces (may not be the best way) Ensure that you can see the other node cat /proc/net/batman-adv/originators test pinging the internet Thanks On Fri, Aug 20, 2010 at 2:27 PM, Sven Eckelmann <sven.eckelmann@gmx.de> wrote: > > On Friday 20 August 2010 11:58:32 David Beaumont wrote: > > So large pings appear to be going over the batman interface. > > So, first you say that all packets go over the bat interface and that this > part works fine. Now you say that large packets will also work... which is no > gain of information for the batman-adv related parts. > > > 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 :-( > > Create a real minimal setup. Minimal as possible. Get that working and then at > parts to it (iptables, bridges, ...) until it doesn't work anymore. Check if > that is real the part which makes the problem by reducing the complexity of > other parts you already added. > > You already told us that it is not related to batman-adv and that the bridge > makes problems. > > Actually nobody understands here what you are currently try to archive with > your setup and why all the iptables or maybe ebtables stuff/bridges/... is > needed to find a problem. > > And why have both mesh and net (for whatever they are used) a masquerade rule > in postrouting? > > > Simplest setup would be: > * net is a nat router; everything in iptables to accept: > iptables -F > iptables -t nat -F > iptables -t mangle -F > iptables -X > iptables -P INPUT ACCEPT > iptables -P FORWARD ACCEPT > iptables -P OUTPUT ACCEPT > masquerade enabled > iptables -t nat -A POSTROUTING -o "${OUTIF}" -j MASQUERADE > * configure outif (the thing which has globally routable address) > * enable wired connection between net and mesh by adding them to the same > subnet (eth0 on net 192.168.1.1, eth0 on mesh 192.168.1.2) > * Try to ping each other > * test if connection between net and internet works flawless > * test if connection between mesh and indirectly to the internet over net > works flawless > * set mtu of eth0 on both sides to 1530 > * check if `ping -M do -s 1500` works between both net and mesh > * remove ip addresses of eth0 on both ends (but keep devices up) > * add eth0 on both sides using `batctl if add` to bat0 > * set mtu of bat0 to 1500 on both hosts > * give bat0 the same ips which were used before by eth0 > * set bat0 up > * check if both hosts finds each other using `batctl o` > * try to ping other host > * try if internet works flawless indirectly from mesh over net > * remove ip from bat0 devices > * add bat0 to a bridge on both ends > * set ips which were used by bat0 to the bridge devices > * set mtu of bridge to 1500 > * try to.... I think you can guess the next 1000 steps by yourself > > Regards, > Sven ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2010-08-23 7:05 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.375.1281525844.17951.b.a.t.m.a.n@lists.open-mesh.org>
[not found] ` <AANLkTim-RfupM1iHH-dFwtDiN5RLFVaP=AWK9=MH-dGK@mail.gmail.com>
2010-08-11 11:48 ` [B.A.T.M.A.N.] Nat Question David Beaumont
[not found] ` <AANLkTinhcpamuMGApH9D5SPn3VNkEi9BDCYwGkRcDdJq@mail.gmail.com>
2010-08-11 12:50 ` David Beaumont
2010-08-12 9:31 ` Marek Lindner
2010-08-12 9:38 ` David Beaumont
2010-08-12 9:50 ` Sven Eckelmann
2010-08-12 10:11 ` David Beaumont
2010-08-12 10:16 ` David Beaumont
2010-08-12 10:33 ` Marek Lindner
2010-08-12 10:41 ` David Beaumont
2010-08-12 10:50 ` Marek Lindner
2010-08-12 11:08 ` David Beaumont
2010-08-12 11:29 ` Sven Eckelmann
2010-08-12 11:41 ` David Beaumont
2010-08-12 13:14 ` David Beaumont
2010-08-12 13:19 ` Marek Lindner
2010-08-12 13:26 ` David Beaumont
2010-08-12 13:27 ` David Beaumont
2010-08-13 5:45 ` David Beaumont
2010-08-14 14:46 ` Marek Lindner
2010-08-16 13:11 ` David Beaumont
2010-08-16 16:32 ` Sven Eckelmann
2010-08-17 8:14 ` David Beaumont
2010-08-20 9:53 ` David Beaumont
2010-08-20 9:57 ` David Beaumont
2010-08-20 9:58 ` David Beaumont
2010-08-20 11:27 ` Sven Eckelmann
2010-08-23 7:05 ` David Beaumont
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox