B.A.T.M.A.N January 2011

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

20 participants
35 discussions

Re: [B.A.T.M.A.N.] New BMX website at www.bmx6.net

by Sven Eckelmann

Axel Neumann wrote: > > Does that mean that your svn directories and git repositories at > > open-mesh.org can be dropped > > In the long term yes! But please not right now. I want to update links in > other repositories like openWrt first and give users some time to update > their checkout as well so that the build process does not fail. Lets say > in February. Ok, sounds good. > > (at least it seems that no branch has common > > ancestors with your branches)? > > For branches/bmx-0.3.x/ I used git-svn to create the git repository which > I expected to create common ancestors. Some confusion leaked in when I > moved the directory from trunk/batman-experimental to branches/bmx-0.3.x > (some deleted files like LIESMICH,.. were not deleted which I fixed with > the last git commit). The problem is that you (sry, no offence meant) did a quite bad job to convert it. bmxd.git has these weird git-svn-id lines in the commit messages, "random" commiter names+mails, missing parts of the history, dangling symlinks, ... Please take a look at git://git.open-mesh.org/ecsv/test/bmx.git I don't say that it is the holy grail of svn-to-git conversation, but I think it could be a better conversation than your bmxd.git Best regards, Sven

12 years

[B.A.T.M.A.N.] Fwd: BATMAN routing

by hlabishi kobo

---------- Forwarded message ---------- From: hlabishi kobo <hlabishik(a)gmail.com> Date: Sun, 28 Nov 2010 22:06:01 +0200 Subject: Fwd: BATMAN routing To: lindner_marek(a)yahoo.de Hi Thank you very much for your reply. The reason why i sent this to you and your colleague is that i have tried the mail list before and all my post kept on being returned, i used this address b.a.t.m.a.n-owner(a)lists.open-mesh.org. I would really appreciate it if this can reach the mailing list public (i will keep on trying). i will send you a follow up on the full explanation of the concept like you requested. Regards Hlabishi ---------- Forwarded message ---------- From: <b.a.t.m.a.n-owner(a)lists.open-mesh.org> Date: Sat, Nov 27, 2010 at 12:58 AM Subject: Fwd: BATMAN routing To: hlabishik(a)gmail.com Message rejected by filter rule match ---------- Forwarded message ---------- From: hlabishi kobo <hlabishik(a)gmail.com> To: b.a.t.m.a.n(a)lists.open-mesh.org Date: Sat, 27 Nov 2010 00:58:09 +0200 Subject: Fwd: BATMAN routing ---------- Forwarded message ---------- From: Marek Lindner <lindner_marek(a)yahoo.de> Date: Fri, Nov 26, 2010 at 5:23 PM Subject: Re: BATMAN routing To: hlabishi kobo <hlabishik(a)gmail.com>, Linus Lüssing < linus.luessing(a)web.de> Cc: siwu(a)hrz.tu-chemnitz.de Hi, welcome to the project! :-) > Firstly my apologies for sending this email to your personal email. My name > is Hlabishi Isaac Kobo at the, an Msc computer science student at the > University of the Western Cape in South Africa, I am doing a research on > routing in a hybrid (combination of static and mobile dynamic routers) > mesh. I don't see a good reason to apologize, just wondering why you are not sending this mail to the public list ? > I want to use the mesh potatoes as well as the batphone (android > version of batman) to create a mesh model. What is the "batphone" ? A project name or a nick name you invented ? :-) Note: Various tests have shown that running a mobile device (smartphone/tablet/etc) in adhoc mode plus running a mesh protocol on top is a battery killer, hence not practical in real world scenarios (in addition of the hassle to install and configure the mesh software on each and every device). This was one of the main reasons to start developing batman-adv as it allows mobile devices to take advantage of the mesh (e.g. roaming) without having to run the mesh on the device itself. You might be aware of this - I am just mentioning it because many people are not. > First we say the recently received OGMs will give a clear indication on the > reliability on the link, so we give the recently received OGMs from the > sliding window a priority in deciding the best next hop link towards a > destination. We want to count and add the indexes were an OGM was recorded > in an interval (seconds), (hence the recently received OGM will have more > weight). At the end the link with more recent OGMs will have more weight > and hence become the current best link. This is a good idea. We are in the process of redesigning the current protocol and welcome any input. Giving older OGMs less "weight" was also one of the ideas we had. Would you mind explaining your concept in greater detail ? > I went through the source code so many times and I got few questions about > this: Are we talking about the batman daemon source code or the batman-adv kernel module ? All my answers will refer to the kernel module as this is the place where most of the development is going on at the moment. > 1. What structure is used to keep track of the sliding window? If its the > has how does it get updated based on the sliding packet range? Each "struct orig_node" has a bitarray to keep track of its own seqnos repeated by its neighbors (bcast_own) and each "struct neigh_node" having a bitarray for its own OGMs (real_bits). > 2. How are the OGM's recorded, is in a form of binary where 1 will > represent the received OGM and 0 otherwise? Correct. > 3. I looked in the source and still not sure of where the ranking decisions > are made, can you enlighten me on that? You mean which function changes the route when a better neighbor was found ? That would be update_orig() in routing.c. > On the second approach we want to use mac layer stats to estimate the > signal strength and probably the congestion rate of the top N ranked links. > We acknowledge the fact that usually links with lower signal strength will > loose more OGM's which results in an automatic low rank, however in a > frequently changing topology, current signal strength is crucial. We plan > to use SNR or RSSI in this case. The concept is known since a while but nobody has implemented it so far because its implementation is fairly complex. Do you have an idea how it should work in the end ? > 1. How can i get the RSSI/LQI of th neighbor links? I don't get this question. You intend to use RSSI but you don't know how ? > I would really appreciate your opinions and advices in this regard more > specially how to go about implementing changes in BATMAN protocol. This is a little abstract. Usually, we discuss specific concepts / ideas in our IRC channel or on the mailing list long before starting to implement them. The past has shown it is often better to let other people dive into your ideas and comment because routing is a rather complex subject. As I mentioned above: We are in a redesign phase right now and welcome anyone interested to join. As the next step we envisioned a collection of routing scenarios in which the current implementation behaves poorly. All routing protocol changes have to go through this collection of scenarios to estimate its impact. What do you think about this idea ? Regards, Marek

