B.A.T.M.A.N

b.a.t.m.a.n@lists.open-mesh.org

15 participants
4308 discussions

[B.A.T.M.A.N.] [PATCH 1/2] batman-adv: fix aggregation timing bug
by Linus Lüssing 20 Mar '10

20 Mar '10

From: Marek Lindner <lindner_marek(a)yahoo.de> batman-adv aggregates routing packets to reduce the number of packets in the air. Every outgoing packet is compared with other packets in the buffer to determine whether it can be aggregated or not. Packets sent at a lower interval can be held back longer to maximize the aggregation. Due to insufficient checking batman-adv held back all packets for a certain time depending on its own lowest interval rate which slowed down all other nodes. Reported-by: Linus Luessing <linus.luessing(a)web.de> Signed-off-by: Marek Lindner <lindner_marek(a)yahoo.de> --- aggregation.c | 12 ++++++++++++ send.c | 10 +--------- 2 files changed, 13 insertions(+), 9 deletions(-) diff --git a/batman-adv-kernelland/aggregation.c b/batman-adv-kernelland/aggregation.c index a829814..0635b5a 100644 --- a/batman-adv-kernelland/aggregation.c +++ b/batman-adv-kernelland/aggregation.c @@ -52,6 +52,8 @@ static bool can_aggregate_with(struct batman_packet *new_batman_packet, */ if (time_before(send_time, forw_packet->send_time) && + time_after_eq(send_time + msecs_to_jiffies(MAX_AGGREGATION_MS), + forw_packet->send_time) && (aggregated_bytes <= MAX_AGGREGATION_BYTES)) { /** @@ -196,6 +198,16 @@ void add_bat_packet_to_list(unsigned char *packet_buff, int packet_len, if (forw_packet_aggr == NULL) { /* the following section can run without the lock */ spin_unlock_irqrestore(&forw_bat_list_lock, flags); + + /** + * if we could not aggregate this packet with one of the others + * we hold it back for a while, so that it might be aggregated + * later on + */ + if ((!own_packet) && + (atomic_read(&bat_priv->aggregation_enabled))) + send_time += msecs_to_jiffies(MAX_AGGREGATION_MS); + new_aggregated_packet(packet_buff, packet_len, send_time, direct_link, if_incoming, own_packet); diff --git a/batman-adv-kernelland/send.c b/batman-adv-kernelland/send.c index 1c82f43..4320855 100644 --- a/batman-adv-kernelland/send.c +++ b/batman-adv-kernelland/send.c @@ -49,15 +49,7 @@ static unsigned long own_send_time(void) /* when do we schedule a forwarded packet to be sent */ static unsigned long forward_send_time(struct bat_priv *bat_priv) { - unsigned long send_time = jiffies; /* Starting now plus... */ - - if (atomic_read(&bat_priv->aggregation_enabled)) - send_time += (((MAX_AGGREGATION_MS - (JITTER/2) + - (random32() % JITTER)) * HZ) / 1000); - else - send_time += (((random32() % (JITTER/2)) * HZ) / 1000); - - return send_time; + return jiffies + (((random32() % (JITTER/2)) * HZ) / 1000); } /* send out an already prepared packet to the given address via the -- 1.7.0

2 3

[B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010
by Michael Fazio 16 Mar '10

16 Mar '10

Hello, My name is Michael. I am currently working on a large robotics project and I am thinking of using B.A.T.M.A.N to facilitate a MANET to communicate between a number of bots and a base station. I was hoping to get a bit of information regarding the suitability of B.A.T.M.A.N for such an application. Any information would be helpful (general or specific). Here are some of the details of our project. We will be using up-to 14 bots in our project (each must be network aware). The area that our bots will be operating in is approximately the size of a football field. There are both indoor and outdoor areas that must be navigated with a significant amount of obstacles. We will be using 802.11a,b,g and possibly n as well as one or more long range VHF links which I am hoping to setup as additional entry points to our bot network. We have various types of data to be communicated on our network including, GPS, basic telemetry, control message, imagery, UAV feeds, point cloud info etc. Some data such as GPS and telemetry is realtime and need not be reliable (we are considering simply UDP broadcasting this data). Other data such as imagery and control messages will require stable links and need to be relatively reliable. We are not yet sure if we will be deploying any specific middleware technology although I am partial to pub/sub middleware. Are there any such middleware that can complement B.A.T.M.A.N? I was hoping to know what type of issues I might run into using B.A.T.M.A.N adv in such a scenario. For instance, what kind of throughput might I expect in the described environment? Link stability issues? General suitability? How would B.A.T.M.A.N compare to OLSR or Babel? I am really interested in anything that anyone has to offer. The reason I am pushing for B.A.T.M.A.N is because of the ability for us to develop our application layer using IPv4 TCP/UDP on-top of a mesh network driven by routers running openWRT & B.A.T.M.A.N. I want to take as much network layer knowledge away from out application layer. Also, does anyone know of other similar usages of B.A.T.M.A.N? I have a bunch of studies from various organizations comparing B.A.T.M.A.N to other solutions but I would really appreciate to hear what the mail list users have to say about their own experiences with B.A.T.M.A.N. I hope this is the right place to be asking all these questions! Thanks Batmen & Batwomen! Michael

4 6

[B.A.T.M.A.N.] reorganized kernel interface patches [part II]
by Marek Lindner 15 Mar '10

15 Mar '10

Hi, since we have initial steps behind us it is time to move on. The following patches convert 4 files from /proc to /sys - nothing fancy here. Please give it a try and let me know what you think. Cheers, Marek

1 3

[B.A.T.M.A.N.] Strange sequence numbers
by Kevin Steen 14 Mar '10

14 Mar '10

I've been lurking on this list for a few weeks, but finally tried compiling and running the batman-adv module from the svn sources. It seems to work fine between my two test machines so far, but I noticed some weird sequence numbers when doing a dump with 'batctl td'. In the sequence below, I had 'rover' running and active on rover's eth0, then I activated the eth1 interface on hilltop for a few seconds, then de-activated it. It seems like when rover re-sends the OGM from hilltop, it gets the sequence number wrong (1->256, 2->512, 3->768). Is this my lack of understanding of how it should work, a bug in batctl's display or a bug in batman-adv? rover is kernel 2.6.31-20-generic (Ubuntu karmic), hilltop is kernel 2.6.26-2-686 (Debian lenny) $ ./batctl td eth1 23:37:22.022554 BAT rover-eth0: OGM via neigh rover-eth0, seqno 481, tq 255, ttl 50, v 9, flags [..F], length 42 23:37:23.002547 BAT rover-eth0: OGM via neigh rover-eth0, seqno 482, tq 255, ttl 50, v 9, flags [..F], length 42 23:37:23.982469 BAT rover-eth0: OGM via neigh rover-eth0, seqno 483, tq 255, ttl 50, v 9, flags [..F], length 42 23:37:24.962417 BAT rover-eth0: OGM via neigh rover-eth0, seqno 484, tq 255, ttl 50, v 9, flags [..F], length 42 23:37:25.962320 BAT rover-eth0: OGM via neigh rover-eth0, seqno 485, tq 255, ttl 50, v 9, flags [..F], length 42 23:37:26.943490 BAT rover-eth0: OGM via neigh rover-eth0, seqno 486, tq 0, ttl 49, v 9, flags [D..], length 42 23:37:27.041437 BAT rover-eth0: OGM via neigh hilltop-eth1, seqno 486, tq 0, ttl 49, v 9, flags [D..], length 28 23:37:27.893422 BAT hilltop-eth1: OGM via neigh hilltop-eth1, seqno 1, tq 255, ttl 50, v 9, flags [..F], length 22 23:37:27.922233 BAT rover-eth0: OGM via neigh rover-eth0, seqno 487, tq 0, ttl 49, v 9, flags [D..], length 42 23:37:27.978267 BAT hilltop-eth1: OGM via neigh rover-eth0, seqno 256, tq 10, ttl 49, v 9, flags [D..], length 42 23:37:28.025425 BAT rover-eth0: OGM via neigh hilltop-eth1, seqno 487, tq 0, ttl 49, v 9, flags [D..], length 28 23:37:28.873428 BAT hilltop-eth1: OGM via neigh hilltop-eth1, seqno 2, tq 255, ttl 50, v 9, flags [..F], length 28 23:37:28.902203 BAT rover-eth0: OGM via neigh rover-eth0, seqno 488, tq 10, ttl 49, v 9, flags [D..], length 42 23:37:28.958188 BAT hilltop-eth1: OGM via neigh rover-eth0, seqno 512, tq 21, ttl 49, v 9, flags [D..], length 42 23:37:29.005443 BAT rover-eth0: OGM via neigh hilltop-eth1, seqno 488, tq 10, ttl 49, v 9, flags [D..], length 28 23:37:29.873428 BAT hilltop-eth1: OGM via neigh hilltop-eth1, seqno 3, tq 255, ttl 50, v 9, flags [..F], length 28 23:37:29.902152 BAT rover-eth0: OGM via neigh rover-eth0, seqno 489, tq 22, ttl 49, v 9, flags [D..], length 42 23:37:29.970180 BAT hilltop-eth1: OGM via neigh rover-eth0, seqno 768, tq 30, ttl 49, v 9, flags [D..], length 42 23:37:30.009433 BAT rover-eth0: OGM via neigh hilltop-eth1, seqno 489, tq 22, ttl 49, v 9, flags [D..], length 28 23:37:30.882142 BAT rover-eth0: OGM via neigh rover-eth0, seqno 490, tq 255, ttl 50, v 9, flags [..F], length 42 23:37:31.882087 BAT rover-eth0: OGM via neigh rover-eth0, seqno 491, tq 255, ttl 50, v 9, flags [..F], length 42 23:37:32.862046 BAT rover-eth0: OGM via neigh rover-eth0, seqno 492, tq 255, ttl 50, v 9, flags [..F], length 42 23:37:33.861989 BAT rover-eth0: OGM via neigh rover-eth0, seqno 493, tq 255, ttl 50, v 9, flags [..F], length 42 23:37:34.861946 BAT rover-eth0: OGM via neigh rover-eth0, seqno 494, tq 255, ttl 50, v 9, flags [..F], length 42 -Kevin

4 7

[B.A.T.M.A.N.] vis: (sometimes) missing entries
by Linus Lüssing 14 Mar '10

14 Mar '10

Hi guys, Ok, and the second bug, which has been there even before the 0.2 release if I remember right, is, that seemingly random entries in the vis-servers output are missing, even when having a setup with single-interface nodes only. The probability seems to increase the more nodes are in the mesh network. For instance, I'm right now running a setup of 4 wifi routers + my laptop with the current batman-adv maintenance version with my last vis patch. They are all right next to each other and connected over wifi, therefore they're all in the same neighbourhood. No downloads or any other highly disturbing wifi traffic around. With just 3 routers, there are only missing entries from time to time, but with 5 devices, there is usually always at least one entry missing. For example: ----------------------------------------------------------------- sh-4.1# ./batctl vd dot && ./batctl o digraph { "06:22:b0:98:94:0b" -> "06:22:b0:98:87:f9" [label="1.20"] "06:22:b0:98:94:0b" -> "06:22:b0:44:c6:59" [label="1.0"] "06:22:b0:98:94:0b" -> "00:13:e8:50:c0:ff" [label="1.0"] "06:22:b0:98:94:0b" -> "06:22:b0:44:94:5d" [label="1.20"] "06:22:b0:98:94:0b" -> "00:22:b0:98:94:0b" [label="HNA"] "06:22:b0:98:94:0b" -> "02:c7:5f:09:af:0f" [label="HNA"] subgraph "cluster_06:22:b0:98:94:0b" { "06:22:b0:98:94:0b" [peripheries=2] } "06:22:b0:98:87:f9" -> "06:22:b0:98:94:0b" [label="1.20"] "06:22:b0:98:87:f9" -> "06:22:b0:44:c6:59" [label="1.71"] "06:22:b0:98:87:f9" -> "00:13:e8:50:c0:ff" [label="1.32"] "06:22:b0:98:87:f9" -> "00:22:b0:98:87:f9" [label="HNA"] "06:22:b0:98:87:f9" -> "9e:03:d3:3e:3e:15" [label="HNA"] subgraph "cluster_06:22:b0:98:87:f9" { "06:22:b0:98:87:f9" [peripheries=2] } "06:22:b0:44:c6:59" -> "06:22:b0:98:87:f9" [label="1.15"] "06:22:b0:44:c6:59" -> "00:13:e8:50:c0:ff" [label="1.28"] "06:22:b0:44:c6:59" -> "06:22:b0:44:94:5d" [label="1.80"] "06:22:b0:44:c6:59" -> "46:b4:01:60:f6:57" [label="HNA"] "06:22:b0:44:c6:59" -> "00:22:b0:44:c6:59" [label="HNA"] subgraph "cluster_06:22:b0:44:c6:59" { "06:22:b0:44:c6:59" [peripheries=2] } "00:13:e8:50:c0:ff" -> "06:22:b0:98:87:f9" [label="1.3"] "00:13:e8:50:c0:ff" -> "06:22:b0:98:94:0b" [label="1.28"] "00:13:e8:50:c0:ff" -> "06:22:b0:44:c6:59" [label="1.36"] "00:13:e8:50:c0:ff" -> "06:22:b0:44:94:5d" [label="1.53"] "00:13:e8:50:c0:ff" -> "2e:bb:47:5b:b1:5e" [label="HNA"] subgraph "cluster_00:13:e8:50:c0:ff" { "00:13:e8:50:c0:ff" [peripheries=2] } "06:22:b0:44:94:5d" -> "06:22:b0:98:87:f9" [label="1.0"] "06:22:b0:44:94:5d" -> "06:22:b0:98:94:0b" [label="1.89"] "06:22:b0:44:94:5d" -> "06:22:b0:44:c6:59" [label="1.28"] "06:22:b0:44:94:5d" -> "00:13:e8:50:c0:ff" [label="1.49"] "06:22:b0:44:94:5d" -> "00:22:b0:44:94:5d" [label="HNA"] "06:22:b0:44:94:5d" -> "da:ef:64:a7:33:a7" [label="HNA"] subgraph "cluster_06:22:b0:44:94:5d" { "06:22:b0:44:94:5d" [peripheries=2] } } Originator (#/255) Nexthop [outgoingIF]: Potential nexthops ... [B.A.T.M.A.N. adv 0.2.1-beta, MainIF/MAC: wlan0/00:13:e8:50:c0:ff] 06:22:b0:98:87:f9 (252) 06:22:b0:98:87:f9 [ wlan0]: 06:22:b0:98:87:f9 (252) 06:22:b0:98:94:0b (232) 06:22:b0:44:94:5d (232) 06:22:b0:44:c6:59 (229) 06:22:b0:98:94:0b (249) 06:22:b0:98:94:0b [ wlan0]: 06:22:b0:98:94:0b (249) 06:22:b0:44:94:5d (217) 06:22:b0:98:87:f9 (235) 06:22:b0:44:c6:59 (234) 06:22:b0:44:c6:59 (246) 06:22:b0:44:c6:59 [ wlan0]: 06:22:b0:44:c6:59 (246) 06:22:b0:44:94:5d (221) 06:22:b0:98:94:0b (229) 06:22:b0:98:87:f9 (225) 06:22:b0:44:94:5d (242) 06:22:b0:44:94:5d [ wlan0]: 06:22:b0:44:94:5d (242) 06:22:b0:98:94:0b (225) 06:22:b0:98:87:f9 (212) 06:22:b0:44:c6:59 (227) sh-4.1# ----------------------------------------------------------------- I'd expect all 5 nodes to have a direct connection to all other 4 nodes. However, for instance 06:22:b0:98:87:f9 is just having three. A couple of seconds later, the missing entry is there again, but other ones can be missing. What I also just noticed is, that when I refresh the vis-output every second only the TQ values of _2_ entries at a time get updated, the other ones are static for quite a while. However, looking at wireshark tells me, that I'm still getting a vis-packet of all other 4 nodes every second. So it looks like the vis-server might not be always updating its vis_hash to me, but not sure about that. I'm also attaching a capture on the laptop's wifi interface while I had been sending ping-floods to ensure that the tq-values should be changing frequently (which is not the case according to the vis-server-output). Cheers, Linus

5 16

[B.A.T.M.A.N.] reorganized kernel interface patches (version 2)
by Marek Lindner 11 Mar '10

11 Mar '10

Hi, I merged the feedback given so far into the patchset and post them again to offer you the chance of generating even more feedback. :-) Changes since version1: * the known issue from version1 turned out to be a bug in the used kernel * batctl sysfs path has been changed to /sys/class/net/ since older kernels don't provide the "virtual" subdirectory * the year of the copyright notice was corrected * In case the erroneous of input contains a newline it will not be printed to avoid printing 2 subsequent newlines * the function calls which used global variables before now receive the bat_priv struct as an argument * added _GNU_SOURCE to bat-hosts.c to avoid compile warning * batctl gets bonding mode support Cheers, Marek

2 5

[B.A.T.M.A.N.] [PATCH] batman-adv: Add missing source-if info in vis raw
by Linus Lüssing 10 Mar '10

10 Mar '10

With this patch, a line for each _source interface_ for every node will be used in the vis raw output instead of one line per originator. This stops discarding valuable information about secondary interfaces. Signed-off-by: Linus Lüssing <linus.luessing(a)web.de> --- proc.c | 33 ++++++++++++++++++++++++++------- vis.c | 25 +++++++++---------------- vis.h | 7 +++++-- 3 files changed, 40 insertions(+), 25 deletions(-) diff --git a/proc.c b/proc.c index 1c12613..ab5047f 100644 --- a/proc.c +++ b/proc.c @@ -370,6 +370,8 @@ static int proc_vis_data_read(struct seq_file *seq, void *offset) struct vis_info *info; struct vis_info_entry *entries; HLIST_HEAD(vis_if_list); + struct if_list_entry *entry; + struct hlist_node *pos, *n; int i; char tmp_addr_str[ETH_STR_LEN]; unsigned long flags; @@ -388,17 +390,34 @@ static int proc_vis_data_read(struct seq_file *seq, void *offset) info = hashit.bucket->data; entries = (struct vis_info_entry *) ((char *)info + sizeof(struct vis_info)); - addr_to_string(tmp_addr_str, info->packet.vis_orig); - seq_printf(seq, "%s,", tmp_addr_str); for (i = 0; i < info->packet.entries; i++) { - proc_vis_read_entry(seq, &entries[i], &vis_if_list, - info->packet.vis_orig); + if (entries[i].quality == 0) + continue; + proc_vis_insert_interface(entries[i].src, &vis_if_list, + compare_orig(entries[i].src, + info->packet.vis_orig)); } - /* add primary/secondary records */ - proc_vis_read_prim_sec(seq, &vis_if_list); - seq_printf(seq, "\n"); + hlist_for_each_entry(entry, pos, &vis_if_list, list) { + addr_to_string(tmp_addr_str, entry->addr); + seq_printf(seq, "%s,", tmp_addr_str); + + for (i = 0; i < info->packet.entries; i++) + proc_vis_read_entry(seq, &entries[i], + entry->addr, entry->primary); + + /* add primary/secondary records */ + if (compare_orig(entry->addr, info->packet.vis_orig)) + proc_vis_read_prim_sec(seq, &vis_if_list); + + seq_printf(seq, "\n"); + } + + hlist_for_each_entry_safe(entry, pos, n, &vis_if_list, list) { + hlist_del(&entry->list); + kfree(entry); + } } spin_unlock_irqrestore(&vis_hash_lock, flags); diff --git a/vis.c b/vis.c index 4f1339a..fa8a487 100644 --- a/vis.c +++ b/vis.c @@ -87,7 +87,7 @@ static int vis_info_choose(void *data, int size) /* insert interface to the list of interfaces of one originator, if it * does not already exist in the list */ -static void proc_vis_insert_interface(const uint8_t *interface, +void proc_vis_insert_interface(const uint8_t *interface, struct hlist_head *if_list, bool primary) { @@ -112,39 +112,32 @@ void proc_vis_read_prim_sec(struct seq_file *seq, struct hlist_head *if_list) { struct if_list_entry *entry; - struct hlist_node *pos, *n; + struct hlist_node *pos; char tmp_addr_str[ETH_STR_LEN]; - hlist_for_each_entry_safe(entry, pos, n, if_list, list) { - if (entry->primary) { + hlist_for_each_entry(entry, pos, if_list, list) { + if (entry->primary) seq_printf(seq, "PRIMARY, "); - } else { + else { addr_to_string(tmp_addr_str, entry->addr); seq_printf(seq, "SEC %s, ", tmp_addr_str); } - - hlist_del(&entry->list); - kfree(entry); } } /* read an entry */ void proc_vis_read_entry(struct seq_file *seq, struct vis_info_entry *entry, - struct hlist_head *if_list, - uint8_t *vis_orig) + uint8_t *src, + bool primary) { char to[40]; addr_to_string(to, entry->dest); - if (entry->quality == 0) { - proc_vis_insert_interface(vis_orig, if_list, true); + if (primary && entry->quality == 0) seq_printf(seq, "HNA %s, ", to); - } else { - proc_vis_insert_interface(entry->src, if_list, - compare_orig(entry->src, vis_orig)); + else if (compare_orig(entry->src, src)) seq_printf(seq, "TQ %s %d, ", to, entry->quality); - } } /* add the info packet to the send list, if it was not diff --git a/vis.h b/vis.h index 465da47..a1f92a4 100644 --- a/vis.h +++ b/vis.h @@ -49,10 +49,13 @@ struct recvlist_node { extern struct hashtable_t *vis_hash; extern spinlock_t vis_hash_lock; +void proc_vis_insert_interface(const uint8_t *interface, + struct hlist_head *if_list, + bool primary); void proc_vis_read_entry(struct seq_file *seq, struct vis_info_entry *entry, - struct hlist_head *if_list, - uint8_t *vis_orig); + uint8_t *src, + bool primary); void proc_vis_read_prim_sec(struct seq_file *seq, struct hlist_head *if_list); void receive_server_sync_packet(struct vis_packet *vis_packet, -- 1.7.0

2 2

[B.A.T.M.A.N.] FWD: batman: potential null dereference
by Andrew Lunn 08 Mar '10

08 Mar '10

Does somebody have time to look at this? Andrew ----- Forwarded message from Dan Carpenter <error27(a)gmail.com> ----- Date: Mon, 8 Mar 2010 16:07:01 +0300 From: Dan Carpenter <error27(a)gmail.com> To: andrew(a)lunn.ch Cc: kernel-janitors(a)vger.kernel.org Subject: batman: potential null dereference X-Spam-Status: No, score=2.9 required=4.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_WEB autolearn=no version=3.3.0 drivers/staging/batman-adv/routing.c 88 } else if ((orig_node->router == NULL) && (neigh_node != NULL)) { ^^^^^^^^^^^^^^^^^^^^^^^^^ 89 90 bat_dbg(DBG_ROUTES, 91 "Adding route towards: %pM (via %pM)\n", 92 orig_node->orig, neigh_node->addr); 93 hna_global_add_orig(orig_node, hna_buff, hna_buff_len); 94 95 /* route changed */ 96 } else { 97 bat_dbg(DBG_ROUTES, "Changing route towards: %pM (now via %pM - was via %pM)\n", orig_node->orig, neigh_node->addr, orig_node->router->addr); ^^^^^^^^^^^^^^^^^^^^^^^ 98 } This could fail if debugging is enabled and neigh_node is null. regards, dan carpenter ----- End forwarded message -----

4 4

[B.A.T.M.A.N.] vis packet format
by Linus Lüssing 04 Mar '10

04 Mar '10

Hi, Marek and I have been chatting a little about the buggy vis raw output yesterday. And there was either the option to sort the mixed list on the receiving vis server or on the sender already. For the second option there was also the idea of changing the vis packet format accordingly to also save some more overhead. Currently, we're sending a mixed list of (src,dest,quality) with the struct vis_info_entry. Instead, the idea for a new format was the following: vis_packet.entries = number of source interfaces of this originator followed by tuples {src,num_neighbours,num_neighbours x {dest,quality}} for each source interface of a node. Additionally, the first entry shall be the one of the primary interface already. I've made a little prototype patch, see the attachment for this (it applies on top of Simon's last vis_refcount additions patch). I haven't done the more difficult part yet, the sorting and structuring that has to be done in the generate_vis_packet() instead now. If you think this kind of format is ok, then I'd like to have some more opinions of how to deal with the structuring in the generate_vis_packet(). My idea so far is, to create num_if lists and malloc and copy the information for every neighbour of an originator during the locked orig_hash iteration and freeing as well as packing those list after realeasing the lock. Or, if the mallocs might take too much time for being used so often during the lock, to allocate num_ifs buffers with the maximum vis_packet size (currently 1000B) for each interface batman is using before entering the spinlock. And I guess, that anyway num_ifs would have to be made an atomic_t, right? Cheers, Linus PS: Could someone explain, why the recv_list_add() is being done with a sender_orig instead of vis_orig? Because if using vis_orig, then we could get rid of the sender_orig as well because of having this information in the ethernet header already.

3 4

[B.A.T.M.A.N.] [PATCH v2] batctl: avoid parsing bat-hosts multiple times
by Daniel Seither 04 Mar '10

04 Mar '10

Currently, running batctl from the home directory leads to warnings ("Warning - mac already known") if ~/bat-hosts exists. This is caused by batctl parsing both "~/bat-hosts" and "bat-hosts" which happen to be the same file when the working directory is ~ This patch adds duplicate file name detection to bat_hosts_init() to avoid these warnings. Signed-off-by: Daniel Seither <post(a)tiwoc.de> --- Index: batctl/bat-hosts.c =================================================================== --- batctl/bat-hosts.c (revision 1579) +++ batctl/bat-hosts.c (working copy) @@ -23,6 +23,7 @@ #include <stdio.h> #include <stdint.h> +#include <limits.h> #include <stdlib.h> #include <errno.h> #include <string.h> @@ -144,9 +145,11 @@ void bat_hosts_init(void) { - unsigned int i; + unsigned int i, j, parse; char confdir[CONF_DIR_LEN]; char *homedir; + size_t locations = sizeof(bat_hosts_path) / sizeof(char *); + char *normalized[locations]; host_hash = hash_new(64, compare_mac, choose_mac); @@ -157,7 +160,7 @@ homedir = getenv("HOME"); - for (i = 0; i < sizeof(bat_hosts_path) / sizeof(char *); i++) { + for (i = 0; i < locations; i++) { strcpy(confdir, ""); if (strlen(bat_hosts_path[i]) >= 2 @@ -169,9 +172,29 @@ strncpy(confdir, bat_hosts_path[i], CONF_DIR_LEN); confdir[CONF_DIR_LEN - 1] = '\0'; } - - parse_hosts_file(&host_hash, confdir); + + normalized[i] = realpath(confdir, NULL); + if (normalized[i] == NULL) + continue; + + /* check for duplicates: don't parse the same file twice */ + parse = 1; + for (j = 0; j < i; j++) { + if (normalized[j] == NULL) + continue; + + if (strncmp(normalized[i], normalized[j], CONF_DIR_LEN) == 0) { + parse = 0; + break; + } + } + + if (parse && (normalized[i] != NULL)) + parse_hosts_file(&host_hash, normalized[i]); } + + for (i = 0; i < locations; i++) + free(normalized[i]); } struct bat_host *bat_hosts_find_by_name(char *name)

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N