All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Rack <michael.rack@rsm-freilassing.de>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.net>
Subject: Re: [B.A.T.M.A.N.] Problems with Gateway-Selection without option -g
Date: Mon, 07 Sep 2009 15:40:48 +0200	[thread overview]
Message-ID: <4AA50D60.9050605@rsm-freilassing.de> (raw)
In-Reply-To: <200909072102.57854.lindner_marek@yahoo.de>

[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

Am 07.09.2009 15:02, schrieb Marek Lindner:
> And what is the MTU of the interface batman is running on ?
>
> Did the iptables command I posted help you to fix your MSS problem ?
>
>    
The interface where batman is running on have MTU 1460 (Standard 
Ethernet - UDP VPN Overload) on HOST #1.
The interface where batman is running on have MTU 1500 (Standard 
Ethernet) on HOST #2.
Yes, the iptables-command does the trick for me. This iptalbes-filter 
was known before. I added the filter to the mangle-table as the problem 
occurs.

My Root-Server (HOST #1) is located at Nuernberg, DE and have access to 
the internet with a public ip-space /22 that allocated to me. HOST #2 is 
connected to an lowcost ISP-Provider with 30MBits / 2MBits. HOST #2 is 
connected by VPN with HOST #1 to route the public ip-addresses.
>> IP-Host #1: 123.205.12.0 / 32
>> IP-Host #2: 123.205.12.4 / 32
>>
>> IP RULES ON "HOST #2":
>> ~ $ /sbin/ip rule show
>> 6600:    to 123.205.12.4 lookup batman_hosts [66]
>> 6601:    from all lookup batman_networks [65]
>> 6700:    to 123.205.12.4 lookup batman_unreach [67]
>>
>> Host #1 (123.205.12.0) is in the routingtable of batman_hosts [66].
>>
>> But i can not ping 123.205.12.0, because the kernel will not enter the
>> rule 6600.
>>
>> When i configure my Host #2 to a /24 network, all went fine. Then the
>> rule will setuped as follow:
>>
>> 6600:    to 123.205.12.4/24 lookup batman_hosts [66]
>>      
> Ok, I see your problem. Batman could easily detect whether the host is part of
> any existing network and if not modify the routing rules. I see 2 options:
> * adding more rules to jump in table 66
> * adding the node to table 65 instead of 66
>    
Correct. I've added some rules with "to any", and this does the trick. 
In addition i use my own policy-routing-script, because the "throw" 
event makes the routing-table a little fuzzy. Now i have only two 
routing-tables "batman_hosts" and "batman_networks". In my 
policy-routing-script i do the seperation between both tables.
> What did you do to make it work ?
>    
My policy-routing-script is attached.

Michael.


[-- Attachment #2: policy_routing_script.sh --]
[-- Type: text/plain, Size: 1421 bytes --]

#!/bin/sh
LOG_FILE="/var/log/batman-routing.log"
echo "" > $LOG_FILE
date=(/bin/date +"%Y-%m-%d %H:%M:%S")

while read method action mtype dst mask gw src_ip ifi_prio dev table
do
	if [ "$method" == "ROUTE" ]
	then
		if [ "$mtype" == "UNICAST" ]
		then
			if [ "$mask" == "32" -a "$table" == "66" ]
			then
				# HOST-Route
				if [ "$action" == "add" ]
				then
					if [ "$gw" == "$dst" ]
					then
						# DIRECT NEIGHBOUR
						/sbin/ip route add $dst src $src_ip dev $dev table $table
						echo "Add neighbour: $dst reached by $src_ip@$dev" >> $LOG_FILE
					else
						# TWO-HOP NEIGHBOUR
						/sbin/ip route add $dst/$mask via $gw src $src_ip dev $dev table $table
						echo "Add host: $dst via $gw reached by $src_ip@$dev" >> $LOG_FILE
					fi
				elif [ "$action" == "del" ]
				then
				# Remove a HOST-Route
					/sbin/ip route del $dst table $table
					echo "Delete neighbour: $dst" >> $LOG_FILE
				fi
			elif [ "$mask" != "32" -a "$table" == "65" ]
			then
				# NETWORK-Announcement
				if [ "$action" == "add" ]
				then
					# Add Network
					/sbin/ip route add $dst/$mask via $gw src $src_ip dev $dev table $table
					echo "Add network: $dst/$mask via $gw reached by $src_ip@$dev" >> $LOG_FILE
				elif [ "$action" == "del" ]
				then
					# Remove Network
					/sbin/ip route del $dst/$mask via $gw table $table
					echo "Add network: $dst/$mask via $gw" >> $LOG_FILE
				fi
			fi
		fi
	fi
done

  reply	other threads:[~2009-09-07 13:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-06  5:28 [B.A.T.M.A.N.] Problems with Gateway-Selection without option -g Michael Rack
2009-09-06 10:50 ` elektra
2009-09-06 11:33   ` Michael Rack
2009-09-06 12:37     ` elektra
2009-09-06 15:11 ` Marek Lindner
2009-09-06 17:13   ` Michael Rack
2009-09-06 17:47     ` Marek Lindner
2009-09-07 10:16       ` Michael Rack
2009-09-07 13:02         ` Marek Lindner
2009-09-07 13:40           ` Michael Rack [this message]
2009-09-08 17:57             ` Marek Lindner
2009-10-30 10:19               ` Michael Rack
2009-10-30 12:11                 ` elektra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AA50D60.9050605@rsm-freilassing.de \
    --to=michael.rack@rsm-freilassing.de \
    --cc=b.a.t.m.a.n@lists.open-mesh.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.