AW: [B.A.T.M.A.N.] wrong ip rules

AW: [B.A.T.M.A.N.] wrong ip rules

[Marek Lindner]

Hi,


> 6598:   from all to 104.0.0.0/8 lookup olsr
> 6599:   from 104.0.0.0/8 lookup olsr

> 6598:   from all to 104.0.0.0/8 lookup olsr
> 6599:   from 104.0.0.0/8 lookup olsr

> 6802:   from 104.0.0.0/8 lookup 68

> batmand delete olsr-rules and set "from 104.0.0.0/8 lookup 68"!?

which olsr-rules are deleted ? I can't see a difference there.

In table 68 is the batman default route. All interfaces not controlled
by batmand are routed towards this routing table. If you don't want
that OLSR traffic is routed into the batman default route you have
2 choices:
- You deleted the OLSR rules after each batmand start (hackish).
- You use the --no-policy-routing option and set all rules by 
yourself. This option allows a tight integration into a firmware and
full control of the policy routing.

Why does batmand not recognize OLSR interfaces and 
ignores them ? We simply could not find a good solution for
this kind of detection but we are open to suggestions.  ;-)

Greetings,
Marek






       __________________________________ Ihr erstes Fernweh? Wo gibt es den schönsten Strand? www.yahoo.de/clever

Re: AW: [B.A.T.M.A.N.] wrong ip rules

[Aaron Kaplan]

On Nov 14, 2007, at 8:30 AM, Marek Lindner wrote:

>
> Why does batmand not recognize OLSR interfaces and
> ignores them ? We simply could not find a good solution for
> this kind of detection but we are open to suggestions.  ;-)


parse /etc/olsrd.conf?

Re: AW: [B.A.T.M.A.N.] wrong ip rules / tunnel crashes

[tetzlav]

Marek Lindner schrieb:
>> batmand delete olsr-rules and set "from 104.0.0.0/8 lookup 68"!?
>>     
>
> which olsr-rules are deleted ? I can't see a difference there.
>   

Sorry, my fault - I should open my eyes:
at first look i thought batmand deleted the "from all to 104.0.0.0/8
lookup olsr" set.

> 2 choices:
> - You deleted the OLSR rules after each batmand start (hackish).
> - You use the --no-policy-routing option and set all rules by 
> yourself. This option allows a tight integration into a firmware and
> full control of the policy routing.
>   

ok ;)

after a small&dirty hack in batman-startscript
olsrd+batman+gatewaytunnel working:

--- 8< ---
        # policy-routing workaround for olsr ip-rules
        if [ "$gw_choose" != 0 -o -n "$gw_tunnel" ] && [ "$(nvram get
ff_policyrt)" = 1 ]; then
            echo -e "\nWorkaround to prevent conflicts between
olsrd/batmand"
            # eval $(/usr/bin/netparam)    # allready done

            for dev in WIFI LAN WAN; do   
                # needs consistent '$dev_proto=olsr' for olsr-devices
                # (unfortunately not any more in ff-v1.6.x)

                if [ "$(eval 'echo ${'$dev'OLSR}')" = 1 ]; then
                    OLSRNET="$(eval 'echo ${'$dev'NET}')/$(eval 'echo
${'$dev'PRE}')"

                    echo "* deleting all batmand ip rules 'from $OLSRNET
lookup 68'"
                    while ip rule del from $OLSRNET lookup 68
2>/dev/null; do :; done

                    echo "* set ip rule 'from $OLSRNET lookup olsr prio
6800'"
                    ip rule add from $OLSRNET lookup olsr prio 6800
                    echo "ip rule del from $OLSRNET lookup olsr prio
6800" >> $IF_LOCK
                fi
            done
            echo
        fi
--- >8 ---


but i noticed that the gatewaytunnel crashes somtimes if a package with
wrong source-adress comes along:

