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] batman-adv: Record route for ICMP messages
by Daniel Seither 15 Feb '10

15 Feb '10

The standard layer 3 ping utility can use the record route option of IP to collect route data for sent ping messages (ping -R). This patch introduces comparable functionality for batman-adv ICMP messages. The patch modifies the batman ICMP packet format such that up to 17 MAC addresses can be recorded (sufficient for up to 8 hops per direction). batctl is extended to recognize the -R option for the ping subcommand. The output should be the same as for the standard iputils ping program. For this, the destination host is printed two times. In device.c, the sender's MAC address is inserted at the first position when receiving a ping message from batctl and RR is enabled (rr_cur > 0). In routing.c, each forwarding node then appends its own MAC address. This patch could be improved by dynamically growing the packet when a MAC address is to be added to the recorded route instead of statically allocating a buffer of fixed length. Signed-off-by: Daniel Seither <post(a)tiwoc.de> --- Index: batman-adv-kernelland/packet.h =================================================================== --- batman-adv-kernelland/packet.h (revision 1568) +++ batman-adv-kernelland/packet.h (working copy) @@ -60,6 +60,8 @@ #define BAT_PACKET_LEN sizeof(struct batman_packet) +#define BAT_RR_LEN 96 + struct icmp_packet { uint8_t packet_type; uint8_t version; /* batman version field */ @@ -69,6 +71,8 @@ uint8_t orig[6]; uint16_t seqno; uint8_t uid; + uint8_t rr_cur; + uint8_t rr[BAT_RR_LEN]; } __attribute__((packed)); struct unicast_packet { Index: batman-adv-kernelland/device.c =================================================================== --- batman-adv-kernelland/device.c (revision 1568) +++ batman-adv-kernelland/device.c (working copy) @@ -268,6 +268,12 @@ memcpy(icmp_packet.orig, batman_if->net_dev->dev_addr, ETH_ALEN); + + if (icmp_packet.rr_cur) { + memcpy(icmp_packet.rr, + batman_if->net_dev->dev_addr, + ETH_ALEN); + } send_raw_packet((unsigned char *)&icmp_packet, sizeof(struct icmp_packet), Index: batman-adv-kernelland/routing.c =================================================================== --- batman-adv-kernelland/routing.c (revision 1568) +++ batman-adv-kernelland/routing.c (working copy) @@ -862,6 +862,12 @@ icmp_packet = (struct icmp_packet *) skb->data; + /* add record route information if not full */ + if (icmp_packet->rr_cur && icmp_packet->rr_cur < BAT_RR_LEN / ETH_ALEN) { + memcpy(&(icmp_packet->rr[icmp_packet->rr_cur * ETH_ALEN]), ethhdr->h_dest, ETH_ALEN); + icmp_packet->rr_cur++; + } + /* packet for me */ if (is_my_mac(icmp_packet->dst)) return recv_my_icmp_packet(skb); Index: batctl/ping.c =================================================================== --- batctl/ping.c (revision 1568) +++ batctl/ping.c (working copy) @@ -48,6 +48,7 @@ printf(" \t -h print this help\n"); printf(" \t -i interval in seconds\n"); printf(" \t -t timeout in seconds\n"); + printf(" \t -R record route\n"); } void sig_handler(int sig) @@ -66,18 +67,19 @@ { struct icmp_packet icmp_packet_out, icmp_packet_in; struct timeval tv; - struct ether_addr *dst_mac = NULL; - struct bat_host *bat_host; + struct ether_addr *dst_mac = NULL, *rr_mac = NULL; + struct bat_host *bat_host, *rr_host; ssize_t read_len; fd_set read_socket; int ret = EXIT_FAILURE, ping_fd = 0, res, optchar, found_args = 1; - int loop_count = -1, loop_interval = 1, timeout = 1; + int loop_count = -1, loop_interval = 1, timeout = 1, rr = 0, i; unsigned int seq_counter = 0, packets_out = 0, packets_in = 0, packets_loss; - char *dst_string, *mac_string; + char *dst_string, *mac_string, *rr_string; double time_delta; float min = 0.0, max = 0.0, avg = 0.0; + uint8_t last_rr_cur = 0, last_rr[BAT_RR_LEN]; - while ((optchar = getopt(argc, argv, "hc:i:t:")) != -1) { + while ((optchar = getopt(argc, argv, "hc:i:t:R")) != -1) { switch (optchar) { case 'c': loop_count = strtol(optarg, NULL , 10); @@ -100,6 +102,10 @@ timeout = 1; found_args += ((*((char*)(optarg - 1)) == optchar ) ? 1 : 2); break; + case 'R': + rr = 1; + found_args++; + break; default: ping_usage(); return EXIT_FAILURE; @@ -147,6 +153,8 @@ icmp_packet_out.msg_type = ECHO_REQUEST; icmp_packet_out.ttl = 50; icmp_packet_out.seqno = 0; + icmp_packet_out.rr_cur = (rr) ? 1 : 0; + memset(&icmp_packet_out.rr, 0, BAT_RR_LEN); printf("PING %s (%s) %zu(%zu) bytes of data\n", dst_string, mac_string, sizeof(icmp_packet_out), sizeof(icmp_packet_out) + 28); @@ -204,10 +212,34 @@ switch (icmp_packet_in.msg_type) { case ECHO_REPLY: time_delta = end_timer(); - printf("%zd bytes from %s icmp_seq=%hu ttl=%d time=%.2f ms\n", + printf("%zd bytes from %s icmp_seq=%hu ttl=%d time=%.2f ms", read_len, dst_string, ntohs(icmp_packet_in.seqno), icmp_packet_in.ttl, time_delta); + if (icmp_packet_in.rr_cur) { + if (last_rr_cur == icmp_packet_in.rr_cur && !memcmp(last_rr, icmp_packet_in.rr, BAT_RR_LEN)) { + printf("\t(same route)\n"); + } else { + printf("\nRR: "); + for (i = 0; i < BAT_RR_LEN/ETH_ALEN && i < icmp_packet_in.rr_cur; i++) { + rr_mac = (struct ether_addr *)&icmp_packet_in.rr[i*ETH_ALEN]; + rr_host = bat_hosts_find_by_mac((char *)rr_mac); + if (rr_host) + rr_string = rr_host->name; + else + rr_string = ether_ntoa_long(rr_mac); + printf("\t%s\n", rr_string); + if (memcmp(rr_mac, dst_mac, ETH_ALEN) == 0) + printf("\t%s\n", rr_string); + } + printf("\n"); + + last_rr_cur = icmp_packet_in.rr_cur; + memcpy(last_rr, icmp_packet_in.rr, BAT_RR_LEN); + } + } else + printf("\n"); + if ((time_delta < min) || (min == 0.0)) min = time_delta; if (time_delta > max)

