Hey guys,
I've been installing a 9 node setup here in our cellar. They are
all running B.A.T.M.A.N. adv 0.2.1-beta r1545 (so the current
batman-adv maintance version in OpenWRT).
The result over night:
- 1x: bat_events: page allocation failure
- 3x: WARNING: at net/sched/sch_generic.c:226 0x801c3554()
(those 3 had TQ values of about 10-15 in batctl)
For the last error, I'm not sure if this is related to batman-adv
or to the madwifi driver. I was using OpenWRT trunk 18405 on all
routers.
I'm attaching some backtraces. Sorry again I can't get more out of
them than that with ksymoops. The first two ones are the
bat_events problem, the others the scheduling thingy.
Cheers, Linus
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
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
-------- 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.
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
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
-------- Original-Nachricht --------
> Datum: Thu, 21 Jan 2010 18:57:52 +0100
> Von: Sven Eckelmann <sven.eckelmann(a)gmx.de>
> Yes, but doesn't explain why there is no batman-adv packet from ARM
> reaching
> the laptop and the other way around. batman-adv is a layer bellow and has
> nearly nothing to do with the stuff which runs over it (the only thing
> which
> accesses the layer over it should be the gateway stuff).
>
> @Juha, I found time and looked a little bit at the stuff which came from
> the
> ARM in the last log. Wireshark means that it is a Raw ethernet packet. And
> thinks that the stuff attached is a IPX packet.... but reading the raw
> data
> reveals that it should be the batman-packet.... with extra data between
> the
> ethernet header and the actual batman-adv packet. So the problem looks to
> me a
> little bit like hardware of the arm does something very stupid to our
> packets.
>
> I've attach a small picture to explain what I mean. The green part it the
> normal receiver and sender stuff for ethernet. The orange part is not
> explainable for me... Have we forgot some alignment stuff? Is your card
> adding
> some extra data? I am not sure what that could mean right now.
> The red thing is the ethernet type for batman-adv, pink the type of
> batman-adv
> packet, yellow the protocol version and light blue the flags for that
> packet.
> I don't know more color - so just marked the rest of the packet blue. The
> amount of bytes are correct and it looks fine to me.
>
> As anyone a good idea? Maybe a small capture of a normal ping test and a
> rawsend test between the both could help to understand the problem better.
> And
> can you maybe tell us what kind of hardware is used inside the arm for the
> eth1 device?
Hi,
This looks interesting, I've had problems with the wlan driver before but it has been quite stable for a while. Wlan chip in use is CSR UniFi 1050, with driver compiled from CSR supplied sources.
I'll try your rawsend and ping capturing during the weekend. Sorry for the bother in advance if this turns out to be due the crappy wlan driver (as said, it has been giving problems earlier, though I haven't seen any packet mangling before).
-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.
Hi,
I have a couple of questions regarding BATMAN and BATMAN-ADV
I do not understand what the transmission quality in OGMs is for. From my
reading of the RFC draft, route selection is done based on the number of
OGMs received for a specific destination within a sliding window of sequence
numbers. I did catch a comment in the source code about transmission
quality it being used for bidirectional link detection, but there I couldn't
find a mention of transmission quality in the draft RFC.
I have been looking at BATMAN and BATMAN-ADV OGMs in Wireshark. It seems
that the BATMAN L3 OGMs have 18 bytes of BATMAN information on top of the
802.11 header (24bytes) LLC (8 bytes) IP header (20 bytes). Comparatively,
the BATMAN-ADV OGMs comprise of a 802.11 header (24bytes) LLC (8 bytes) and
26 Bytes of BATMAN data. Now because Wireshark does not recognise BATMAN-ADV
frames. I don't know what is being used for the extra 8 bytes of batman
data. I guess the originator and receiver portions of the packet are now 6
byte MAC addresses rather than 4 byte IP addresses. However, this does not
account for extra 8 bytes used for BATMAN-ADV.
In the future, it seems like BATMAN-ADV will get the majority of the
developer attention. Other than not having to asign IP addresses, which does
seem pretty cool, I am finding it hard to see 'major' advantages of one
versus another. This advantage also seems to be slightly offset because it
now becomes harder to get gateway information. Is this right?
Does working at the data link layer make it easier to extract, neighbour
SNR's or bit rates from the wireless driver? What about power control? I'm
just throwing ideas around here (I haven't thought this through) but could
you have a power save mode whereby if the device is battery powered and has
> 8 neighbours, then slowly reduce the transmission power until neighbours
is < 4 or mains powered batman neighbours is <2.
Thank you very much for your time
Dave
Hi,
I've been trying to get my embedded project included in my mesh, but no success yet. Could anyone give a pointers what is going wrong?
I have batman-adv compiled on my laptop, and also for testing purposes on another laptop, they see each other and everything is fine. I used the same sources and compiled it cleanly on each.
The problem comes when I try to add my little ARM based linux box onto the group. Again same sources used (latest stable from the wiki), crosscompiles fine and I can load the module as normal on the box. Setup goes as it should on both the device and the laptop, and both systems seems to be running smoothly. But my laptop can only see the other laptop, and the device doesn't see anyone. The wireless net is working and I can ping each device directly if I assign IP's to the 'real' interfaces, but through bat0 nothing is found. Any idea what is going wrong?
---
I've also played with the batman daemon on the device, with it I the laptop and device can see each other just fine. The problem there is that apparently it doesn't really support multicast forwarding? i.e. If I have 3 devices A-B-C, where A does not have direct link to C (batman routes through B), sending a multicast from A can be received in B and vice versa, also same for C-B, but no messages from A to C. Will I have the same problem with batman-adv? Or can this be fixed on the daemon?
Best Regards
Juha
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