12 years

[B.A.T.M.A.N.] Wireless Battle Mesh v4 - Call for papers

by Marek Lindner

Wireless Battle Mesh v4 - Call for papers ========================= Wireless Battle Mesh v4 is at hand and it is time to bring together the agenda. To avoid last year's dynamic process which gave us a true talk marathon on the very last day of WBMv3 all talks / workshops / panel discussions shall be announced beforehand. Tracks ==== In order to broaden the horizon of the event we are going to split the event into different tracks: * The technical track is taking place throughout the week (monday till friday) which mainly focuses on rather technical topics like: => routing protocol internals => implementations / development of "cool" algorithms => hands-on routing / multicast / roaming / convergence speed / etc => secuity aspects in mesh networks => your idea here * The weekend (saturday & sunday) is reserved for the applications track which aims to showcase applications that run on top of the mesh. It is not important whether protocol X or Y is deployed and how it is implemented, the question is: What can we do with the mesh once it is there ? => VoIP in the mesh ? => fast desaster recovery ? => artistic projects ? => your idea here The idea of these tracks is to provide a ground for the different developers / projects to exchange ideas on technical aspects of algorithms / implementations / optimizations as well as organizing an exchange with mesh network users who care less about how the mesh itself works as long as their application can do its job. On the other hand the weekend serves as an entry point for people to learn about what you can actually do with mesh networks. Submission ======= To allow an efficient handling of your submission, please provide the following information and send them to me directly in form of an email: * your name * the track you are interested in * the type of your slot (talk/workshop/panel discussion) * your topic headline * your topic description which can brief (does not need to exceed a couple of lines) but should provide a reasonable summary of your talk * the dates of your stay at the event + (optional) preferred day for your slot * length of the slot if you wish to do a workshop (all other slots will be limited to one hour - notify me in advance if you think that is not enough for you) Deadlines ====== Submissions are accepted until and including the 28th of February. Everyone missing this deadline still has the opportunity to apply for a lightening talk slot. These slots can be acquired by simply contacting me during the event. The list of registered lightening talks will be published in the battlemesh wiki. The final program will be made available in the aforementioned wiki during the first week of March. If you have any question or suggestion, please let me know. Regards, Marek