(client)
root@17-3:~# tcpdump -ni gate0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back
to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gate0, link-type LINUX_SLL (Linux cooked), capture size 96
bytes
01:31:01.584874 IP 169.254.0.2.1024 > 88.198.178.18.53:  43979+[|domain]
01:31:01.670353 IP 88.198.178.18.53 > 169.254.0.2.1024:  43979[|domain]
01:32:01.580469 IP 169.254.0.2.1024 > 88.198.178.18.53:  62407+[|domain]
01:32:01.641472 IP 88.198.178.18.53 > 169.254.0.2.1024:  62407[|domain]
01:32:20.330535 IP 104.61.17.3.41155 > 134.109.133.25.143: P
4242585185:4242585222(37) ack 1209814060 win 2003 <nop,nop,timestamp
165019315 636115595>
01:32:20.331694 IP 104.61.17.3.41156 > 134.109.133.25.143: P
4243816576:4243816613(37) ack 373738705 win 1413 <nop,nop,timestamp
165019315 636115598>
01:32:20.334014 IP 104.61.17.3.49819 > 88.198.44.10.993: P
4250143974:4250144011(37) ack 2087267410 win 2003 <nop,nop,timestamp
165019316 1323419075>
tcpdump: pcap_loop: recvfrom: Network is down
30 packets captured
63 packets received by filter
0 packets dropped by kernel


(gateway)
root@17-35:~# batmand -cd3
[...]
Gateway - assigned 169.254.0.2 to client: 105.61.17.3
Gateway - assigned 169.254.0.2 to client: 105.61.17.3
Gateway - assigned 169.254.0.2 to client: 105.61.17.3
Deleting route to 105.61.17.32/32 via 105.61.89.90 (table 66 - vlan1:bat)
Adding route to 105.61.17.32/32 via 105.61.89.92 (table 66 - vlan1:bat)
Deleting route to 105.61.17.17/32 via 105.61.89.90 (table 66 - vlan1:bat)
Adding route to 105.61.17.17/32 via 105.61.89.92 (table 66 - vlan1:bat)
Gateway - assigned 169.254.0.1 to client: 105.61.89.90
Deleting route to 105.61.17.17/32 via 105.61.89.92 (table 66 - vlan1:bat)
Adding route to 105.61.17.17/32 via 105.61.89.90 (table 66 - vlan1:bat)
Gateway - assigned 169.254.0.1 to client: 105.61.89.90
Deleting route to 105.61.17.19/32 via 105.61.89.90 (table 66 - vlan1:bat)
Adding route to 105.61.17.19/32 via 105.61.89.92 (table 66 - vlan1:bat)
Deleting route to 105.61.17.19/32 via 105.61.89.92 (table 66 - vlan1:bat)
Adding route to 105.61.17.19/32 via 105.61.89.90 (table 66 - vlan1:bat)
Gateway - assigned 169.254.0.2 to client: 105.61.17.3
Deleting route to 105.61.17.32/32 via 105.61.89.92 (table 66 - vlan1:bat)
Adding route to 105.61.17.32/32 via 105.61.89.90 (table 66 - vlan1:bat)
Gateway - assigned 169.254.0.1 to client: 105.61.89.90
Gateway - assigned 169.254.0.1 to client: 105.61.89.90
Gateway - assigned 169.254.0.1 to client: 105.61.89.90
Gateway - assigned 169.254.0.1 to client: 105.61.89.90
Unix socket: got connection
Unix client closed connection ...

root@17-35:~# logread
[...]
Nov 14 15:35:37 (none) daemon.err batmand[30596]: Error - can't delete
route to 105.61.17.17/32 via 105.61.89.90 (table 66): No such process
Nov 14 15:38:14 (none) daemon.err batmand[30596]: Error - can't delete
route to 105.61.17.32/32 via 105.61.89.90 (table 66): No such process
Nov 14 15:40:09 (none) daemon.err batmand[30604]: Error - got packet
from unknown client: 105.61.17.3 (virtual ip 104.61.17.3) 
Nov 14 15:40:09 (none) daemon.err batmand[30604]: Error - got packet
from unknown client: 105.61.17.3 (virtual ip 104.61.17.3) 
Nov 14 15:40:10 (none) daemon.err batmand[30604]: Error - got packet
from unknown client: 105.61.17.3 (virtual ip 104.61.17.3) 
Nov 14 15:40:11 (none) daemon.err batmand[30604]: Error - got packet
from unknown client: 105.61.17.3 (virtual ip 104.61.17.3)


