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
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
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
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
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
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
b.a.t.m.a.n@lists.open-mesh.org
-
Aaron Kaplan -
Axel Neumann -
Marek Lindner -
Predrag Balorda -
tetzlav