-------- Original-Nachricht --------
Datum: Fri, 22 Jan 2010 13:16:09 +0100 Von: Sven Eckelmann sven.eckelmann@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
Juha Ylönen wrote:
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?
No, one direction is ok. What we can see here is that we have a < 50 bytes packet and it is seems to be send correctly. So maybe the problem is not related to "small" packets.
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.
Ok, so we have a real simple example here. We see that we have a "large" ethernet frame (unlike batman-adv) and a "unnormal" ethernet type. So maybe you could forward rawsend.log and rawsend.c to the driver developers. They should be able to find and fix the problem with such a real small example. Or does anyone see a related problem in rawsend.c?
What is the batmand stuff for?
Best regards, Sven
-------- Original-Nachricht --------
Datum: Sun, 24 Jan 2010 23:03:48 +0100 Von: Sven Eckelmann sven.eckelmann@gmx.de
Ok, so we have a real simple example here. We see that we have a "large" ethernet frame (unlike batman-adv) and a "unnormal" ethernet type. So maybe you could forward rawsend.log and rawsend.c to the driver developers. They should be able to find and fix the problem with such a real small example. Or does anyone see a related problem in rawsend.c?
Thanks for the analysis, I'll try to get this solved with the driver.
What is the batmand stuff for?
I'm evaluating the batmand for routing multicast audiostream in a mesh. Batmand seems to be doing the routing better than olsr, but the lack of multicast is a problem, hence batman-adv.
I tried batman-adv and multicast routing with couple of laptops, but it did not work quite well. Some packages seemed to be left ping-ponging in the mesh, while others disappeared completely. Is batman-adv multicast being actively used somewhere?
-Juha
On Tuesday 26 January 2010 15:20:58 Juha Ylönen wrote:
I tried batman-adv and multicast routing with couple of laptops, but it did not work quite well. Some packages seemed to be left ping-ponging in the mesh, while others disappeared completely. Is batman-adv multicast being actively used somewhere?
I know that Freifunk Luebeck was experimenting with multicast but I don't know where that stands. Maybe Linus could share some insights ?
Could you be a bit more specific on the multicast problems you see ? As always: If you provide logs, tcpdump and/or wireshark dumps we can help otherwise it is quite difficult.
Cheers, Marek
b.a.t.m.a.n@lists.open-mesh.org
-
"Juha Ylönen" -
Marek Lindner -
Sven Eckelmann