12 years, 1 month

[B.A.T.M.A.N.] HNAs Announcements and Roaming management v2]

by Antonio Quartulli

Hello to everyone, This is the second version of the HNAs announcement mechanism/Roaming management paper. Please, consider it still a draft. A lot of things have changed since the previous version of this paper. As usual, feel free to comment it. I'll wait for your feedback :) Link: http://www.open-mesh.org/attachment/wiki/hna-improvements/handover.pdf Ragards, -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto "Che" Guevara

12 years, 1 month

[B.A.T.M.A.N.] Reordered rcu refcounting

by Sven Eckelmann

Hi, I told Linus and Marek that the implementation of some datastructures using reference counting and RCUs must be redesigned. The problem is that call_rcu should only be used when the reference count is zero because multiple call_rcu cannot be initiated at the same time. The next problem is that we may try to access an element with the refcount 0 when we try to traverse a rcu protected list. This problem cannot be solved by kref - thus we have to use atomic_t again to _not_ increase the reference count when it was already zero. Marek asked me what we must change - I try to summarize those things in the following patches. They aren't tested and should only be seen as suggestions what must be done to finish the "remove orig_hash lock"-patches. If you try these patches then please keep in mind that they will sell your soul to the next confectioner (for some cookies or a pie). More information can be found inside Documentation/RCU/rcuref.txt Btw, maybe I've found a bug inside the find_router with enabled bonding (see "BUG" in patch 4). Best regards, Sven

12 years, 1 month

[B.A.T.M.A.N.] Connecting through Batman advanced interface

by Clemens John

Hi, I have a special question on confgurating our batman advanced setup. We have a Tinc VPN on tap0, and behind this VPN is a dhcp server and an internet gateway which is reachable trough the ip 10.18.0.1. On the router I have ath1, an adhoc wlan device, on which batman advanced is sending packagets. Now bat0 and tap0 are brindged to br-mesh. Like you can see in the configuration: root@Floh:~# cat /etc/config/network [...] config 'interface' 'mesh' option 'type' 'bridge' option 'ifname' 'bat0 tap0' option 'stp' '1' [...] root@Floh:~# cat /etc/config/batman-adv config 'mesh' 'bat0' option 'interfaces' 'ath1' option 'orig_interval' option 'log_level' [batman] [client]-->[adhoc ath1]-->[bat0][br-mesh][tap0]-->internet-->[gateway/dhcp] Other nodes running the same configuration but not connecting trought vpn can connect to the dhcp server through batman advanced and the adhoc device. If a client (laptop) without batman advanced tries to connect, it has no success because it does not get an I address. What can I do? I can not open a second wifi device in ap mode and add it to mesh. I know that this would be the best way but I´m trying this on an wrt54g and the b43 driver does not support multi essid. Regards Clemens

12 years, 1 month

[B.A.T.M.A.N.] Weighting the local packet count; Optimizations for multi-interface nodes

by Daniel Seither

