Hi all, i have strange problem with gatewat<>client setup as described here:
http://www.open-mesh.org/projects/batman-adv/wiki/Gateways
setup is simple
[dhcp server on bat0]<wired connection>[mesh node]<wireless connection>[client]
server configuration:
root@droch:~# ifconfig
bat0 Link encap:Ethernet HWaddr a2:a1:ff:98:cd:37
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5541 errors:0 dropped:0 overruns:0 frame:0
TX packets:3636 errors:0 dropped:20 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:506784 (494.9 KiB) TX bytes:364485 (355.9 KiB)
eth0 Link encap:Ethernet HWaddr 00:1d:09:36:96:84
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:20020 errors:0 dropped:0 overruns:0 frame:0
TX packets:12193 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1519028 (1.4 MiB) TX bytes:820498 (801.2 KiB)
Interrupt:16
root@droch:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 bat0
root@droch:~# batctl if
eth0: active
root@droch:~# batctl gw
server (announced bw: 1024MBit/1024MBit)
dhcp daemon (isc-dhcp-server 4.2.2) running on bat0
mesh node configuration:
ifconfig
bat0 Link encap:Ethernet HWaddr 12:cb:4a:61:c5:0c
inet addr:192.168.2.3 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:154 errors:0 dropped:0 overruns:0 frame:0
TX packets:101 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:14327 (13.9 KiB) TX bytes:14836 (14.4 KiB)
eth0 Link encap:Ethernet HWaddr 00:0d:b9:24:e3:44
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3626 errors:0 dropped:0 overruns:0 frame:0
TX packets:1898 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:232959 (227.4 KiB) TX bytes:84767 (82.7 KiB)
Interrupt:10 Base address:0x8000
wlan0 Link encap:Ethernet HWaddr 00:02:6f:b8:95:5e
UP BROADCAST RUNNING MULTICAST MTU:1528 Metric:1
RX packets:3539 errors:0 dropped:0 overruns:0 frame:0
TX packets:2134 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:161096 (157.3 KiB) TX bytes:173733 (169.6 KiB)
root@proto-3:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 bat0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 bat0
root@proto-3:~# batctl if
eth0: active
wlan0: active
root@proto-3:~# batctl gwl
Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.2.0, MainIF/MAC: eth0/00:0d:b9:24:e3:44 (bat0)]
00:1d:09:36:96:84 (255) 00:1d:09:36:96:84 [ eth0]: 119 - 1024MBit/1024MBit
client configuration:
ifconfig
bat0 Link encap:Ethernet HWaddr d6:50:dd:4d:54:75
inet addr:192.168.2.135 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::d450:ddff:fe4d:5475/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1664 errors:0 dropped:0 overruns:0 frame:0
TX packets:1728 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:174732 (170.6 KiB) TX bytes:170468 (166.4 KiB)
mp1 Link encap:Ethernet HWaddr 00:21:a4:35:36:26
UP BROADCAST RUNNING MULTICAST MTU:1528 Metric:1
RX packets:8248 errors:0 dropped:0 overruns:0 frame:0
TX packets:5910 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:477461 (466.2 KiB) TX bytes:560034 (546.9 KiB)
batctl if
mp1: active
batctl gwl
Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.2.0, MainIF/MAC: mp1/00:21:a4:35:36:26 (bat0)]
=> 00:1d:09:36:96:84 (225) 00:02:6f:b8:95:5e [ mp1]: 119 - 1024MBit/1024MBit
batctl gw
client (selection class: 20)
dhcp client is dhcpcd version 3.2.3.
In first step all work fine, bring up bat0 on client, bring up dhcp on it, it get ip address and work
fine. but if i just bring bat0 on client down then up it don't work, it see gateway, i see dhcp
request and replies on server on bat0, but on mesh node and client i don't see any reply in batctl tr
nor tcpdump and it stay in this state forever.
But, if i bring bat0 on client down, wait 200 seconds until client is removed from originators
on server by timeout and bring bat0 on client back up it starts working again and get ip from dhcp server.
On all batman nodes i use batman-adv version 2012.2.0.
C уважением With Best Regards
Георгиевский Юрий. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
факс +7 4872 711143 fax +7 4872 711143
Компания ООО "Ай Ти Сервис" IT Service Ltd
http://nkoort.ruhttp://nkoort.ru
JID: GHhost(a)icf.org.ru JID: GHhost(a)icf.org.ru
YG129-RIPE YG129-RIPE
Hello again,
can't determine exactly since when, but avahi is acting funny in
QuintanaLibre :(
two computers (pbx and veci) connected to different nodes in the mesh
can't always resolve hostnames through avahi
pbx ]=eth==[ nicoyjesi --> .. --> .. --> wlan1(czuk)wlan0 <-->
natychucho ]==eth=[ veci
(cf. attached dotgraph)
question from pbx is broadcasted perfectly and reaches veci,
veci replies, natychucho broadcasts the replly through wifi , gets to
czuk wlan0, but czuk doesn't re-broadcast it , silently dropping the
packet.
relevant tcpdump
http://pastebin.com/6xLmDqe5
you can see question coming in through czuk(wlan1), rebroadcasted
through czuk(wlan0), reach veci, veci reply, czuk(wlan0) gets reply,
but doesn't retransmit it through czuk(wlan1) :(
iptables @ czuk looks sane
http://pastebin.com/mFUFuNdC
## czuk has two wifi interfaces, both in ap mode, managed by batman
## natychucho is connected to wlan0 in client mode,
## and cisterna is client to wlan1. no WDS whatsoever.
root@czuk:~# batctl if
wlan0: active
wlan1: active
root@czuk:~# brctl show
bridge name bridge id STP enabled interfaces
br-lan 8000.54e6fcb98e2b no eth0
bat0
complete live config can be lurked in
https://bitbucket.org/nicoechaniz/quintanalibre-configs/src/d9bd3603824d/cz…
I don't find any reason batman would be involved in this, but iptables
is discarded as a suspect, and AFAICS there are no other factors
messing with the packets (maybe it's a bit late night :) ). No bridges
whatsoever.
In fact, packet is catched by batctl td coming in at wlan0.
Any hints or experiences will be greatly appreciated as always!
Gui
Hi everyone,
I've been experimenting with gateway selection in QuintanaLibre. I have
a very bad gateway that I want to work as a last resort gateway when the
other is down, so I tried changing to gw_mode client 1 and used some
unreal values for the Up/Down speeds to "force" the selection.
Anyway, this is all well, the good gateway gets selected from almost all
the mesh, but the problem is that when I updated the client routers
configuration using uci to make it permanent, I stumbled with this
strange result that you can see here:
http://pastebin.com/pEhcq2TW
there's no gateway being selected until I manually run:
# batctl gw_mode client 1
(which was te current mode anyway)
on each client.
In fact, connected computers are not being served DHCP offers because of
this.
Is this some known behavior or just something I overlooked?
Thanks as ever for your help with batman-adv, which here at the far
south we are loving every day more as little mesh clouds keep spawning
around us :)
Cheers,
NicoEchániz
This regression was introduced in 724d05c8215e4e8186097121595ef20b6ba601b7
Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
---
translation-table.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/translation-table.c b/translation-table.c
index 172d50b..37ae4a9 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -688,7 +688,8 @@ batadv_tt_global_orig_entry_add(struct batadv_tt_global_entry *tt_global,
orig_entry = batadv_tt_global_orig_entry_find(tt_global, orig_node);
if (orig_entry) {
/* refresh the ttvn: the current value could be a bogus one that
- * was added during a "temporary client detection" */
+ * was added during a "temporary client detection"
+ */
orig_entry->ttvn = ttvn;
goto out;
}
--
1.7.10.4
Hi!
As we are nearing to our transition to Batman, we are playing some
scenarios with it and our current setups and layouts. Currently we
have many nodes connected to more and more VPN servers we have. And we
would like to use Batman on top of that. What happens is that we would
like to use the Batman also for routing over those VPN links. So that
we can connect our nodes to all VPN servers at the same time and
Batman then chooses over which tunnel the data should be routed. And
of course this is a bit different situation then wireless routing. For
example, different VPN servers might have different free capacities at
the moment available, or at least different overall capacity provided
(somebody can donate 100 Mbit/s on the server, somebody else 50
Mbit/s), and then there are also different latencies. Is there some
way for Batman to prefer routes based on this information? So latency
over one link and capacity? I know that capacity is problematic to
measure for wireless links, but here we could configure them manually.
Latency could be measured. And maybe it would even be enough to
measure latency, assuming that congested link would have higher
latency. So the logic could be:
* if packet loss is different, choose the one with lower packet loss
* if packet loss is the same, choose the one with lower latency
Such logic could probably be even user also on wireless links, no?
Anyway, is this doable? If I understand correctly, Batman does not
support some plugin system where we could inject this in? Would be
this some addition which could go into the core implementation?
I think I asked a bit of this questions before, but now we have a bit
more concrete picture what would be nice to have for our setup to play
really nicely.
Mitar
Hi!
I had a chat the other day on IRC about how to assign ip addresses
whether there is an internet gateway available or not.
Here is the problem and the solution I came up with. Let me know if
that makes sense or if I'm complicating my life.
* Problem *
Our network is still small, there may or may not be an internet gateway
available on it, it doesn't matter. From what I read here
http://www.open-mesh.org/projects/batman-adv/wiki/Gateways for nodes to
have access to the internet, the internet gateway has to be a dhcp server.
The node requests an ip by dhcp and then knows what the default route
is. But if the gateway disappears, there is no more dhcp server, the
nodes do not have ip addresses and the mesh network is about useless.
But if I set nodes with static ips, then the mesh is routable all the
time, but nodes do not know the default route to reach the internet.
Am I right so far?
* Solution *
Someone on irc pointed me out to this page:
http://www.open-mesh.org/projects/batman-adv/wiki/Uevent
I use this uevent to send a dhcp request if a gateway becomes available
or go back to a static ip if all gateways are gone.
Attached is the hotplug script I use. It is in
/etc/hotplug.d/net/99-batman-adv-gw. It supposes the interface is
configured by default with a static ip.
It works perfectly, but I can't believe there is no simpler solution to
this. Our problem should be a quite common one. What is the general
solution to it?
Thanks,
Geneviève
I have an interesting hardware setup I'd like to explore.
Basically, I would like to take commodity ubiquiti and/or openmesh
hardware and build a mesh with two different node types, some having
just 1 radio and others having multiple radios, a standard node and a
super node.
the standard node is:
a picostation flashed to openwrt running batman-adv and running the
radio in Ad-Hoc mode. Alternately an OM2P flashed to openwrt. This
is the basic client radio
the super node is:
a group of picostations or nanostations, flashed openwrt in adhoc
mode, but acting only as the L2 transport with a router at the center
running batman-adv.
The idea is that the super nodes have multiple radios in multiple
channels and can take advantage of link alternation allowing super
nodes to keep much higher bandwidth between them while the standard
nodes are cheap. The 'router' MIGHT also have a radio for client
access (unifi station flashed to openwrt maybe, or an ALIX board)
The supernode will have more CPU and also be the target of
backhaul/shorthaul links to cut down on hop count. The main router
would also be a batman-adv device, probably an x86 server, and would
be the border router for the mesh.
some questions,
I know that the supernodes will have higher throughput capabilities
due to dual mesh radios, but how will batman-adv know this or how
would I tell it? Is the internal mechanism for determining the best
path going to take this into account? Is there a way to identify a
supernode as being a better path above and beyond the automatic
batman-adv mechanisms?
Is having separate radios connected to a batman-adv router going to
behave how I presume? That multiple node2node connections will be
identified and the links be alternated when appropriate?
If the supernodes have 2 mesh radios, 1 in 5Ghz and 1 in 2.4Ghz, then
the standard nodes will only be able to connect to the 2.4Ghz channel
which might make it inappropriate to do link alternating on these two
links because of the shared traffic. Should batman-adv automatically
stop alternating the tx/rx on these links when one of the channels
starts to get saturated?
some other info:
the supernodes may have a link directly to the main distribution
point, but may also be linked just to another supernode and not to the
main distribution point, or possibly both.
the supernodes are likely to have more than 2 mesh radios as some of
these could be direction antennas. A supernode might have 3x 2.4Ghz
radios for mesh, 2x 5Ghz radios for mesh, and a 2.4Ghz radio for
non-mesh clients. These would most likely all be connected to a
switch port and only be on a single ethernet interface as far as
batman-adv is concerned.
From: Ben Hutchings <bhutchings(a)solarflare.com>
Fix incorrect start markers, wrapped summary lines, missing section
breaks, incorrect separators, and some name mismatches.
Signed-off-by: Ben Hutchings <bhutchings(a)solarflare.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
---
This patch is already part of net-next
bridge_loop_avoidance.c | 51 +++++++++++++++++++++++++++++++----------------
hash.h | 3 ++-
main.h | 3 ++-
types.h | 3 ++-
4 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c
index e350ea4..6705d35 100644
--- a/bridge_loop_avoidance.c
+++ b/bridge_loop_avoidance.c
@@ -162,12 +162,13 @@ static struct batadv_claim *batadv_claim_hash_find(struct batadv_priv *bat_priv,
return claim_tmp;
}
-/* @bat_priv: the bat priv with all the soft interface information
+/**
+ * batadv_backbone_hash_find - looks for a claim in the hash
+ * @bat_priv: the bat priv with all the soft interface information
* @addr: the address of the originator
* @vid: the VLAN ID
*
- * looks for a claim in the hash, and returns it if found
- * or NULL otherwise.
+ * Returns claim if found or NULL otherwise.
*/
static struct batadv_backbone_gw *
batadv_backbone_hash_find(struct batadv_priv *bat_priv,
@@ -242,12 +243,12 @@ batadv_bla_del_backbone_claims(struct batadv_backbone_gw *backbone_gw)
backbone_gw->crc = BATADV_BLA_CRC_INIT;
}
-/* @bat_priv: the bat priv with all the soft interface information
+/**
+ * batadv_bla_send_claim - sends a claim frame according to the provided info
+ * @bat_priv: the bat priv with all the soft interface information
* @orig: the mac address to be announced within the claim
* @vid: the VLAN ID
* @claimtype: the type of the claim (CLAIM, UNCLAIM, ANNOUNCE, ...)
- *
- * sends a claim frame according to the provided info.
*/
static void batadv_bla_send_claim(struct batadv_priv *bat_priv, uint8_t *mac,
short vid, int claimtype)
@@ -348,7 +349,9 @@ out:
batadv_hardif_free_ref(primary_if);
}
-/* @bat_priv: the bat priv with all the soft interface information
+/**
+ * batadv_bla_get_backbone_gw
+ * @bat_priv: the bat priv with all the soft interface information
* @orig: the mac address of the originator
* @vid: the VLAN ID
*
@@ -520,12 +523,12 @@ static void batadv_bla_send_announce(struct batadv_priv *bat_priv,
}
-/* @bat_priv: the bat priv with all the soft interface information
+/**
+ * batadv_bla_add_claim - Adds a claim in the claim hash
+ * @bat_priv: the bat priv with all the soft interface information
* @mac: the mac address of the claim
* @vid: the VLAN ID of the frame
* @backbone_gw: the backbone gateway which claims it
- *
- * Adds a claim in the claim hash.
*/
static void batadv_bla_add_claim(struct batadv_priv *bat_priv,
const uint8_t *mac, const short vid,
@@ -743,7 +746,9 @@ static int batadv_handle_claim(struct batadv_priv *bat_priv,
return 1;
}
-/* @bat_priv: the bat priv with all the soft interface information
+/**
+ * batadv_check_claim_group
+ * @bat_priv: the bat priv with all the soft interface information
* @hw_src: the Hardware source in the ARP Header
* @hw_dst: the Hardware destination in the ARP Header
* @ethhdr: pointer to the Ethernet header of the claim frame
@@ -975,7 +980,9 @@ purge_now:
}
}
-/* @bat_priv: the bat priv with all the soft interface information
+/**
+ * batadv_bla_purge_claims
+ * @bat_priv: the bat priv with all the soft interface information
* @primary_if: the selected primary interface, may be NULL if now is set
* @now: whether the whole hash shall be wiped now
*
@@ -1023,7 +1030,9 @@ purge_now:
}
}
-/* @bat_priv: the bat priv with all the soft interface information
+/**
+ * batadv_bla_update_orig_address
+ * @bat_priv: the bat priv with all the soft interface information
* @primary_if: the new selected primary_if
* @oldif: the old primary interface, may be NULL
*
@@ -1193,7 +1202,9 @@ int batadv_bla_init(struct batadv_priv *bat_priv)
return 0;
}
-/* @bat_priv: the bat priv with all the soft interface information
+/**
+ * batadv_bla_check_bcast_duplist
+ * @bat_priv: the bat priv with all the soft interface information
* @bcast_packet: originator mac address
* @hdr_size: maximum length of the frame
*
@@ -1297,7 +1308,9 @@ int batadv_bla_is_backbone_gw_orig(struct batadv_priv *bat_priv, uint8_t *orig)
}
-/* @skb: the frame to be checked
+/**
+ * batadv_bla_is_backbone_gw
+ * @skb: the frame to be checked
* @orig_node: the orig_node of the frame
* @hdr_size: maximum length of the frame
*
@@ -1363,7 +1376,9 @@ void batadv_bla_free(struct batadv_priv *bat_priv)
batadv_hardif_free_ref(primary_if);
}
-/* @bat_priv: the bat priv with all the soft interface information
+/**
+ * batadv_bla_rx
+ * @bat_priv: the bat priv with all the soft interface information
* @skb: the frame to be checked
* @vid: the VLAN ID of the frame
* @is_bcast: the packet came in a broadcast packet type.
@@ -1457,7 +1472,9 @@ out:
return ret;
}
-/* @bat_priv: the bat priv with all the soft interface information
+/**
+ * batadv_bla_tx
+ * @bat_priv: the bat priv with all the soft interface information
* @skb: the frame to be checked
* @vid: the VLAN ID of the frame
*
diff --git a/hash.h b/hash.h
index 83990e3..977de9c 100644
--- a/hash.h
+++ b/hash.h
@@ -81,7 +81,8 @@ static inline void batadv_hash_delete(struct batadv_hashtable *hash,
batadv_hash_destroy(hash);
}
-/* hash_add - adds data to the hashtable
+/**
+ * batadv_hash_add - adds data to the hashtable
* @hash: storage hash table
* @compare: callback to determine if 2 hash elements are identical
* @choose: callback calculating the hash index
diff --git a/main.h b/main.h
index 6dca9c4..c88e18e 100644
--- a/main.h
+++ b/main.h
@@ -218,7 +218,8 @@ static inline int batadv_compare_eth(const void *data1, const void *data2)
return (memcmp(data1, data2, ETH_ALEN) == 0 ? 1 : 0);
}
-/* has_timed_out - compares current time (jiffies) and timestamp + timeout
+/**
+ * has_timed_out - compares current time (jiffies) and timestamp + timeout
* @timestamp: base value to compare with (in jiffies)
* @timeout: added to base value before comparing (in milliseconds)
*
diff --git a/types.h b/types.h
index 2141c13..12635fd 100644
--- a/types.h
+++ b/types.h
@@ -44,7 +44,8 @@ struct batadv_hard_iface {
struct rcu_head rcu;
};
-/* batadv_orig_node - structure for orig_list maintaining nodes of mesh
+/**
+ * struct batadv_orig_node - structure for orig_list maintaining nodes of mesh
* @primary_addr: hosts primary interface address
* @last_seen: when last packet from this node was received
* @bcast_seqno_reset: time when the broadcast seqno window was reset
--
1.7.10.4