2 3

[B.A.T.M.A.N.] race condition with activate_module?
by Linus Lüssing 14 Feb '10

14 Feb '10

Hi guys, I think I've seen this bug a couple of times but I've never been able to reproduce it. Now I added a little patch to slow down the activate_module() procedure and the bug occures every time now. My question is, did I make a race condition apparent or did I introduce a bug with this patch? Cheers, Linus

3 4

[B.A.T.M.A.N.] Can't load batman-module on 2.6.26
by Linus Lüssing 13 Feb '10

13 Feb '10

And next thing, batman-adv is crashing on Debian stable with a 2.6.26 kernel. The call trace is showing bat_printk() right after insmodding the batman-adv kernel module from the current maintenance branch. (And also thanks to Chris/|x|, I guess you've been experiencing the same problem on your router with the maintenance branch.) Cheers, Linus

3 7

[B.A.T.M.A.N.] batman-adv 0.2 on openwrt
by x＠muc.ccc.de 13 Feb '10

13 Feb '10

hi! as openwrt 8.09.2 still ships with an old batman-adv 0.1 module, i tried to compile a batman-adv 0.2 module. the compile worked, the module loads, originators see each other, but on the openwrt box on bat0 tx packets stays 0 while tx dropped obviously increases with each packet to be transmitted. the setup: laptop debian squeeze amd64 2.6.31.12 batman-adv 0.2 laptop debian sid x86 2.6.32 batman-adv 0.2 ap openwrt 8.09.2 ixp4xx/armeb (cambria) 2.6.26.8 batman-adv 0.2 the facts: all bridges and iptables switched off. with plain ip on the wlan interfaces, pinging between all nodes works fine (when within reach). all three nodes have the respective two other nodes listed as originators, and if all are within reach of each other, with originator=nexthop. pinging via bat0 works between the two laptops. pinging the laptops via bat0 from the ap results in no packets seen on the laptops' bat0. pinging the ap via bat0 from a laptop results in incoming arp-requests and outgoing arp-replies seen on the ap's bat0 - but again, the arp-replies aren't seen on the laptops' bat0 (nor on the laptops' wlan interfaces). on the ap's bat0, the tx packets counter stays at 0, while the tx dropped counter seems to increase with each packet that should be sent over it. i enabled all logging (15) on the ap and the laptops, but found no hint in there... the only interesting messages seem to be in dmesg, saying: protocol 4305 is buggy, dev ath1 so to me it seems like all tx packets on bat0 on the ap are dropped, while everything else seems to work as it's supposed to. i then tried to compile the current (r1568) version from svn for the ap. again, the compile worked, but the ap just freezes immediately when i try to load it. i thought about trying a newer kernel for the ap, but from openwrt there's a special cambria kernel and i haven't found its config and also don't know what patches might have been applied, so i haven't had much hope for any helpful result along this path... regards, Chris

3 11

[B.A.T.M.A.N.] 403 Forbidden message while trying to download BMX pdf file
by Julio Cesar Puigpinos 10 Feb '10

10 Feb '10

While trying to download the BMX documentation http://downloads.open-mesh.net/batman/misc/bmx.pdf I get a 403 Forbidden message. Is there another link or can it be fixed? Saludos, Julio -- www.lugro-mesh.org.ar/ Wireless Mesh Networks Group www.lugro.org.ar GNU/Linux User Group Rosario, Argentina Slackware rulez :P www.slackware.org NO A LA MATRICULA!!!: http://noalamatricula.wordpress.com/

3 4

[B.A.T.M.A.N.] batman-adv and IPSec
by ecfu 28 Jan '10

28 Jan '10

Can I use IPSec with batman-adv? Has anyone ever done this? Is there anything special that needs to be done or because I am using batman-adv, this is transparent? Thanks

3 2

[B.A.T.M.A.N.] git changes break OpenWRT package
by Gus Wirth 28 Jan '10

28 Jan '10

It seems that changes made to the git sources have broken OpenWRT batman-adv package. The OpenWRT package points to: http://git.open-mesh.org/snapshots for kernel code. But that directory has been cleaned out. There also doesn't appear to be any backup packages at: http://downloads.openwrt.org/sources Is there any way to put the old snapshots back? Or since the kernel module can be built from source checked out from subversion, I guess the batman-adv package can be redone to only use the subversion code and not any maintenance code. Has anyone done this yet? I can't tell who created the original package so I suspect it is someone here. Gus

2 3

Re: [B.A.T.M.A.N.] batman-adv on different archs
by "Juha Ylönen" 26 Jan '10

26 Jan '10

-------- Original-Nachricht -------- > Datum: Fri, 22 Jan 2010 13:16:09 +0100 > Von: Sven Eckelmann <sven.eckelmann(a)gmx.de> > > Cannot find the driver at http://www.csr.com/products/UF1050_over.htm They have files at csrsupport.com, but I can't actually find the driver sources there either. But the LICENSE file included says they're GPLv2. I'll check from the guy who I got the sources from, since this is a bit confusing. > So please test and capture > * rawsend from ARM > * ping between laptop and arm > * a "ping -s 1" between laptop and arm > > I hope that tests help to see were the problem really is. If the ping -s 1 > works, can you please also capture a some packets of batman-adv 0.2? Logs for all cases attached. I pinged from arm to laptop, would you have liked it in the other direction too? Rawsend from arm->laptop didn't work, the packets end up in the laptop as llc packets, so apparently they were mangled by the driver. rawsend from laptop->arm worked fine, which is included in the rawsend.log file. I'll try out with a later driver version (it has bad stability issues, which is why we use older version in the device). -Juha -- Haiti-Nothilfe! Helfen Sie per SMS: Sende UIHAITI an die Nummer 81190. Von 5 Euro je SMS (zzgl. SMS-Gebühr) gehen 4,83 Euro an UNICEF.

3 3

Re: [B.A.T.M.A.N.] batman-adv on different archs
by "Juha Ylönen" 24 Jan '10

24 Jan '10

And a new try to send the log, previous was rather big and didn't get sent. This one is shorter and missing all the multicast traffic. -Juha -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02

6 13

[B.A.T.M.A.N.] State of batman-adv in mainline
by Andrew Lunn 24 Jan '10

24 Jan '10

Hi Folks Here is a quick summary of the state of batman in mainline. First a quick summary of how code gets into mainline in general. When Linus released a kernel version, eg 2.6.33, he opens the merge window for the next kernel version. This merge window is normally two weeks long. During these two weeks, all new development work which is intended for 2.6.34 is merged into his tree. At the end of the two weeks the first rc kernel is released, in this case 2.6.34-rc1. At this point no more development work can be merged, just bug fixes. Generally there is a new -rc kernel every week, for about 8 or 9 weeks. So after about three months, the kernel is released, and it all starts again. This two week merge window is a busy period with all sorts of patches come together. In the past this did not always go too well, patches collided and conflicted. To try to find out about such problems early, before the merge window, the linux-next tree was created. linux-next is roughly all the patches which will be merged in the next merge window. It contains ongoing development work from all over the place. If patches are going to clash, they will likely clash in linux-next and then developers know about such problems early. O.K. so what is the status of batman-adv? Our first patch landed by GregKH just before the merge window for 2.6.33 opened. This patch made it into 2.6.33-rc1. So at around the end of march when 2.6.33 is released, we will be in mainline. All patches submitted after this first big one was after the merge window closed. So they are currently queued up by GregKH. They appear in linux-next and should be accepted during the 2.6.34 merge window. So we have a few issues to address in the next couple of weeks. 1) We should make it clear on www.open-mesh.org which version of batctl should be used with 2.6.33. The trunk version will not work correctly, an older version is needed. Probably we want to make a tarball release and put it somewhere prominent on the website. 2) We still have the chance to get bug fixes into 2.6.33. Is there anything in 2.6.33-rc5 which can cause oopses, deadlocks, etc? 3) It would be nice if the community actually downloaded 2.6.33-rc5 and tested it. Please report any problems you find. 4) We should review what is currently in subversion but not yet pushed to GregKH ready for 2.6.34. eg gateway support, vis server startup fix, bonding, etc. In another email i will produce a list of patches we should consider. All this work is currently happening in staging. Once 2.6.33 is released we will get a bit more exposure and hopefully trigger some discussion. 2.6.34-rc1 will be a big step forward and i think at that point we should approach the linux networking guys and ask for a review. That would be one of the first steps of getting out of staging and somewhere under the net directory. Andrew

3 6

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