Hi there, I found an interesting paper today that covers mobility of some nodes in a batman-adv network: > Stefano Annese, Claudio Casetti, Carla F. Chiasserini, Paolo > Cipollone, Andrea Ghittino, and Massimo Reineri. 2009. Assessing > mobility support in mesh networks. In Proceedings of the 4th ACM > international workshop on Experimental evaluation and > characterization (WINTECH '09). http://portal.acm.org/citation.cfm?id=1614297 Unfortunately, the paper is not freely available on the web. If you're blessed with access to the ACM digital library by your school or employer, you can download it free of charge; in other cases you'll have to buy it for USD 15. In the following, I will summarize relevant parts: I) Weighting the local packet count The authors found that when each entry in the sliding window is weighed with the same weight as it is done in the current version of batman-adv, routing loops can occur when mobility is present. They greatly improve their results by weighting with the following function (i = 0..S-1 where S is the window size; 0 means freshest packet): weight(i) := max(1, floor(i * S / e^i)) This function seems to be suboptimal as it weights entry 0 with 1 while the following few entries are boosted with a weight of up to 20 (see attachment). Adding 1 to i should deal with this flaw. However, this weighting function lead to big improvements in the authors' simulations, so I think you are on the right track when thinking about introducing some kind of weighting or moving average to boost the weight of current packets. Here's the Octave/Matlab code I used to create the plot (if you want to do plots for other weighting functions that are discussed, just replace the definition of w and don't forget to use .* and ./ instead of * and / to enforce elementwise operations): > x = 0:63 > w = max(1, x.*64./exp(x)) > stem(x,w) > xlabel('age') > ylabel('weight') II) Optimizations for multi-interface nodes The authors used nodes with 2 radios. They did roughly the following on the mobile nodes (not on the fixed ones): 1) In regular intervals, scan the forwarding tables for each interface to check if any neighbors are known. If an interface has no contact to any neighbor, go to 2) 2) Use the interface without known neighbors to scan all channels except the channel that the other interface is listening to. Don't send OGMs but simply listen for OGMs from other stations. If a channel is found that has a neighbor sending, stay on this channel and start to behave like a normal batman-adv node (send OGMs etc.). I'm not sure if this will be benefitial in other scenarios than in the vehicular network scenario of the paper, but I wanted to share my findings with you. - Daniel

12 years, 1 month

[B.A.T.M.A.N.] [PATCH] batctl: add raw wifi packet decapsulation support

by Marek Lindner

Signed-off-by: Marek Lindner <lindner_marek(a)yahoo.de> --- batctl/tcpdump.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++++++- batctl/tcpdump.h | 49 +++++++++++++++++++++++++ 2 files changed, 152 insertions(+), 1 deletions(-) diff --git a/batctl/tcpdump.c b/batctl/tcpdump.c index 4bff970..bdf81bc 100644 --- a/batctl/tcpdump.c +++ b/batctl/tcpdump.c @@ -29,6 +29,7 @@ #include <sys/time.h> #include <arpa/inet.h> #include <net/if.h> +#include <net/if_arp.h> #include <netinet/in.h> #include <netinet/ip.h> #include <netinet/tcp.h> @@ -458,6 +459,75 @@ static void parse_eth_hdr(unsigned char *packet_buff, ssize_t buff_len, int read } } +static void parse_wifi_hdr(unsigned char *packet_buff, ssize_t buff_len, int read_opt, int time_printed) +{ + struct ether_header *eth_hdr; + struct ieee80211_hdr *wifi_hdr; + unsigned char *shost, *dhost; + uint16_t fc; + int hdr_len; + + if (buff_len <= (ssize_t)PRISM_HEADER_LEN) + return; + + buff_len -= PRISM_HEADER_LEN; + packet_buff += PRISM_HEADER_LEN; + + /* we assume a minimum size of 38 bytes + * (802.11 data frame + LLC) + * before we calculate the real size */ + if (buff_len <= 38) + return; + + wifi_hdr = (struct ieee80211_hdr *)packet_buff; + fc = wifi_hdr->frame_control; + + /* not carrying payload */ + if ((fc & IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_DATA) + return; + + /* encrypted packet */ + if (fc & IEEE80211_FCTL_PROTECTED) + return; + + shost = wifi_hdr->addr2; + if (fc & IEEE80211_FCTL_FROMDS) + shost = wifi_hdr->addr3; + else if (fc & IEEE80211_FCTL_TODS) + shost = wifi_hdr->addr4; + + dhost = wifi_hdr->addr1; + if (fc & IEEE80211_FCTL_TODS) + dhost = wifi_hdr->addr3; + + hdr_len = 24; + if ((fc & IEEE80211_FCTL_FROMDS) && (fc & IEEE80211_FCTL_TODS)) + hdr_len = 30; + + if (fc & IEEE80211_STYPE_QOS_DATA) + hdr_len += 2; + + /* LLC */ + hdr_len += 8; + hdr_len -= sizeof(struct ether_header); + + if (buff_len <= hdr_len) + return; + + buff_len -= hdr_len; + packet_buff += hdr_len; + + eth_hdr = (struct ether_header *)packet_buff; + memmove(eth_hdr->ether_shost, shost, ETH_ALEN); + memmove(eth_hdr->ether_dhost, dhost, ETH_ALEN); + + /* printf("parse_wifi_hdr(): ether_type: 0x%04x\n", ntohs(eth_hdr->ether_type)); + printf("parse_wifi_hdr(): shost: %s\n", ether_ntoa_long((struct ether_addr *)eth_hdr->ether_shost)); + printf("parse_wifi_hdr(): dhost: %s\n", ether_ntoa_long((struct ether_addr *)eth_hdr->ether_dhost)); */ + + parse_eth_hdr(packet_buff, buff_len, read_opt, time_printed); +} + int tcpdump(int argc, char **argv) { struct ifreq req; @@ -526,6 +596,27 @@ int tcpdump(int argc, char **argv) memset(&req, 0, sizeof (struct ifreq)); strncpy(req.ifr_name, dump_if->dev, IFNAMSIZ); + res = ioctl(dump_if->raw_sock, SIOCGIFHWADDR, &req); + if (res < 0) { + printf("Error - can't create raw socket (SIOCGIFHWADDR): %s\n", strerror(errno)); + close(dump_if->raw_sock); + goto out; + } + + dump_if->hw_type = req.ifr_hwaddr.sa_family; + + switch (dump_if->hw_type) { + case ARPHRD_ETHER: + case ARPHRD_IEEE80211_PRISM: + break; + default: + printf("Error - interface '%s' is of unknown type: %i\n", dump_if->dev, dump_if->hw_type); + goto out; + } + + memset(&req, 0, sizeof (struct ifreq)); + strncpy(req.ifr_name, dump_if->dev, IFNAMSIZ); + res = ioctl(dump_if->raw_sock, SIOCGIFINDEX, &req); if (res < 0) { @@ -588,7 +679,18 @@ int tcpdump(int argc, char **argv) continue; } - parse_eth_hdr(packet_buff, read_len, read_opt, 0); + switch (dump_if->hw_type) { + case ARPHRD_ETHER: + parse_eth_hdr(packet_buff, read_len, read_opt, 0); + break; + case ARPHRD_IEEE80211_PRISM: + parse_wifi_hdr(packet_buff, read_len, read_opt, 0); + break; + default: + /* should not happen */ + break; + } + fflush(stdout); } diff --git a/batctl/tcpdump.h b/batctl/tcpdump.h index f98d63f..f4276dc 100644 --- a/batctl/tcpdump.h +++ b/batctl/tcpdump.h @@ -23,6 +23,10 @@ #include <netpacket/packet.h> #include "list-batman.h" +#ifndef ARPHRD_IEEE80211_PRISM +#define ARPHRD_IEEE80211_PRISM 802 +#endif + #define DUMP_TYPE_BATOGM 1 #define DUMP_TYPE_BATICMP 2 #define DUMP_TYPE_BATUCAST 4 @@ -31,11 +35,21 @@ #define DUMP_TYPE_BATFRAG 32 #define DUMP_TYPE_NONBAT 64 +#define IEEE80211_FCTL_FTYPE 0x000c +#define IEEE80211_FCTL_TODS 0x0100 +#define IEEE80211_FCTL_FROMDS 0x0200 +#define IEEE80211_FCTL_PROTECTED 0x4000 + +#define IEEE80211_FTYPE_DATA 0x0008 + +#define IEEE80211_STYPE_QOS_DATA 0x0080 + struct dump_if { struct list_head list; char *dev; int32_t raw_sock; struct sockaddr_ll addr; + int32_t hw_type; }; struct vlanhdr { @@ -43,4 +57,39 @@ struct vlanhdr { u_int16_t ether_type; } __attribute__ ((packed)); +struct ieee80211_hdr { + u_int16_t frame_control; + u_int16_t duration_id; + u_int8_t addr1[6]; + u_int8_t addr2[6]; + u_int8_t addr3[6]; + u_int16_t seq_ctrl; + u_int8_t addr4[6]; +} __attribute__ ((packed)); + +struct prism_item { + u_int32_t did; + u_int16_t status; + u_int16_t len; + u_int32_t data; +}; + +struct prism_header { + u_int32_t msgcode; + u_int32_t msglen; + u_int8_t devname[16]; + struct prism_item hosttime; + struct prism_item mactime; + struct prism_item channel; + struct prism_item rssi; + struct prism_item sq; + struct prism_item signal; + struct prism_item noise; + struct prism_item rate; + struct prism_item istx; + struct prism_item frmlen; +}; + +#define PRISM_HEADER_LEN sizeof(struct prism_header) + int tcpdump(int argc, char **argv); -- 1.7.2.3

12 years, 1 month

[B.A.T.M.A.N.] pull request: batman-adv 2011-01-29

by Sven Eckelmann

Hi, I would like to propose following changes for net-2.6.git/2.6.38 which fixes some bugs in the fragmentation and vis code. There are also some minor cleanup patches available. If you don't want to merge those cleanup patches then please look bellow the first diffstat for an alternative way to get only the bugfixes. thanks, Sven The following changes since commit aa0adb1a85e159cf57f0e11282bc6c9e3606a5f3: batman-adv: Use "__attribute__" shortcut macros (2011-01-16 03:25:19 +0100) are available in the git repository at: git://git.open-mesh.org/ecsv/linux-merge.git batman-adv/merge Linus Lüssing (1): batman-adv: Fix kernel panic when fetching vis data on a vis server Simon Wunderlich (1): batman-adv: remove unused parameters Sven Eckelmann (11): batman-adv: Create roughly equal sized fragments batman-adv: Calculate correct size for merged packets batman-adv: Remove vis info on hashing errors batman-adv: Remove vis info element in free_info batman-adv: Make vis info stack traversal threadsafe batman-adv: Remove dangling declaration of hash_remove_element batman-adv: Remove unused definitions batman-adv: Remove declaration of batman_skb_recv batman-adv: Remove unused variables batman-adv: Update copyright years batman-adv: Merge README of v2011.0.0 release Documentation/networking/batman-adv.txt | 16 ++++++++-------- net/batman-adv/Makefile | 2 +- net/batman-adv/aggregation.c | 2 +- net/batman-adv/aggregation.h | 2 +- net/batman-adv/bat_debugfs.c | 6 ++---- net/batman-adv/bat_debugfs.h | 2 +- net/batman-adv/bat_sysfs.c | 2 +- net/batman-adv/bat_sysfs.h | 2 +- net/batman-adv/bitarray.c | 2 +- net/batman-adv/bitarray.h | 2 +- net/batman-adv/gateway_client.c | 2 +- net/batman-adv/gateway_client.h | 2 +- net/batman-adv/gateway_common.c | 2 +- net/batman-adv/gateway_common.h | 2 +- net/batman-adv/hard-interface.c | 13 ++++++++++--- net/batman-adv/hard-interface.h | 6 +----- net/batman-adv/hash.c | 2 +- net/batman-adv/hash.h | 7 +------ net/batman-adv/icmp_socket.c | 2 +- net/batman-adv/icmp_socket.h | 2 +- net/batman-adv/main.c | 2 +- net/batman-adv/main.h | 17 +---------------- net/batman-adv/originator.c | 4 ++-- net/batman-adv/originator.h | 2 +- net/batman-adv/packet.h | 3 ++- net/batman-adv/ring_buffer.c | 2 +- net/batman-adv/ring_buffer.h | 2 +- net/batman-adv/routing.c | 26 ++++++++------------------ net/batman-adv/routing.h | 5 ++--- net/batman-adv/send.c | 6 +++--- net/batman-adv/send.h | 2 +- net/batman-adv/soft-interface.c | 2 +- net/batman-adv/soft-interface.h | 2 +- net/batman-adv/translation-table.c | 2 +- net/batman-adv/translation-table.h | 2 +- net/batman-adv/types.h | 2 +- net/batman-adv/unicast.c | 15 ++++++++++----- net/batman-adv/unicast.h | 25 ++++++++++++++++++++++++- net/batman-adv/vis.c | 16 +++++++++------- net/batman-adv/vis.h | 2 +- 40 files changed, 109 insertions(+), 108 deletions(-) If you don't want to merge those cleanup patches, please merge only the bugfixes. They can be found in the branch batman-adv/merge-bugfixonly. The following changes since commit aa0adb1a85e159cf57f0e11282bc6c9e3606a5f3: batman-adv: Use "__attribute__" shortcut macros (2011-01-16 03:25:19 +0100) are available in the git repository at: git://git.open-mesh.org/ecsv/linux-merge.git batman-adv/merge-bugfixonly Linus Lüssing (1): batman-adv: Fix kernel panic when fetching vis data on a vis server Sven Eckelmann (5): batman-adv: Create roughly equal sized fragments batman-adv: Calculate correct size for merged packets batman-adv: Remove vis info on hashing errors batman-adv: Remove vis info element in free_info batman-adv: Make vis info stack traversal threadsafe net/batman-adv/packet.h | 1 + net/batman-adv/routing.c | 2 +- net/batman-adv/unicast.c | 13 +++++++++---- net/batman-adv/unicast.h | 23 +++++++++++++++++++++++ net/batman-adv/vis.c | 14 ++++++++------ 5 files changed, 42 insertions(+), 11 deletions(-)

12 years, 1 month

[B.A.T.M.A.N.] B.A.T.M.A.N.-Advanced Multicast Optimizations, v2

by Linus Lüssing

Hi everyone, Here's the next series of patches which should address the comments I got for the first one. Thanks for all the feedback! Changelog: * rebasing to commit [65e0869478bce153a799c0e774a117ba5fc78025], using new orig_hash methods * putting seqno before ttl, 4 byte aligning mcast_packet [01/20] * adapted compat.h to not use custom lock macros, instead only one macro for netif_addr_lock_bh() in case of older kernel versions * merged spinlock-irqsave-to-bh commit into previous commits [20/20] * moved mcast_may_optimize() to soft-interface.c [18/20], removed inlining (won't optimize much anyway...) * purge_mcast_forw_table, splitted list operations into separate functions [12/20] * use batman_if refcounting to reduce the time of rcu-locking [13/20] * do not create nexthop entry if according batman_if is NULL [13/20] * route_mcast_packet, split into separat functions [13/20] * fix typo "seperate" [13/20] * fix typo "i.g." [08/20] * COMPAT_VERSION to 14 [01/20] * use rcu-locking+refcounting for orig_node, remove orig_hash_lock [07/20], [17/20] * made checkpatch-clean * use __packed instead of __attribute_((packed)) [01/20] * change tracker_packet_for_each_dest macro [07/20]: make a "break" in this macro to behave like usual, export parts from macro into own functions TODO: * directly prepare mcast-tracker-packet in sk_buff * only create methods / variables in patches that need them * update mcast-doc * upload updated mcast-doc to wiki maybe TODO? * use hlist instead of list for mcast-table? * use rcu-locking / refcounting for mcast_forw_table? Cheers, Linus

12 years, 1 month

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N January 2011