Regards
tetzlav

Re: AW: [B.A.T.M.A.N.] wrong ip rules

[tetzlav]

Aaron Kaplan schrieb:
> On Nov 14, 2007, at 8:30 AM, Marek Lindner wrote:
>
>> Why does batmand not recognize OLSR interfaces and
>> ignores them ? We simply could not find a good solution for
>> this kind of detection but we are open to suggestions.  ;-)
>
>
> parse /etc/olsrd.conf? 

This is dirty and not generic enough.
Batmand is IP-based/layer3, so why not bind batmand to IPs (optional)
instead of interfaces!?
(like olsrd)


my 0,02€
tetzlav

Re: AW: [B.A.T.M.A.N.] wrong ip rules

[Marek Lindner]

> > parse /etc/olsrd.conf?
>
> This is dirty and not generic enough.

I agree.

> Batmand is IP-based/layer3, so why not bind batmand to IPs (optional)
> instead of interfaces!?
> (like olsrd)

I don't understand how this is going to help us here. 
By the way: batmand binds to IPs ...


Greetings,
Marek

[B.A.T.M.A.N.] batman 0.3 and batmand-exp-0.3

[Predrag Balorda]

I have been using the exp branch for over 2 weeks now and it is working nicely. OK my set-up is not huge, only 4 batman-enabled nodes with additional 6 repeaters as clients to batman nodes. Now I would like to know when will someone decide to kill off the 0.3 beta and continue with exp 0.3 as the only batman? Maybe it's time to name it batman 0.4 and get rid of the "experimental" designation altogether (you even got the official ports)?

I even believe exp can be now released as another stable version.

Best regards to everyone on the list,

Pele

Re: [B.A.T.M.A.N.] batman 0.3 and batmand-exp-0.3

[Axel Neumann]

Hello,

sounds like you made some good experience with the batman-exp branch. Thats 
really cheering to hear. Just, let me add some words regarding your 
understanding of the different branches.

batman-exp has started as a branch to make batman more configurable - e.g give 
the user more control about the system integration and even twist the core 
routing algorithm.  
Of course more flexibility also tends to make things more complex.
The majority of the developers did not wanted to have the bunch of optional  
configuration options in the standard batman branch, thats why these features 
were realized in a different branch. 

Particularly its possibility to experiment with the core routing metrics has 
lead to the extension "-experimental". Unfortunately, this has caused some 
people to think that the maturity of batman-exp is less advanced than the 
standard branch. This is NOT the idea, nor is it the other way around. Just 
two different branches, supposed to coexist and enrich each other.

Of course such a biased opinion tends to hurt a bit, and for the release I am 
already considering to rename it to something like -x or -exp. So it may 
considered as batman experimental, expert, extremely professional, or what so 
ever. But anyway, its just a name.


Approximately since the release of batman-0.3-alpha we have started to develop 
some new mechanisms to make the core routing algorithm more aware of 
asymmetric links and other stuff. And we had two different ideas to achieve 
this. It turned out, that one approach was implemented in the standard branch 
and the other one in the exp branch. 

I think that both approaches definitively have their charm and their 
shortcomings. And it requires the feedback of the users to further trigger 
the evolution of these approaches. I am very grateful for that and any other 
feedback, criticism, bug report, etc.

Regarding the versioning (0.3/0.4/apha/beta/rc1...). exp 0.3-alpha might be a 
bit conservative. However, there is a very small list of other features on my 
todo list which i would like to add before the code is freezed.

thanks,
axel


On Mittwoch 21 November 2007, Predrag Balorda wrote:
> I have been using the exp branch for over 2 weeks now and it is working
> nicely. OK my set-up is not huge, only 4 batman-enabled nodes with
> additional 6 repeaters as clients to batman nodes. Now I would like to know
> when will someone decide to kill off the 0.3 beta and continue with exp 0.3
> as the only batman? Maybe it's time to name it batman 0.4 and get rid of
> the "experimental" designation altogether (you even got the official
> ports)?
>
> I even believe exp can be now released as another stable version.
>
> Best regards to everyone on the list,
>
> Pele
>
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n