batman-adv on different archs
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
Signature · 2 lines
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02
�ò� �� ��UKTn * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UKK�
2 2 ������ ��� $���� C @ � "�ܚ� "�ܚ�1 � x��UKj7 2 2 ������ ��� $���� C � e ��� ��� 2 g�M���UK{l * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UK��
2 2 ������ ��� $���� C @ � "�ܚ� "�ܚ�1 � x��UK�5 2 2 ������ ��� $���� C � f ��� ��� 2 g�M���UK * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UKk6 2 2 ������ ��� $���� C � g ��� ��� 2 g�M���UK:� * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UKVM
2 2 ������ ��� $���� C @ � "�ܚ� "�ܚ�1 � x��UK(� 2 2 ������ ��� $���� C � h ��� ��� 2 g�M���UK)� * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UKK� 2 2 ������ ��� $���� C @ � "�ܚ� "�ܚ�1 � x��UK�� 2 2 ������ ��� $���� C � i ��� ��� 2 g�M���UK� * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UK�� 2 2 ������ ��� $���� C @ � "�ܚ� "�ܚ�1 � x��UKYL 2 2 ������ ��� $���� C � j ��� ��� 2 g�M���UK�3 * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UK�� 2 2 ������ ��� $���� C @ � "�ܚ� "�ܚ�1 � x��UKI� 2 2 ������ ��� $���� C � k ��� ��� 2 g�M���UK�� * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UK�� 2 2 ������ ��� $���� C � l ��� ��� 2 g�M���UK�� * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UKIC 2 2 ������ ��� $���� C @ � "�ܚ� "�ܚ�1 � x��UK�� 2 2 ������ ��� $���� C � m ��� ��� 2 g�M���UK�� * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UK{ 2 2 ������ ��� $���� C @ � "�ܚ� "�ܚ�1 � x��UK˲ 2 2 ������ ��� $���� C � n ��� ��� 2 g�M���UK�� * * ������ "�ܚ�C � � "�ܚ� "�ܚ�2 � x>��UKb 2 2 ������ ��� $���� C @ � "�ܚ� "�ܚ�1 � x��UK-� 2 2 ������ ��� $���� C � o ��� ��� 2 g�M�
Quoted 2 lines · On Tuesday 19 January 2010 22:58:06 Juha Ylönen wrote:
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.
This log only contains packets from the Intel notebook. It seems the messages from the ARM device never leave the wifi card.
Before we dive into debugging the code I'd suggest you send us your complete interface configuration. Maybe the problem is much more simple than it seems. Complete configuration means: brctl show, ifconfig, cat /proc/net/batman- adv/interfaces (or batctl if) and ping output.
Regards,
Marek
-------- Original-Nachricht --------
Quoted 5 lines
Datum: Wed, 20 Jan 2010 10:15:59 +0800
Von: Marek Lindner <[email protected]>Complete configuration means: brctl show, ifconfig, cat
/proc/net/batman-adv/interfaces (or batctl if) and ping output.
Could be the first one in the list as brctl fails. CONFIG_BRIDGE is not configured in the device kernel. Is batman-adv dependent on this? I'll recompile the kernel and see what happens (it's a slow process), in the meanwhile, what other kernel configurations are needed for batman-adv?
-Juha
Signature · 2 lines
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Quoted 4 lines · On Wednesday 20 January 2010 17:29:04 Juha Ylönen wrote:
Could be the first one in the list as brctl fails.
CONFIG_BRIDGEis not
configured in the device kernel. Is batman-adv dependent on this? I'll recompile the kernel and see what happens (it's a slow process), in the meanwhile, what other kernel configurations are needed for batman-adv?
No, it is not required but bridging is the best way to connect batman-adv with non-mesh participants, therefore many people use bridging. It is easy to add the wrong interface to the wrong bridge and then strange things happen which is way it is on my checklist. ;)
Regards,
Marek
Quoted 5 lines · Juha Yl?nen
-------- Original-Nachricht --------
Quoted 3 lines
Datum: Wed, 20 Jan 2010 10:15:59 +0800
Von: Marek Lindner <[email protected]>
Quoted 8 lines
Quoted 2 lines
Complete configuration means: brctl show, ifconfig, cat
/proc/net/batman-adv/interfaces (or batctl if) and ping output.Could be the first one in the list as brctl fails.
CONFIG_BRIDGEis not configured in the device kernel. Is batman-adv dependent on this? I'll recompile the kernel and see what happens (it's a slow process), in the meanwhile, what other kernel configurations are needed for batman-adv?
Bridging is not a requirement.
However many uses typically use bridging to build bigger networks. They bridge bat0 with eth0 to form one big layer 2 network.
However you don't have to do this. I've run OSPF on the bat0 interface and just routed traffic over it just like any other network link in the network.
Andrew
Quoted 5 lines · Juha Ylönen
-------- Original-Nachricht --------
Quoted 3 lines
Datum: Wed, 20 Jan 2010 10:15:59 +0800
Von: Marek Lindner <[email protected]>
Quoted 7 lines
Quoted 2 lines
Complete configuration means: brctl show, ifconfig, cat
/proc/net/batman-adv/interfaces (or batctl if) and ping output.Could be the first one in the list as brctl fails.
CONFIG_BRIDGEis not
configured in the device kernel. Is batman-adv dependent on this? I'll recompile the kernel and see what happens (it's a slow process), in the meanwhile, what other kernel configurations are needed for batman-adv?
No, bridge stuff is not really a dependency. Only many configurations use is to bridge the bat0 and for example the ethernet interface together. The dependencies of 0.2 are currently PROC_FS and PACKET.
Just as side note for the futyre: Configure the mtu of bat0 to match the mtu of your other devices in the bridge or otherwise big packets will be dropped while bridging.
@Andrew: We don't depend on PACKET after the merge of the skb based transfers. Please remove it from Kconfig - we need NET instead.
Best regards,
Sven
-------- Original-Nachricht --------
Quoted 9 lines
Datum: Wed, 20 Jan 2010 10:15:59 +0800
Von: Marek Lindner <[email protected]>Before we dive into debugging the code I'd suggest you send us your complete
interface configuration. Maybe the problem is much more simple than it seems.
Complete configuration means: brctl show, ifconfig, cat/proc/net/batman-adv/interfaces (or batctl if) and ping output.
Here we go:
---
##x> brctl show
bridge name bridge id STP enabled interfaces
##> cat interfaces
[ active] eth1 00:11:f6:83:af:ab
##> ifconfig
bat0 Link encap:Ethernet HWaddr 32:21:CA:8E:37:DC
inet addr:10.0.1.39 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1476 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:468 (468.0 B)
eth1 Link encap:Ethernet HWaddr 00:11:F6:83:AF:AB
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:179 errors:0 dropped:0 overruns:0 frame:0 TX packets:268 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
RX bytes:6086 (5.9 KiB) TX bytes:10450 (10.2 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
##> route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 * 255.0.0.0 U 0 0 0 bat0
##> ping 10.0.1.40
PING 10.0.1.40 (10.0.1.40): 56 data bytes
--- 10.0.1.40 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
---
I also checked the return value for dev_queue_xmit in send.c and it was 0.
-Juha
-Juha
Signature · 2 lines
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
Hey,
Quoted 5 lines
0 bat0 ##> ping 10.0.1.40
PING 10.0.1.40 (10.0.1.40): 56 data bytes--- 10.0.1.40 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
actually, I meant the ping that you said would work and expected the config from both ends. Otherwise we can't see much. We know that the ping over batman does not work because the routes are not there ...
It might be useful to join us on irc to speed things up. Is that an option for you ? We idle in #batman on irc.freenode.org.
Cheers,
Marek
-------- Original-Nachricht --------
Quoted 2 lines
Datum: Thu, 21 Jan 2010 06:32:19 +0800
Von: Marek Lindner <[email protected]>
Hi,
Ok, here's another set:
---IN ARM DEVICE---
##> ifconfig
bat0 Link encap:Ethernet HWaddr BE:8F:67:10:32:A9
inet addr:10.1.1.33 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1476 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
RX bytes:768 (768.0 B) TX bytes:378 (378.0 B)
eth1 Link encap:Ethernet HWaddr 00:11:F6:83:AF:1C
inet addr:10.0.1.33 Bcast:10.0.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9842 errors:0 dropped:0 overruns:0 frame:0 TX packets:17276 errors:5 dropped:0 overruns:0 carrier:5 collisions:0 txqueuelen:1000
RX bytes:320656 (313.1 KiB) TX bytes:3038557 (2.8 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:784 (784.0 B) TX bytes:784 (784.0 B)
##> cat /proc/net/batman-adv/interfaces
[ active] eth1 00:11:f6:83:af:1c
##> cat /proc/net/batman-adv/originators
Originator (#/255) Nexthop [outgoingIF]: Potential nexthops ... [B.A.T.M.A.N. adv 0.3.0-alpha r1559, MainIF/MAC: eth1/00:11:f6:83:af:1c]
No batman nodes in range ...
##> route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 * 255.255.255.0 U 0 0 0 eth1 10.0.0.0 * 255.0.0.0 U 0 0 0 bat0 224.0.0.0 * 240.0.0.0 U 0 0 0 eth1
##> ping -c 3 10.0.1.40
PING 10.0.1.40 (10.0.1.40): 56 data bytes
64 bytes from 10.0.1.40: seq=0 ttl=64 time=19.123 ms 64 bytes from 10.0.1.40: seq=1 ttl=64 time=7.077 ms 64 bytes from 10.0.1.40: seq=2 ttl=64 time=7.239 ms
--- 10.0.1.40 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 7.077/11.146/19.123 ms
---
And the same set from the laptop counterpart:
---LAPTOP---
ylo@ylo-laptop:~$ ifconfig
bat0 Link encap:Ethernet HWaddr 26:22:26:1b:f4:f5
inet addr:10.1.1.40 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::2422:26ff:fe1b:f4f5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1476 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:936 (936.0 B)eth0 Link encap:Ethernet HWaddr 00:24:7e:68:bf:10
inet addr:10.10.10.126 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::224:7eff:fe68:bf10/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1370811 errors:0 dropped:0 overruns:0 frame:0
TX packets:613889 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1847455539 (1.8 GB) TX bytes:54536457 (54.5 MB)
Memory:fc000000-fc020000 lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:3060 errors:0 dropped:0 overruns:0 frame:0 TX packets:3060 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:817467 (817.4 KB) TX bytes:817467 (817.4 KB)
wlan0 Link encap:Ethernet HWaddr 00:22:fa:dc:9a:ce
inet addr:10.0.1.40 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: fe80::222:faff:fedc:9ace/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:37473 errors:0 dropped:0 overruns:0 frame:0
TX packets:5862 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10662970 (10.6 MB) TX bytes:539481 (539.4 KB)wmaster0 Link encap:UNSPEC HWaddr 00-22-FA-DC-9A-CE-61-63-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ylo@ylo-laptop:~$ cat /proc/net/batman-adv/interfaces [ active] wlan0 00:22:fa:dc:9a:ce ylo@ylo-laptop:~$ cat /proc/net/batman-adv/originators Originator (#/255) Nexthop [outgoingIF]: Potential nexthops ... [B.A.T.M.A.N. adv 0.3.0-alpha r1559, MainIF/MAC: wlan0/00:22:fa:dc:9a:ce] No batman nodes in range ... ylo@ylo-laptop:~$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 * 255.255.255.0 U 0 0 0 wlan0 10.10.10.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 1000 0 0 eth0 10.0.0.0 * 255.0.0.0 U 0 0 0 bat0 default 10.10.10.1 0.0.0.0 UG 100 0 0 eth0 ylo@ylo-laptop:~$ ping -c 3 10.0.1.33 PING 10.0.1.33 (10.0.1.33) 56(84) bytes of data. 64 bytes from 10.0.1.33: icmp_seq=1 ttl=64 time=6.08 ms 64 bytes from 10.0.1.33: icmp_seq=2 ttl=64 time=5.71 ms 64 bytes from 10.0.1.33: icmp_seq=3 ttl=64 time=5.59 ms
--- 10.0.1.33 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 5.596/5.797/6.082/0.224 ms
---
Quoted 3 lines
It might be useful to join us on irc to speed things up. Is that an option for
you ? We idle in #batman on irc.freenode.org.
Yeah, I've been lurking there for a while, but being so much on/off from the computer lately it's been easier to email. I'll certainly begin bugging You through irc once I have time to sit down for a while..=)
-Juha
Signature · 2 lines
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.
Quoted 3 lines · Juha Ylönen
Yeah, I've been lurking there for a while, but being so much on/off from
the computer lately it's been easier to email. I'll certainly begin bugging You through irc once I have time to sit down for a while..=)
It would help a lot. We are currently waiting for a lot more information from you.
I think it isn't really a big endian vs. little endian problem. I have installed batman-adv 1559 on a powerpc and on my amd64. Both can talk to each other without problems.
Do you have any filters installed which could filter out the ethernet frames? Does your hardware on arm transport non-standard ethernet types? A tcpdump on both sides which we can compare would help a lot.
I usually use a small test program to send raw ethernet packets from one host to another (one sided ping test). It helps a lot to find one directional problems.
On one side you must use ./rawsend DEVICE and on the other ./rawsend DEVICE TARGET-MAC
Best regards,
Sven
#include <stdio.h>
#include <sys/ioctl.h>
#include <net/if.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netpacket/packet.h>
#include <net/ethernet.h>
#include <stdint.h>
#include <string.h>
#include <arpa/inet.h>
#include <unistd.h>
int getmac(const char *src, unsigned char *dst)
{
unsigned int n[6];
int i;
if (sscanf(src, "%x:%x:%x:%x:%x:%x",
&n[0], &n[1], &n[2], &n[3], &n[4], &n[5]) != 6) {
if(sscanf(src, "%2x%2x.%2x%2x.%2x%2x",
&n[0], &n[1], &n[2], &n[3], &n[4], &n[5]) != 6) {
return 1;
}
}
for (i = 0; i < 6; i++) {
if (n[i] <= 255)
dst[i] = (unsigned char)n[i];
else
return 1;
}
return 0;
}int main(int argc, char *argv[])
{
int rawsock;
uint16_t type = 0x1337;
struct ifreq req;
struct sockaddr_ll addr;
struct iovec vector[2];
char buf[256];
size_t size = 256;
struct ether_header header;
if (argc != 2 && argc != 3) {
fprintf(stderr, "Usage: %s DEVICE [DST-MAC]\n", argv[0]);
return 1;
}
if ((rawsock = socket(PF_PACKET, SOCK_RAW, htons(type))) < 0 ) {
fprintf(stderr, "Could not open raw socket\n");
return 1;
}
strncpy(req.ifr_name, argv[1], IFNAMSIZ);
if (ioctl(rawsock, SIOCGIFINDEX, &req) < 0) {
fprintf(stderr, "Could not find device %s\n", argv[1]);
return 1;
}
addr.sll_family = AF_PACKET;
addr.sll_protocol = htons(type);
addr.sll_ifindex = req.ifr_ifindex;
if (bind(rawsock, (struct sockaddr *)&addr, sizeof(addr)) < 0 ) {
fprintf(stderr, "Could not bind to device %s\n", argv[1]);
return 1;
}
strncpy(req.ifr_name, argv[1], IFNAMSIZ);
if (ioctl(rawsock, SIOCGIFHWADDR, &req) < 0) {
fprintf(stderr, "Could not get hwaddr of device %s\n", argv[1]);
return 1;
}
if (argc == 2) {
vector[0].iov_base = &header;
vector[0].iov_len = sizeof(struct ether_header);
vector[1].iov_base = buf;
vector[1].iov_len = size;
if (readv(rawsock, vector, 2) < 0) {
close(rawsock);
fprintf(stderr, "Could not receive message\n");
return 1;
}
printf("Received message\n");
} else if (argc == 3) {
vector[0].iov_base = &header;
vector[0].iov_len = sizeof(struct ether_header);
vector[1].iov_base = buf;
vector[1].iov_len = size;
header.ether_type = htons(type);
memcpy(header.ether_shost, req.ifr_hwaddr.sa_data, ETH_ALEN);
if (getmac(argv[2], header.ether_dhost)) {
close(rawsock);
fprintf(stderr, "Could not parse mac address %s\n", argv[2]);
return 1;
}
if (writev(rawsock, vector, 2) < 0) {
close(rawsock);
fprintf(stderr, "Could not send message\n");
return 1;
}
}
close(rawsock);
return 0;
}On 01/21/2010 06:12 AM, "Juha Ylönen" wrote:
[snip]
Quoted 7 lines
---IN ARM DEVICE---
##> route
Kernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 * 255.255.255.0 U 0 0 0 eth1 10.0.0.0 * 255.0.0.0 U 0 0 0 bat0 224.0.0.0 * 240.0.0.0 U 0 0 0 eth1
[snip]
In the laptop you have:
Quoted 8 lines
ylo@ylo-laptop:~$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 * 255.255.255.0 U 0 0 0 wlan0 10.10.10.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 1000 0 0 eth0 10.0.0.0 * 255.0.0.0 U 0 0 0 bat0 default 10.10.10.1 0.0.0.0 UG 100 0 0 eth0
Your routes are all messed up. You have class C addresses subsumed inside class A address space, which causes undefined behavior.
Give your routes different address spaces, something like one in the 192.168.xx.xx, another 172.16.xx.xx, and the 10.xx.xx.xx so the routes can be sorted out properly.
Also, why does the laptop wlan0 have an IP address? If it is part of the mesh through bat0 it should not have an IP address, only add it as an interface to bat0.
Gus
Quoted 10 lines · Gus Wirth
Your routes are all messed up. You have class C addresses subsumed inside class A address space, which causes undefined behavior.
Give your routes different address spaces, something like one in the 192.168.xx.xx, another 172.16.xx.xx, and the 10.xx.xx.xx so the routes can be sorted out properly.
Also, why does the laptop wlan0 have an IP address? If it is part of the mesh through bat0 it should not have an IP address, only add it as an interface to bat0.
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?
Best regards,
Sven
Hello,
maybe just an idea, but could it be that we have a regression from the skb patch that some skb headers are wrong?
An idea would be to compare the behaviour with the batman-adv 0.2 release or an revision < 1517, which still uses raw sockets instead of working directly on the skb.
regards,
Simon
Quoted 40 lines · Sven Eckelmann
Quoted 10 lines · Gus Wirth
Your routes are all messed up. You have class C addresses subsumed inside class A address space, which causes undefined behavior.
Give your routes different address spaces, something like one in the 192.168.xx.xx, another 172.16.xx.xx, and the 10.xx.xx.xx so the routes can be sorted out properly.
Also, why does the laptop wlan0 have an IP address? If it is part of the mesh through bat0 it should not have an IP address, only add it as an interface to bat0.
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?
Best regards,
Sven
-------- Original-Nachricht --------
Quoted 9 lines
Datum: Fri, 22 Jan 2010 19:26:19 +0100
Von: Simon Wunderlich <[email protected]>maybe just an idea, but could it be that we have a regression from the skb patch that some skb headers are wrong?
An idea would be to compare the behaviour with the batman-adv 0.2 release or an revision < 1517, which still uses raw sockets instead of working directly on the skb.
Hi,
I've been trying out with 0.2 release and with latest trunk, with same behaviour.
-Juha
Signature · 2 lines
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser