Hi again,

the batmand-exp is still hanging. below you see the top output and the parameters of batmand or hna. I also include the network setup and some last connection states. Perhaps it has something to do with any of the options. I can not directly verify if any option is the reason for this hanging. batman is connected via wlan (eth1) and a backbone connection (tbb). I have two router WRT54GL and WRT54GS and a vserver (i386). I only have problems on WRT54GS. Perhaps it has something to do with "-r 1" option.

Setup:

WRT54GL(eth1=wlan)----(eth1=wlan)WRT54GS(tbb=vpn tunnel)----(tbb)vserver

The vserver has also an addtional connection to a different router via tbb. The parameters of batmand are:

WRT54GL: /sbin/batmand -s 10.12.0.1 -a 10.12.10.0/28 -r 2 --t 63 --no-unreachable-rule --no-throw-rules --no-prio-rules --one-way-tunnel 1 --two-way-tunnel 0 eth1 tbb /t 1 /i /A WRT54GS: /sbin/batmand -s 10.12.0.1 -a 10.12.10.16/28 -r 1 --t 63 --no-unreachable-rule --no-throw-rules --no-prio-rules --one-way-tunnel 1 --two-way-tunnel 0 eth1 tbb /t 1 /i /A vserver: /usr/bin/batmand -a 195.42.115.56/32 -a 104.61.0.0/16 -a 105.61.0.0/16 -a 106.61.0.0/16 -s 10.12.0.1 --no-unreachable-rule --no-throw-rules --no-prio-rules --one-way-tunnel 1 --two-way-tunnel 0 wifi tbb /t 1 /i /A

----------- Another question: in previous versions I have seen that if two batmand announce the same HNA ip (-a) one of the batmand are ignored and complete ignored any batmand traffic. As result the node was removed from any batmand list and was not reachable anymore. -----------

top: --------------------- Mem: 15832K used, 14792K free, 0K shrd, 1440K buff, 5972K cached CPU: 0.0% usr 100% sys 0.0% nice 0.0% idle 0.0% io 0.0% irq 0.0% softirq Load average: 1.00 0.97 0.92 PID PPID USER STAT VSZ %MEM %CPU COMMAND 8380 1816 root R 1232 4.0 80.7 /sbin/batmand -s 10.12.0.1 -a 10.12.10.16/28 -r 1 --t 63 --no-unreachable-rule --no-throw-rules --no-prio-rules --one-way-tunnel 1 --two-way-tunnel 0 eth1 tbb /t 1 /i /A 1151 1 root S 1232 4.0 0.0 /sbin/batmand -s 10.12.0.1 -a 10.12.10.16/28 -r 1 --t 63 --no-unreachable-rule --no-throw-rules --no-prio-rules --one-way-tunnel 1 --two-way-tunnel 0 eth1 tbb /t 1 /i /A 1816 1151 root S 1232 4.0 0.0 /sbin/batmand -s 10.12.0.1 -a 10.12.10.16/28 -r 1 --t 63 --no-unreachable-rule --no-throw-rules --no-prio-rules --one-way-tunnel 1 --two-way-tunnel 0 eth1 tbb /t 1 /i /A 23934 23892 root S 1184 3.8 0.0 batmand -c -b -r 1 32567 32525 root S 1184 3.8 0.0 batmand -c -b -r 1 9105 9063 root S 1184 3.8 0.0 batmand -c -b -r 1 3421 3379 root S 1184 3.8 0.0 batmand -c -b -r 1 9038 9036 root S 1184 3.8 0.0 batmand -cb -d2 12030 11988 root S 1184 3.8 0.0 batmand -c -b -r 1 20666 20624 root S 1184 3.8 0.0 batmand -c -b -r 1

Last connection output from batmand: --------------------------- BatMan-eXp 0.3-alpha (compatibility version 10) ! BatMan-eXp 0.3-alpha, IF eth1 10.12.10.17, LinkWindowSize 100, PathWindSize 100, OGI 1000ms, currSeqno 34756, UT 0:07:12:09, CPU 3/1000, IntTime 25929690 Neighbor outgoingIF bestNextHop brc (~rcvd knownSince lseq lvld rid nid ) [ viaIF RTQ RQ TQ].. 10.12.10.1 eth1 10.12.10.1 87 ( 100 0:00:57:20 43345 0 1 1 ) [ eth1 79 100 79] 172.16.8.1 tbb 172.16.8.1 100 ( 99 0:00:56:50 18597 0 2 2 ) [ tbb 100 100 100] 172.16.0.1 tbb 172.16.0.1 100 ( 99 0:00:56:50 39090 0 1 3 ) [ tbb 100 100 100] 172.16.0.17 tbb 172.16.0.17 100 ( 99 0:00:56:49 10460 0 1 4 ) [ tbb 100 100 100]

Originator outgoingIF bestNextHop brc (~rcvd knownSince lseq lvld pws ogi cpu hop change ) alternativeNextHops brc ... 10.12.0.1 tbb 172.16.0.1 100 ( 99 0:00:56:48 39090 0 100 1015 1 1 5 ) 172.16.0.17 98 172.16.8.1 98 10.12.0.17 tbb 172.16.0.17 100 ( 99 0:00:56:48 10460 0 100 1008 3 1 11 ) 172.16.0.1 96 172.16.8.1 98 10.12.10.1 eth1 10.12.10.1 87 ( 100 0:00:57:20 43345 0 100 1008 1 -12 1 ) 172.16.0.17 0 172.16.0.1 0 10.12.8.1 tbb 172.16.8.1 99 ( 99 0:00:56:48 18597 0 100 1006 0 -12 29 ) 172.16.0.1 96 172.16.0.17 95 4 known Originator(s), averages: 96 ( 99 0 100 1009 1 -5 11 )

Last hna output -------------------- BatMan-eXp 0.3-alpha (compatibility version 10) ! Originator Announced networks HNAs: network/netmask or interface/IF (B:blocked)... 10.12.0.1 195.42.115.56/32 104.61.0.0/16 105.61.0.0/16 106.61.0.0/16 172.16.0.1/IF 194.26.180.0/24 77.87.48.0/21 10.2.0.0/16 191.161.0.0/16 104.32.0.0/12 104.0.0.0/11 104.64.0.0/10 104.128.0.0/ 9 10.126.0.0/16 10.124.0.0/15 10.120.0.0/14 10.112.0.0/13 10.12.0.17 172.16.0.17/IF 10.12.10.1 10.12.10.0/28 172.16.10.1/IF 10.12.8.1 10.12.8.0/28 172.16.8.1/IF

last service output: ------------------- BatMan-eXp 0.3-alpha (compatibility version 10) ! Originator Announced services ip:port:seqno ... 10.12.0.1 104.61.79.20:80:1 104.61.119.111:21:1 104.61.119.222:21:1 104.61.232.34:80:1 104.61.230.188:80:1 104.61.230.193:80:1

ip addr: ------------- 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:13:10:30:00:fd brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:13:10:30:00:ff brd ff:ff:ff:ff:ff:ff inet 10.12.10.17/8 brd 10.255.255.255 scope global eth1 4: br0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue link/ether 00:13:10:30:00:fd brd ff:ff:ff:ff:ff:ff inet 192.168.1.4/24 brd 192.168.1.255 scope global br0 5: vlan0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue link/ether 00:13:10:30:00:fd brd ff:ff:ff:ff:ff:ff 6: vlan1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue link/ether 00:13:10:30:00:fd brd ff:ff:ff:ff:ff:ff inet 192.168.178.25/24 brd 192.168.178.255 scope global vlan1 7: tbb: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue link/ether 00:ff:15:bf:0b:c0 brd ff:ff:ff:ff:ff:ff inet 172.16.10.17/16 brd 172.16.255.255 scope global tbb 17: tap1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:ff:50:70:1e:1d brd ff:ff:ff:ff:ff:ff 154: bat0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1471 qdisc pfifo_fast qlen 10 link/[65534] inet 10.12.10.17/32 scope global bat0 155: tap0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:ff:15:bf:0b:c0 brd ff:ff:ff:ff:ff:ff

bridges: -------------- bridge name bridge id STP enabled interfaces br0 8000.0013103000fd no vlan0 tap1 tbb 8000.00ff15bf0bc0 yes tap0

/stephan

--------------------------------------- Dipl.Informatiker(FH) Stephan Enderlein Freifunk Dresden

Hi,

On Dienstag 09 Dezember 2008, Stephan Enderlein (Freifunk Dresden) wrote:

---

Another question: in previous versions I have seen that if two batmand announce the same HNA ip (-a) one of the batmand are ignored and complete ignored any batmand traffic. As result the node was removed from any batmand list and was not reachable anymore.

---

And it should be also the current behavior of bmx. The background is:

BMX currently does NOT support anycast routing.

Therefore in practical terms, if two nodes are announcing the same IP it is effectively an IP doubler. Such a scenario triggers the dublicate-address detection which results in ignoring the younger of the two nodes announcing this IP.

With the batman routing algorithm it is indeed difficult to do a consistent anycast routing. Therefore I've decided to protect against casual duplicate address announcements with the described behavior. Older versions (2007 and before) tended to have chaotic routing entries due to duplicated entries or removals of HNA routing entries.

When dynamically adding an HNA (using e.g. bmxd -ca 1.2.3.4/32) the daemon checks if other nodes are already announcing this specific HNA. If this is the case the announcement is rejected and a warning should be given in debuglevel 3. You can always inspect current announcements from other nodes using debug-level 9. This debug-level also differentiates between announced interfaces (e.g. 1.2.3.4/IF) and networks (e.g. 1.2.3.4/32). ( the idea for the future was, that network announcements should become anycast announcements )

Indeed it is a problem when a daemon is started from the beginning with a duplicate HNA announcement. In this situation the daemon can hardly check if the network is already announced. Then, only his neighboring nodes are aware of the IP doubler. They will ignore everything from this node and cause a warning in debug level 0.

hope this clarifies a bit.

/axel

Hi, On Donnerstag 11 Dezember 2008, Freifunk wrote:

Hi Axel,

thanks for your description. Would it be better to only ignore the HNA that is already received from another node instead of ignoring the node completely?

Sounds reasonable. What were the consideratios from those days - there were a number of reasons for the current approach but meanwhile some things have changed.

1. The hope to find a consistent anycast routing approach soon which would eliminate the duplicate HNA problem.

2. Secondary interfaces were conceptually announced in the same way as HNAs. The signaling of secondary-interface information to all other nodes was essential for many scenarios. This is because traffic originated and leaving the node via a secondary interface usually had the ip address of the secondary interface as src-address. Though, corresponding nodes could not reply if not having a correct HNA route to the originating src. This has changed some time ago. Now the bmx daemon sets the ip of the primary interface as preferred src address for all interfaces, making the interface announcement non-obligatory. You can see this by looking at the default bmx routing table ip r ls t 64 which should always show the primary-interface ip as src address.

3. I think there were theoretical scenarios for routing loops if the routing entries in different nodes for a given HNAs point to different destination nodes. But currently I can not remember.

so far, /axel

I currently use one node that is connected to icvpn (inter-city vpn) that connects different freifunk cities together. The network runs bgp and allows to setup a second server that also initiates a connection to the icvpn. both server would then announce the same ip addresses. In this case the batman notes only should ignore the HNA if they are injected by different icvpn servers and keep the server still in network.

Bye stephan

Axel Neumann schrieb:

...

Hi,

On Dienstag 09 Dezember 2008, Stephan Enderlein (Freifunk Dresden) wrote:

...

---

Another question: in previous versions I have seen that if two batmand announce the same HNA ip (-a) one of the batmand are ignored and complete ignored any batmand traffic. As result the node was removed from any batmand list and was not reachable anymore.

---

And it should be also the current behavior of bmx. The background is:

BMX currently does NOT support anycast routing.

Therefore in practical terms, if two nodes are announcing the same IP it is effectively an IP doubler. Such a scenario triggers the dublicate-address detection which results in ignoring the younger of the two nodes announcing this IP.

With the batman routing algorithm it is indeed difficult to do a consistent anycast routing. Therefore I've decided to protect against casual duplicate address announcements with the described behavior. Older versions (2007 and before) tended to have chaotic routing entries due to duplicated entries or removals of HNA routing entries.

When dynamically adding an HNA (using e.g. bmxd -ca 1.2.3.4/32) the daemon checks if other nodes are already announcing this specific HNA. If this is the case the announcement is rejected and a warning should be given in debuglevel 3. You can always inspect current announcements from other nodes using debug-level 9. This debug-level also differentiates between announced interfaces (e.g. 1.2.3.4/IF) and networks (e.g. 1.2.3.4/32). ( the idea for the future was, that network announcements should become anycast announcements )

Indeed it is a problem when a daemon is started from the beginning with a duplicate HNA announcement. In this situation the daemon can hardly check if the network is already announced. Then, only his neighboring nodes are aware of the IP doubler. They will ignore everything from this node and cause a warning in debug level 0.

hope this clarifies a bit.

/axel _______________________________________________ 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

---

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

Hi,

On Samstag 13 Dezember 2008, Stephan Enderlein (Freifunk Dresden) wrote:

Hi,

I'm not so deep involved in batman routing to find a solution. I hope you can find a way. But for now it is not so important. But if one node announces a HNA and a different node that just has fun to "turn off" this node can simply send the same HNA. If you say the first HNA is the right one, then what happens when this node gets the forced disconnection after 24 hours by its internet provider?

Theoretically, if the node can reestablish a new connection after its forced disconnection within the dad timeout (100secs by default) then it should not be kicked out. But, the preliminary for this is that: the node must re-appear using the same primary IP for its primary interface and continuing with the foreseen sequence-number range.

best, axel

I think it is difficult to find a solution for this. The best is to keep all nodes active but kill the HNA if not reachable?

/Stephan

---

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

HI,

I like brainstorming like this. We wanted batmand (and especially its core routing algorithm) to be decentral and simple. So no central point of control/failure and therefore also no HNA server. Of course there are many potential attack vectors in a community mesh and probably there will always be until you completely restrict the access. Therefore IMHO the preferable security to be solved should be:

- detect and protect against (usually accidental) misconfigurations like duplicate addresses.

- find mechanisms to limit the impact of denial of service or other attacks to the local environment (neighborhood).

Certificates and signatures might be a theoretical solution. I am not a security expert but many people have stated that frequent signature validation (like every OGM) will definitely exceed the cpu performance of the small embedded devices we use for our networks.

On Donnerstag 18 Dezember 2008, Stephan Enderlein (Freifunk Dresden) wrote:

...

Theoretically, if the node can reestablish a new connection after its forced disconnection within the dad timeout (100secs by default) then it should not be kicked out. But, the preliminary for this is that: the node must re-appear using the same primary IP for its primary interface and continuing with the foreseen sequence-number range.

The router always will have the same IP. But it can take a little time to establish the vpn connection (over internet) to connect to other batman clouds. So it is possible that the 100 seconds are reached easily. At moment the firmware has no way to set the time of the forced disconnection. But If the user are using a different router or the firmware will later support a timed disconnection, it is possible that user leave the default time. Assuming this other may connect there disturbing routers at same time to turn off attractive nodes with many connections.

You can tweak the dulicate address timeout detection using --dad-timeout .

Because the duplicate address detection is working based on expected sequence numbers you can avoid being ignored by other nodes after a restart by correcting your initial sequence number to a number accepted by other nodes using --initial-seqno.

ciao, axel

All nodes must be reachable and they must ping the hna regulary (if ping is supported or check for certain services) and tell the local batmand to remove a specific hna from its internal list. But this is also not secure because the bad guy may redirect such requests and pretend the IP is reachable.

I think there must be a central server that collects "HNA requests" if they are valid, the batman node that has requested to propagate a HNA can add it. For this batman should support such a procedure internally perhaps like the visualisation server, else the bad guy may simply add hna per command line. It should be possible to generate two versions of batmand, one that acts as HNA server (only few authenticated servers) and one as HNA client (requesting to publish HNA and build in in all nodes).

To avoid running a faked batmand client to disturb a mesh, batman should support certificates to protect its OGM and other packets. Is there a way to make a batman network unique by using certificates? batman should always send signed OGM and other batman packets and also check for the correctness on receiption.

For HNA authentication and signed batman traffic you may use cacert.org. If someone then tries to disturb a batman network by setting up its own HNA server, you just may look into the certificate to get the user.

Cheers Stephan

---

Dipl.Informatiker(FH) Stephan Enderlein Freifunk Dresden

---

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

Hi again,

is there a way to set a TTL value for each hna that is different from OGM TTL? If I assume that an HNA internet host is reachable via two nodes (e.g. running icvpn - bgp) batmand currently ignores one of this hna and also the node and its traffic (right?).

What if we use the ttl value as metric to decide which hna is used? In this case both nodes are still present in network but you don't have a address conflict. Batman should not accept HNA that belongs to the ipranges of the batman network. So a node with ip 10.12.0.1 can not send a HNA with 10.12.10.17 and disturbing the routing. Perhaps batmand already checks this?

/stephan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Axel Neumann schrieb:

HI,

I like brainstorming like this. We wanted batmand (and especially its core routing algorithm) to be decentral and simple. So no central point of control/failure and therefore also no HNA server. Of course there are many potential attack vectors in a community mesh and probably there will always be until you completely restrict the access. Therefore IMHO the preferable security to be solved should be:

• detect and protect against (usually accidental) misconfigurations like

duplicate addresses.

sure, a duplicate address is something the routingprotocoll has to detect and to react on, but: duplicate HNA are very importand and widely accepted in the internet community, they are called anycast and are a vital instrument in network design and deployment.

as an example, anycast ist used for dns root servers, 6to4 tunnel and many other usecases.

i am still not understanding why you are discussing about removing such important thing as anycast.

anycast is a way to use distributed services, as you can announce an anycast address on every node, providing a specific service and packets will get routed to the nearest service provider.

• find mechanisms to limit the impact of denial of service or other attacks to

the local environment (neighborhood).

<removed>

Gruss, Alex

Hiii,

I'm a beginner regarding mesh networks. At the moment, I have a problem by building a mesh network with batman between 2 Linksys and a Laptop. I get a ping response on the router side and from my Laptop side. There is a connection... ok..

But I can't run batmand to establish a mesh network...

I gave the command" sudo batmand eth1 wlan0:test" to build the connection and then this here"sudo batmand -c -d 1" but the second command gives this error message: "Error - can't connect to unix socket '/var/run/batmand.socket': No such file or directory ! Is batmand running on this host ?"

My batman version is" B.A.T.M.A.N. 0.2 (compability version 3)"

Can anybody help me to fix this problem ?

greetings, R

Hi -

sure, we have. Ad-Hoc mode of 802.11 is broken by design. Keywords: IBSS merges and time stamps in beacons. There are some hacks which work exclusively for the Madwifi driver with the patches of a recent Openwrt Kamikaze developer version. You can use the ad-hoc demo mode or 'real' IBSS mode with the option "nosbeacon" when creating the VAP with

"wlanconfig ath0 create wlandev wifi0 wlanmode adhoc nosbeacon"

This is the only option for a PC at the moment. Works rock solid even in the Berlin Freifunk mesh with ~500 ad-hoc interfaces where MAC timestamps permanently jump back and forth.

Closed source binary driver for Linux 2.4 for Broadcom also works - mostly, there have been reports about issues in conjuction with patched Madwifi versions (software generated timestamps are not precise enough and can confuse the Broadcom driver) These issues can be avoided by using ah-demo mode where you fix the IBSS-ID.

Cheers, elektra

Has anybody experience with this issue...

Greetings, R

...

Hiii,

I'm a beginner regarding mesh networks. At the moment, I have a problem by building a mesh network with batman between 2 Linksys and a Laptop. I get a ping response on the router side and from my Laptop side. There is a connection... ok..

But I can't run batmand to establish a mesh network...

I gave the command" sudo batmand eth1 wlan0:test" to build the connection and then this here"sudo batmand -c -d 1" but the second command gives this error message: "Error - can't connect to unix socket '/var/run/batmand.socket': No such file or directory ! Is batmand running on this host ?"

My batman version is" B.A.T.M.A.N. 0.2 (compability version 3)"

Can anybody help me to fix this problem ?

greetings, R

---

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

---

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