14 Nov
2007
14 Nov
'07
7:30 a.m.
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
4:08 p.m.
Aaron Kaplan schrieb:
On Nov 14, 2007, at 8:30 AM, Marek Lindner wrote:
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
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?
20 Nov
20 Nov
4:33 p.m.
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)
I don't understand how this is going to help us here.
By the way: batmand binds to IPs ...
Greetings,
Marek
21 Nov
21 Nov
3:20 p.m.
New subject: [B.A.T.M.A.N.] batman 0.3 and batmand-exp-0.3
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
8 p.m.
New subject: [B.A.T.M.A.N.] batman 0.3 and batmand-exp-0.3
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(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
14 Nov
14 Nov
2:49 p.m.
New subject: AW: [B.A.T.M.A.N.] wrong ip rules / tunnel crashes
Marek Lindner schrieb:
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.
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.
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
5602
days inactive
5609
days old
b.a.t.m.a.n@lists.open-mesh.org
6 comments
5 participants
participants (5)
-
Aaron Kaplan -
Axel Neumann -
Marek Lindner -
Predrag Balorda -
tetzlav