* [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
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.