i found time delay is very high and there are more caution info , if possible , please give me some advisement
----------------------------- archlinux hostA _____________________________
ip link set mtu 1532 dev eth0 batctl if add eth0 ip link set up dev eth0 ip link set up dev bat0
ifconfig bat0 10.10.130.88 netmask 255.255.255.0 up
----------------------------- archlinux hostB _____________________________
ip link set mtu 1532 dev eth0 batctl if add eth0 ip link set up dev eth0 ip link set up dev bat0
ifconfig bat0 10.10.130.66 netmask 255.255.255.0 up
my problem is :
when i try to ping hostB from hostA
i found time delay is very high and there are more caution info
because i tested between ethernet network port ( i don't test in wifi port ) , whether it will master reason ?
ethernet network use csma/cd ,but wifi use csma/ca , and ethernet network haven't mode ad-hoc .
if possible , please give some advisement .
Thanks again
On Freitag, 21. Oktober 2016 22:31:00 CEST johnzeng wrote: [..]
my problem is :
when i try to ping hostB from hostA
i found time delay is very high and there are more caution info
* What means high? * What would not be high? * What kind of "caution" info? * Did you try to disable offloading for your ethernet chip via ethtool? * Are these two devices directly connected via cable or is there some kind of device in the middle (like a switch/firewall/...)? * What batman-adv version are you using? * Did you check the packets sent via eth0 on both ends with wireshark 2.x?
because i tested between ethernet network port ( i don't test in wifi port ) , whether it will master reason ?
Should not be the "reason". batman-adv doesn't care much about it. It just requires an ethernet compatible device. The re-broadcast is a little bit less aggressive on non-wifi devices but this has nothing to do with your problem.
Kind regards, Sven
On Freitag, 21. Oktober 2016 16:43:41 CEST Sven Eckelmann wrote: [...]
because i tested between ethernet network port ( i don't test in wifi port ) , whether it will master reason ?
Should not be the "reason". batman-adv doesn't care much about it. It just requires an ethernet compatible device. The re-broadcast is a little bit less aggressive on non-wifi devices but this has nothing to do with your problem.
Just created a small test setup via ethernet with batman-adv 2016.3 to show you how the results are here. They were connected via a single cable:
without batman-adv ------------------
$ ping -c 10 192.168.2.196 PING 192.168.2.196 (192.168.2.196) 56(84) bytes of data. 64 bytes from 192.168.2.196: icmp_seq=1 ttl=64 time=0.478 ms 64 bytes from 192.168.2.196: icmp_seq=2 ttl=64 time=0.682 ms 64 bytes from 192.168.2.196: icmp_seq=3 ttl=64 time=0.392 ms 64 bytes from 192.168.2.196: icmp_seq=4 ttl=64 time=0.642 ms 64 bytes from 192.168.2.196: icmp_seq=5 ttl=64 time=0.574 ms 64 bytes from 192.168.2.196: icmp_seq=6 ttl=64 time=0.466 ms 64 bytes from 192.168.2.196: icmp_seq=7 ttl=64 time=0.602 ms 64 bytes from 192.168.2.196: icmp_seq=8 ttl=64 time=0.619 ms 64 bytes from 192.168.2.196: icmp_seq=9 ttl=64 time=0.658 ms 64 bytes from 192.168.2.196: icmp_seq=10 ttl=64 time=0.440 ms
--- 192.168.2.196 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9000ms rtt min/avg/max/mdev = 0.392/0.555/0.682/0.098 ms
with batman-adv ---------------
$ ping -c 10 10.10.130.66 PING 10.10.130.66 (10.10.130.66) 56(84) bytes of data. 64 bytes from 10.10.130.66: icmp_seq=1 ttl=64 time=0.489 ms 64 bytes from 10.10.130.66: icmp_seq=2 ttl=64 time=0.675 ms 64 bytes from 10.10.130.66: icmp_seq=3 ttl=64 time=0.552 ms 64 bytes from 10.10.130.66: icmp_seq=4 ttl=64 time=0.562 ms 64 bytes from 10.10.130.66: icmp_seq=5 ttl=64 time=0.612 ms 64 bytes from 10.10.130.66: icmp_seq=6 ttl=64 time=0.573 ms 64 bytes from 10.10.130.66: icmp_seq=7 ttl=64 time=0.534 ms 64 bytes from 10.10.130.66: icmp_seq=8 ttl=64 time=0.622 ms 64 bytes from 10.10.130.66: icmp_seq=9 ttl=64 time=0.454 ms 64 bytes from 10.10.130.66: icmp_seq=10 ttl=64 time=0.468 ms
--- 10.10.130.66 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 8996ms rtt min/avg/max/mdev = 0.454/0.554/0.675/0.067 ms
Kind regards, Sven
PS: I've changed the subject because it was extremely unspecific and too long.
Hello Dear Sven:
this is my config
archlinux 4.4.26-1-ARCH
[root@alarmpi ~]# batctl -v batctl 2016.2 [batman-adv: 2016.3]
----------------------------------------------------------------------------------------- hostA
[root@alarmpi ~]# ip link set mtu 1532 dev eth0 [root@alarmpi ~]# batctl if add eth0 [root@alarmpi ~]# ip link set up dev eth0 [root@alarmpi ~]# ip link set up dev bat0
----------------------------------------------------------------------------------------- bat0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.10.130.88 netmask 255.255.255.0 broadcast 10.10.130.255 inet6 fe80::1c07:c4ff:fe7e:4924 prefixlen 64 scopeid 0x20<link> ether 1e:07:c4:7e:49:24 txqueuelen 1000 (Ethernet) RX packets 20 bytes 1526 (1.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 12 bytes 942 (942.0 B) TX errors 0 dropped 13 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1532 inet 192.168.0.169 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::ba27:ebff:fefa:73b2 prefixlen 64 scopeid 0x20<link> ether b8:27:eb:fa:73:b2 txqueuelen 1000 (Ethernet) RX packets 3217 bytes 191526 (187.0 KiB) RX errors 0 dropped 2466 overruns 0 frame 0 TX packets 622 bytes 69243 (67.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 13 bytes 1101 (1.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 13 bytes 1101 (1.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 --------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------ hostB
[root@alarmpi ~]# ip link set mtu 1532 dev eth0 [root@alarmpi ~]# batctl if add eth0 [root@alarmpi ~]# ip link set up dev eth0 [root@alarmpi ~]# ip link set up dev bat0
-------------------------------------------------------------------------------------------------------
bat0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.10.130.1 netmask 255.255.255.0 broadcast 10.10.130.255 inet6 fe80::d015:7ec8:fe14:4637 prefixlen 64 scopeid 0x20<link> ether 1e:15:7a:b7:08:5a txqueuelen 1000 (Ethernet) RX packets 1657 bytes 83112 (81.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 421 bytes 94519 (92.3 KiB) TX errors 0 dropped 35 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1532 inet 192.168.0.170 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::ba27:ebff:fed8:f2b5 prefixlen 64 scopeid 0x20<link> ether b8:27:eb:d8:f2:b5 txqueuelen 1000 (Ethernet) RX packets 23332 bytes 3589386 (3.4 MiB) RX errors 0 dropped 819 overruns 0 frame 0 TX packets 26114 bytes 2602362 (2.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 193 bytes 15397 (15.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 193 bytes 15397 (15.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.168.0.1 netmask 255.255.255.0 broadcast 172.168.0.255 inet6 fe80::ca3a:35ff:fec9:ce71 prefixlen 64 scopeid 0x20<link> ether c8:3a:35:c9:ce:71 txqueuelen 1000 (Ethernet) RX packets 4177 bytes 636431 (621.5 KiB) RX errors 0 dropped 13 overruns 0 frame 0 TX packets 3539 bytes 2661310 (2.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ------------------------------------------------------------------------------------------------------------
----------------------------------------- ------------------------------------------------------------------- from hostB 10.10.130.1 ping hostA 10.10.130.88
------------------------------------------------------------------------------------------------------------ [root@alarmpi ~]# ping 10.10.130.88 PING 10.10.130.88 (10.10.130.88) 56(84) bytes of data. 64 bytes from 10.10.130.88: icmp_seq=1 ttl=64 time=1025 ms 64 bytes from 10.10.130.88: icmp_seq=2 ttl=64 time=1084 ms 64 bytes from 10.10.130.88: icmp_seq=3 ttl=64 time=1056 ms 64 bytes from 10.10.130.88: icmp_seq=4 ttl=64 time=971 ms 64 bytes from 10.10.130.88: icmp_seq=5 ttl=64 time=1052 ms 64 bytes from 10.10.130.88: icmp_seq=6 ttl=64 time=1123 ms 64 bytes from 10.10.130.88: icmp_seq=7 ttl=64 time=1049 ms 64 bytes from 10.10.130.88: icmp_seq=8 ttl=64 time=1112 ms 64 bytes from 10.10.130.88: icmp_seq=9 ttl=64 time=1055 ms 64 bytes from 10.10.130.88: icmp_seq=10 ttl=64 time=1112 ms
----------------------------------------- ------------------------------------------------------------------- tcpdump from hostA 10.10.130.88
[root@alarmpi ~]# tcpdump -i bat0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bat0, link-type EN10MB (Ethernet), capture size 262144 bytes 15:25:02.269833 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:25:12.289863 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:25:22.309866 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:25:32.329843 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:25:42.349854 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:25:52.369883 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:25:52.369889 ARP, Reply 0.0.0.0 is-at b8:27:eb:fa:73:b2 (oui Unknown), length 28 15:26:01.899991 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 1e:15:7a:b7:08:5a (oui Unknown), length 350 15:26:02.389841 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:26:12.409835 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:26:17.498686 IP bogon > bogon: ICMP echo request, id 626, seq 1, length 64 15:26:18.522626 IP bogon > bogon: ICMP echo reply, id 626, seq 1, length 64 15:26:18.523618 IP bogon > bogon: ICMP echo request, id 626, seq 2, length 64 15:26:19.244386 IP bogon > bogon: ICMP echo reply, id 626, seq 2, length 64 15:26:20.876932 IP bogon > bogon: ICMP echo request, id 626, seq 3, length 64 15:26:21.931920 IP bogon > bogon: ICMP echo reply, id 626, seq 3, length 64 15:26:21.940098 IP bogon > bogon: ICMP echo request, id 626, seq 4, length 64 15:26:22.850412 IP bogon > bogon: ICMP echo reply, id 626, seq 4, length 64 15:26:22.851347 ARP, Request who-has bogon tell bogon, length 28 15:26:22.851890 ARP, Reply bogon is-at 1e:15:7a:b7:08:5a (oui Unknown), length 28 15:26:22.879878 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:26:24.097927 IP bogon > bogon: ICMP echo request, id 626, seq 5, length 64 15:26:25.149237 IP bogon > bogon: ICMP echo reply, id 626, seq 5, length 64 15:26:25.157413 IP bogon > bogon: ICMP echo request, id 626, seq 6, length 64 15:26:25.981228 IP bogon > bogon: ICMP echo reply, id 626, seq 6, length 64 15:26:27.140034 IP bogon > bogon: ICMP echo request, id 626, seq 7, length 64 15:26:28.188497 IP bogon > bogon: ICMP echo reply, id 626, seq 7, length 64 15:26:28.189529 IP bogon > bogon: ICMP echo request, id 626, seq 8, length 64 15:26:28.910758 IP bogon > bogon: ICMP echo reply, id 626, seq 8, length 64 15:26:30.193020 IP bogon > bogon: ICMP echo request, id 626, seq 9, length 64 15:26:31.247332 IP bogon > bogon: ICMP echo reply, id 626, seq 9, length 64 15:26:31.248525 IP bogon > bogon: ICMP echo request, id 626, seq 10, length 64 15:26:32.096880 IP bogon > bogon: ICMP echo reply, id 626, seq 10, length 64 15:26:32.909841 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:26:34.052330 IP bogon > bogon: ICMP echo request, id 626, seq 11, length 64 15:26:35.088054 IP bogon > bogon: ICMP echo reply, id 626, seq 11, length 64 15:26:35.089050 IP bogon > bogon: ICMP echo request, id 626, seq 12, length 64 15:26:35.810244 IP bogon > bogon: ICMP echo reply, id 626, seq 12, length 64 15:26:36.922755 IP bogon > bogon: ICMP echo request, id 626, seq 13, length 64 15:26:37.910153 IP bogon > bogon: ICMP echo reply, id 626, seq 13, length 64 15:26:39.006945 IP bogon > bogon: ICMP echo request, id 626, seq 14, length 64 15:26:39.964130 IP bogon > bogon: ICMP echo reply, id 626, seq 14, length 64 15:26:41.032390 IP bogon > bogon: ICMP echo request, id 626, seq 15, length 64 15:26:42.056430 IP bogon > bogon: ICMP echo reply, id 626, seq 15, length 64 15:26:42.057424 IP bogon > bogon: ICMP echo request, id 626, seq 16, length 64 15:26:42.778857 IP bogon > bogon: ICMP echo reply, id 626, seq 16, length 64 15:26:42.929845 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:26:44.027405 IP bogon > bogon: ICMP echo request, id 626, seq 17, length 64 15:26:45.014653 IP bogon > bogon: ICMP echo reply, id 626, seq 17, length 64 15:26:46.081391 IP bogon > bogon: ICMP echo request, id 626, seq 18, length 64 15:26:47.104540 IP bogon > bogon: ICMP echo reply, id 626, seq 18, length 64 15:26:47.105502 ARP, Request who-has bogon tell bogon, length 28 15:26:47.106049 ARP, Reply bogon is-at 1e:15:7a:b7:08:5a (oui Unknown), length 28 15:26:47.106707 IP bogon > bogon: ICMP echo request, id 626, seq 19, length 64 15:26:47.827792 IP bogon > bogon: ICMP echo reply, id 626, seq 19, length 64 15:26:48.931955 IP bogon > bogon: ICMP echo request, id 626, seq 20, length 64 15:26:49.986791 IP bogon > bogon: ICMP echo reply, id 626, seq 20, length 64 15:26:49.987830 IP bogon > bogon: ICMP echo request, id 626, seq 21, length 64 15:26:51.253787 IP bogon > bogon: ICMP echo reply, id 626, seq 21, length 64 15:26:51.254896 IP bogon > bogon: ICMP echo request, id 626, seq 22, length 64 15:26:52.140032 IP bogon > bogon: ICMP echo reply, id 626, seq 22, length 64 15:26:52.949924 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:26:52.949930 ARP, Reply 0.0.0.0 is-at b8:27:eb:fa:73:b2 (oui Unknown), length 28 15:26:53.074686 IP bogon > bogon: ICMP echo request, id 626, seq 23, length 64 15:26:54.105458 IP bogon > bogon: ICMP echo reply, id 626, seq 23, length 64 15:26:54.106787 IP bogon > bogon: ICMP echo request, id 626, seq 24, length 64 15:26:54.955005 IP bogon > bogon: ICMP echo reply, id 626, seq 24, length 64 15:26:56.336044 IP bogon > bogon: ICMP echo request, id 626, seq 25, length 64 15:26:57.369772 IP bogon > bogon: ICMP echo reply, id 626, seq 25, length 64 15:26:57.370794 IP bogon > bogon: ICMP echo request, id 626, seq 26, length 64 15:26:58.219681 IP bogon > bogon: ICMP echo reply, id 626, seq 26, length 64 15:26:59.578372 IP bogon > bogon: ICMP echo request, id 626, seq 27, length 64 15:27:00.612175 IP bogon > bogon: ICMP echo reply, id 626, seq 27, length 64 15:27:00.613320 IP bogon > bogon: ICMP echo request, id 626, seq 28, length 64 15:27:01.505147 IP bogon > bogon: ICMP echo reply, id 626, seq 28, length 64 15:27:02.441128 IP bogon > bogon: ICMP echo request, id 626, seq 29, length 64 15:27:03.487369 IP bogon > bogon: ICMP echo reply, id 626, seq 29, length 64 15:27:03.488559 IP bogon > bogon: ICMP echo request, id 626, seq 30, length 64 15:27:04.336996 IP bogon > bogon: ICMP echo reply, id 626, seq 30, length 64 15:27:04.340675 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:27:05.331808 IP bogon > bogon: ICMP echo request, id 626, seq 31, length 64 15:27:06.367689 IP bogon > bogon: ICMP echo reply, id 626, seq 31, length 64 15:27:06.368768 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 1e:15:7a:b7:08:5a (oui Unknown), length 350 15:27:06.368773 IP bogon > bogon: ICMP echo request, id 626, seq 32, length 64 15:27:07.089593 IP bogon > bogon: ICMP echo reply, id 626, seq 32, length 64 15:27:08.218598 IP bogon > bogon: ICMP echo request, id 626, seq 33, length 64 15:27:09.272724 IP bogon > bogon: ICMP echo reply, id 626, seq 33, length 64 15:27:09.273837 IP bogon > bogon: ICMP echo request, id 626, seq 34, length 64 15:27:10.287572 IP bogon > bogon: ICMP echo reply, id 626, seq 34, length 64 15:27:11.045960 IP bogon > bogon: ICMP echo request, id 626, seq 35, length 64 15:27:12.073985 IP bogon > bogon: ICMP echo reply, id 626, seq 35, length 64 15:27:12.074885 ARP, Request who-has bogon tell bogon, length 28 15:27:12.075465 ARP, Reply bogon is-at 1e:15:7a:b7:08:5a (oui Unknown), length 28 15:27:12.076299 IP bogon > bogon: ICMP echo request, id 626, seq 36, length 64 15:27:12.923977 IP bogon > bogon: ICMP echo reply, id 626, seq 36, length 64 15:27:13.931779 IP bogon > bogon: ICMP echo request, id 626, seq 37, length 64 15:27:14.966326 IP bogon > bogon: ICMP echo reply, id 626, seq 37, length 64 15:27:14.967323 IP bogon > bogon: ICMP echo request, id 626, seq 38, length 64 15:27:15.688507 IP bogon > bogon: ICMP echo reply, id 626, seq 38, length 64 15:27:15.690217 ARP, Reply 0.0.0.0 is-at 43:05:43:05:b8:20 (oui Unknown), length 28 15:27:16.961136 IP bogon > bogon: ICMP echo request, id 626, seq 39, length 64 15:27:17.947857 IP bogon > bogon: ICMP echo reply, id 626, seq 39, length 64 15:27:18.964151 IP bogon > bogon: ICMP echo request, id 626, seq 40, length 64 15:27:19.990174 IP bogon > bogon: ICMP echo reply, id 626, seq 40, length 64 15:27:19.991106 IP bogon > bogon: ICMP echo request, id 626, seq 41, length 64 15:27:20.712663 IP bogon > bogon: ICMP echo reply, id 626, seq 41, length 64 15:27:21.812959 IP bogon > bogon: ICMP echo request, id 626, seq 42, length 64 15:27:22.866807 IP bogon > bogon: ICMP echo reply, id 626, seq 42, length 64 15:27:22.867823 IP bogon > bogon: ICMP echo request, id 626, seq 43, length 64 15:27:23.588618 IP bogon > bogon: ICMP echo reply, id 626, seq 43, length 64 15:27:24.718226 IP bogon > bogon: ICMP echo request, id 626, seq 44, length 64
------------------------------------------------------------------------------------------------------------
On Freitag, 21. Oktober 2016 16:43:41 CEST Sven Eckelmann wrote: [...]
because i tested between ethernet network port ( i don't test in wifi port ) , whether it will master reason ?
Should not be the "reason". batman-adv doesn't care much about it. It just requires an ethernet compatible device. The re-broadcast is a little bit less aggressive on non-wifi devices but this has nothing to do with your problem.
Just created a small test setup via ethernet with batman-adv 2016.3 to show you how the results are here. They were connected via a single cable:
without batman-adv
$ ping -c 10 192.168.2.196 PING 192.168.2.196 (192.168.2.196) 56(84) bytes of data. 64 bytes from 192.168.2.196: icmp_seq=1 ttl=64 time=0.478 ms 64 bytes from 192.168.2.196: icmp_seq=2 ttl=64 time=0.682 ms 64 bytes from 192.168.2.196: icmp_seq=3 ttl=64 time=0.392 ms 64 bytes from 192.168.2.196: icmp_seq=4 ttl=64 time=0.642 ms 64 bytes from 192.168.2.196: icmp_seq=5 ttl=64 time=0.574 ms 64 bytes from 192.168.2.196: icmp_seq=6 ttl=64 time=0.466 ms 64 bytes from 192.168.2.196: icmp_seq=7 ttl=64 time=0.602 ms 64 bytes from 192.168.2.196: icmp_seq=8 ttl=64 time=0.619 ms 64 bytes from 192.168.2.196: icmp_seq=9 ttl=64 time=0.658 ms 64 bytes from 192.168.2.196: icmp_seq=10 ttl=64 time=0.440 ms --- 192.168.2.196 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9000ms rtt min/avg/max/mdev = 0.392/0.555/0.682/0.098 mswith batman-adv
$ ping -c 10 10.10.130.66 PING 10.10.130.66 (10.10.130.66) 56(84) bytes of data. 64 bytes from 10.10.130.66: icmp_seq=1 ttl=64 time=0.489 ms 64 bytes from 10.10.130.66: icmp_seq=2 ttl=64 time=0.675 ms 64 bytes from 10.10.130.66: icmp_seq=3 ttl=64 time=0.552 ms 64 bytes from 10.10.130.66: icmp_seq=4 ttl=64 time=0.562 ms 64 bytes from 10.10.130.66: icmp_seq=5 ttl=64 time=0.612 ms 64 bytes from 10.10.130.66: icmp_seq=6 ttl=64 time=0.573 ms 64 bytes from 10.10.130.66: icmp_seq=7 ttl=64 time=0.534 ms 64 bytes from 10.10.130.66: icmp_seq=8 ttl=64 time=0.622 ms 64 bytes from 10.10.130.66: icmp_seq=9 ttl=64 time=0.454 ms 64 bytes from 10.10.130.66: icmp_seq=10 ttl=64 time=0.468 ms --- 10.10.130.66 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 8996ms rtt min/avg/max/mdev = 0.454/0.554/0.675/0.067 msKind regards, Sven
PS: I've changed the subject because it was extremely unspecific and too long.
On Freitag, 21. Oktober 2016 23:29:26 CEST johnzeng wrote:
[root@alarmpi ~]# batctl -v batctl 2016.2 [batman-adv: 2016.3]
seems to be recent enough. You can compare my batman-adv settings by just grepping /sys/class/net/bat0/mesh/*
$ grep '' /sys/class/net/bat0/mesh/* /sys/class/net/bat0/mesh/aggregated_ogms:enabled /sys/class/net/bat0/mesh/ap_isolation:disabled /sys/class/net/bat0/mesh/bonding:disabled /sys/class/net/bat0/mesh/bridge_loop_avoidance:enabled /sys/class/net/bat0/mesh/distributed_arp_table:enabled /sys/class/net/bat0/mesh/fragmentation:enabled /sys/class/net/bat0/mesh/gw_bandwidth:10.0/2.0 MBit /sys/class/net/bat0/mesh/gw_mode:off /sys/class/net/bat0/mesh/gw_sel_class:20 /sys/class/net/bat0/mesh/hop_penalty:30 /sys/class/net/bat0/mesh/isolation_mark:0x00000000/0x00000000 /sys/class/net/bat0/mesh/multicast_mode:enabled /sys/class/net/bat0/mesh/network_coding:disabled /sys/class/net/bat0/mesh/orig_interval:1000 /sys/class/net/bat0/mesh/routing_algo:BATMAN_IV
Btw. there are also other things I've mentioned/asked in my first reply.
[...]
tcpdump from hostA 10.10.130.88
[root@alarmpi ~]# tcpdump -i bat0
I said wireshark 2.x and eth0. You maybe can use these dumps to find out if your hardware delays/drops the packets which batman-adv encapsulates. Btw. I can not debug your hardware/driver from remote (when this is a hardware/driver problem).
Anyway, please also read my comment at the end.
You could also dump eth0 and bat0 at the same time to check that the incoming batadv+icmp-request packet comes out of bat0 as icmp-request packet with nearly no extra delay. And then you can check that the icmp-reply transmitted via the bat0 interface is transmitted with nearly no extra delay via the eth0 interface as batadv+icmp-reply.
from hostB 10.10.130.1 ping hostA 10.10.130.88
[...]
tcpdump from hostA 10.10.130.88
[root@alarmpi ~]# tcpdump -i bat0 15:26:17.498686 IP bogon > bogon: ICMP echo request, id 626, seq 1, 15:26:18.522626 IP bogon > bogon: ICMP echo reply, id 626, seq 1, length 64 15:26:18.523618 IP bogon > bogon: ICMP echo request, id 626, seq 2, 15:26:19.244386 IP bogon > bogon: ICMP echo reply, id 626, seq 2, length 64
Are you sure that you are dumping on the system which receives the ping requests and has to reply to the ping requests? Because then you problem seems to be above batman-adv. The request was given upwards "15:26:17.498686" from bat0 (so batman-adv isn't responsible for the packet anymore) and the reply for it was given to bat0 at "15:26:18.522626". So over 1 second delay caused by something above the batman-adv layer.
Kind regards, Sven
Hello linus:
This is my info
lsmod
batman_adv 164539 0 bridge 108205 1 batman_adv
[root@alarmpi tmp]# ls /sys/class/net/bat0/mesh/ aggregated_ogms bonding distributed_arp_table gw_bandwidth gw_sel_class isolation_mark orig_interval ap_isolation bridge_loop_avoidance fragmentation gw_mode hop_penalty multicast_mode routing_algo
[root@alarmpi tmp]# ls /sys/class/net/eth0/batman_adv/ iface_status mesh_iface
[root@alarmpi tmp]# batctl nc disable Error - can't open file '/sys/class/net/bat0/mesh/network_coding': No such file or directory The option you called seems not to be compiled into your batman-adv kernel module. Consult the README if you wish to learn more about compiling options into batman-adv.
于 2016年10月21日 23:31, Linus Lüssing 写道:
On Fri, Oct 21, 2016 at 04:31:20PM +0200, johnzeng via B.A.T.M.A.N wrote:
Date: Fri, 21 Oct 2016 22:31:00 +0800 From: johnzeng johnzeng2013@yahoo.com To: b.a.t.m.a.n@lists.open-mesh.org Subject: i found time delay is very high and there are more caution info , if possible , please give me some advisement
If I remember correctly, then one typical issue for Arch Linux users was, that Arch compiles batman-adv with network-coding, even though it is marked as "Experimental". And that introduces high latency and/or packetloss.
johnzeug, can you check whether network coding is enabled or disabled and if it is enabled, whether disabling helps?
(batctl nc disable)
And like Sven asked, what batman-adv version are you using. Not that long ago the network coding default was changed to disabled by default even if the module is compiled with NC. Maybe you run an older batman-adv release?
Regards, Linus
On Freitag, 21. Oktober 2016 16:43:41 CEST Sven Eckelmann wrote: [...]
because i tested between ethernet network port ( i don't test in wifi port ) , whether it will master reason ?
Should not be the "reason". batman-adv doesn't care much about it. It just requires an ethernet compatible device. The re-broadcast is a little bit less aggressive on non-wifi devices but this has nothing to do with your problem.
Just created a small test setup via ethernet with batman-adv 2016.3 to show you how the results are here. They were connected via a single cable:
without batman-adv
$ ping -c 10 192.168.2.196 PING 192.168.2.196 (192.168.2.196) 56(84) bytes of data. 64 bytes from 192.168.2.196: icmp_seq=1 ttl=64 time=0.478 ms 64 bytes from 192.168.2.196: icmp_seq=2 ttl=64 time=0.682 ms 64 bytes from 192.168.2.196: icmp_seq=3 ttl=64 time=0.392 ms 64 bytes from 192.168.2.196: icmp_seq=4 ttl=64 time=0.642 ms 64 bytes from 192.168.2.196: icmp_seq=5 ttl=64 time=0.574 ms 64 bytes from 192.168.2.196: icmp_seq=6 ttl=64 time=0.466 ms 64 bytes from 192.168.2.196: icmp_seq=7 ttl=64 time=0.602 ms 64 bytes from 192.168.2.196: icmp_seq=8 ttl=64 time=0.619 ms 64 bytes from 192.168.2.196: icmp_seq=9 ttl=64 time=0.658 ms 64 bytes from 192.168.2.196: icmp_seq=10 ttl=64 time=0.440 ms --- 192.168.2.196 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9000ms rtt min/avg/max/mdev = 0.392/0.555/0.682/0.098 mswith batman-adv
$ ping -c 10 10.10.130.66 PING 10.10.130.66 (10.10.130.66) 56(84) bytes of data. 64 bytes from 10.10.130.66: icmp_seq=1 ttl=64 time=0.489 ms 64 bytes from 10.10.130.66: icmp_seq=2 ttl=64 time=0.675 ms 64 bytes from 10.10.130.66: icmp_seq=3 ttl=64 time=0.552 ms 64 bytes from 10.10.130.66: icmp_seq=4 ttl=64 time=0.562 ms 64 bytes from 10.10.130.66: icmp_seq=5 ttl=64 time=0.612 ms 64 bytes from 10.10.130.66: icmp_seq=6 ttl=64 time=0.573 ms 64 bytes from 10.10.130.66: icmp_seq=7 ttl=64 time=0.534 ms 64 bytes from 10.10.130.66: icmp_seq=8 ttl=64 time=0.622 ms 64 bytes from 10.10.130.66: icmp_seq=9 ttl=64 time=0.454 ms 64 bytes from 10.10.130.66: icmp_seq=10 ttl=64 time=0.468 ms --- 10.10.130.66 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 8996ms rtt min/avg/max/mdev = 0.454/0.554/0.675/0.067 msKind regards, Sven
PS: I've changed the subject because it was extremely unspecific and too long.
Hello Dear Sven and Linus:
You are right , and When i check /sys/class/net/bat0/mesh/* and i found archlinux lost network-coding .
They were connected via a single cable as you .
Whether i need use older batman version (batman-adv and batctl 2015.2 ) ?
and our version is newest version ( Linux alarmpi 4.4.26-1-ARCH ) and hardware platform is raspberry pi B , but
i search wiki , i found kernel 4.4 will usebatman 2015.2
https://www.open-mesh.org/projects/open-mesh/wiki/Download
linux 4.4 => batman-adv 2015.2 (get batctl 2015.2 fromhere https://downloads.open-mesh.org/batman/stable/sources/batctl/).
if batman-adv don't support archlinux really , whether ubuntu will support batman-adv .
Thanks
[root@alarmpi ~]# grep '' /sys/class/net/bat0/mesh/* /sys/class/net/bat0/mesh/aggregated_ogms:enabled /sys/class/net/bat0/mesh/ap_isolation:disabled /sys/class/net/bat0/mesh/bonding:disabled /sys/class/net/bat0/mesh/bridge_loop_avoidance:enabled /sys/class/net/bat0/mesh/distributed_arp_table:enabled /sys/class/net/bat0/mesh/fragmentation:enabled /sys/class/net/bat0/mesh/gw_bandwidth:10.0/2.0 MBit /sys/class/net/bat0/mesh/gw_mode:off /sys/class/net/bat0/mesh/gw_sel_class:20 /sys/class/net/bat0/mesh/hop_penalty:30 /sys/class/net/bat0/mesh/isolation_mark:0x00000000/0x00000000 /sys/class/net/bat0/mesh/multicast_mode:enabled /sys/class/net/bat0/mesh/orig_interval:1000 /sys/class/net/bat0/mesh/routing_algo:BATMAN_IV
On Montag, 24. Oktober 2016 13:11:38 CEST johnzeng wrote:
Hello Dear Sven and Linus:
You are right , and When icheck /sys/class/net/bat0/mesh/* and i found archlinux lost network-coding .
No, they/you just haven't compiled network coding for batman-adv. And you don't need it.
They were connected via a single cable as you .
What about the rest mentioned in my other mails?
Whether i need use older batman version (batman-adv and batctl 2015.2 ) ?
No. Use a recent version (unless you know that this is a regression).
and our version is newest version ( Linux alarmpi 4.4.26-1-ARCH ) and hardware platform is raspberry pi B , but i search wiki , i found kernel 4.4 will usebatman 2015.2
It just means that kernel 4.4 includes (more or less) batman-adv 2015.2. You can still use batman-adv 2016.2 as external module for this kernel version.
[...]
if batman-adv don't support archlinux really , whether ubuntu will support batman-adv .
Hm? This doesn't make a lot of sense. batman-adv doesn't require special distribution support. It is just a Linux kernel module. You have to find out what other things (hw/drivers/tc/iptables/...) are causing the problems on your system.
And I even know of people that use Arch Linux on their Freifunk supernodes together with batman-adv.
Kind regards, Sven
Hello Dear Sven:
What kind of "caution" info?
When i start ping hostb from hosta , i catch error info via dmesg , this is parts info
please see attactment of email about more error info .
Thanks again.
[ 7199.866447] [<c0702760>] (ip_local_deliver_finish) from [<c0702da8>] (ip_local_deliver+0x44/0xcc) [ 7199.904865] [<c0702da8>] (ip_local_deliver) from [<c07030bc>] (ip_rcv+0x28c/0x378) [ 7199.941909] [<c07030bc>] (ip_rcv) from [<c06c94fc>] (__netif_receive_skb_core+0x76c/0xb24) [ 7199.979512] [<c06c94fc>] (__netif_receive_skb_core) from [<c06cc3e8>] (process_backlog+0x58/0xd8) [ 7200.017753] [<c06cc3e8>] (process_backlog) from [<c06cbb9c>] (net_rx_action+0x1c0/0x2f8) [ 7200.055308] [<c06cbb9c>] (net_rx_action) from [<c002a4c4>] (__do_softirq+0xb0/0x290) [ 7200.092406] [<c002a4c4>] (__do_softirq) from [<c002a938>] (irq_exit+0xc4/0x10c) [ 7200.129110] [<c002a938>] (irq_exit) from [<c005c898>] (__handle_domain_irq+0x50/0xa8) [ 7200.166474] [<c005c898>] (__handle_domain_irq) from [<c000936c>] (bcm2835_handle_irq+0x34/0x4c) [ 7200.204931] [<c000936c>] (bcm2835_handle_irq) from [<c07a026c>] (__irq_usr+0x4c/0x60) [ 7200.242634] Exception stack(0xd9471fb0 to 0xd9471ff8) [ 7200.277642] 1fa0: 00596c78 00000000 00000000 b5eb8000 [ 7200.315958] 1fc0: 801a68c8 befca240 00000000 801a48e0 b644ec78 befca228 00000026 00000000 [ 7200.354047] 1fe0: 00000032 befca1e8 36353039 b6eac120 a0000010 ffffffff [ 7855.043910] bat0: hw csum failure [ 7855.074857] CPU: 0 PID: 0 Comm: swapper Tainted: G O 4.4.26-1-ARCH #1 [ 7855.109974] Hardware name: BCM2708 [ 7855.140615] [<c0014584>] (unwind_backtrace) from [<c001257c>] (show_stack+0x10/0x14) [ 7855.175696] [<c001257c>] (show_stack) from [<c06c12dc>] (__skb_checksum_complete+0xb4/0xb8) [ 7855.211340] [<c06c12dc>] (__skb_checksum_complete) from [<c0734328>] (icmp_rcv+0xa4/0x35c) [ 7855.247035] [<c0734328>] (icmp_rcv) from [<c0702760>] (ip_local_deliver_finish+0xc4/0x22c) [ 7855.282647] [<c0702760>] (ip_local_deliver_finish) from [<c0702da8>] (ip_local_deliver+0x44/0xcc) [ 7855.318862] [<c0702da8>] (ip_local_deliver) from [<c07030bc>] (ip_rcv+0x28c/0x378) [ 7855.353794] [<c07030bc>] (ip_rcv) from [<c06c94fc>] (__netif_receive_skb_core+0x76c/0xb24) [ 7855.389194] [<c06c94fc>] (__netif_receive_skb_core) from [<c06cc3e8>] (process_backlog+0x58/0xd8) [ 7855.425373] [<c06cc3e8>] (process_backlog) from [<c06cbb9c>] (net_rx_action+0x1c0/0x2f8) [ 7855.460823] [<c06cbb9c>] (net_rx_action) from [<c002a4c4>] (__do_softirq+0xb0/0x290) [ 7855.495919] [<c002a4c4>] (__do_softirq) from [<c002a938>] (irq_exit+0xc4/0x10c) [ 7855.530483] [<c002a938>] (irq_exit) from [<c005c898>] (__handle_domain_irq+0x50/0xa8) [ 7855.565501] [<c005c898>] (__handle_domain_irq) from [<c000936c>] (bcm2835_handle_irq+0x34/0x4c) [ 7855.601613] [<c000936c>] (bcm2835_handle_irq) from [<c079ffa0>] (__irq_svc+0x40/0x54) [ 7855.636711] Exception stack(0xc0a9df58 to 0xc0a9dfa0) [ 7855.669131] df40: da539e20 00000000 [ 7855.704679] df60: 035c3d5e 00000000 c0b2cf4c 00000000 c0a9c000 c0a9e0b4 c0b2cf00 c0b227c4 [ 7855.740071] df80: c0b21cef c0950d28 00000000 c0a9dfa8 c000f710 c000f714 60000013 ffffffff [ 7855.775373] [<c079ffa0>] (__irq_svc) from [<c000f714>] (arch_cpu_idle+0x28/0x30) [ 7855.809908] [<c000f714>] (arch_cpu_idle) from [<c0051358>] (cpu_startup_entry+0x114/0x15c) [ 7855.845403] [<c0051358>] (cpu_startup_entry) from [<c0a4ac18>] (start_kernel+0x344/0x3b8) [ 7855.917089] bat0: hw csum failure [ 7855.947633] CPU: 0 PID: 0 Comm: swapper Tainted: G O 4.4.26-1-ARCH #1 [ 7855.982129] Hardware name: BCM2708 [ 7856.012280] [<c0014584>] (unwind_backtrace) from [<c001257c>] (show_stack+0x10/0x14) [ 7856.046900] [<c001257c>] (show_stack) from [<c06c12dc>] (__skb_checksum_complete+0xb4/0xb8) [ 7856.082154] [<c06c12dc>] (__skb_checksum_complete) from [<c0734328>] (icmp_rcv+0xa4/0x35c) [ 7856.117455] [<c0734328>] (icmp_rcv) from [<c0702760>] (ip_local_deliver_finish+0xc4/0x22c) [ 7856.152655] [<c0702760>] (ip_local_deliver_finish) from [<c0702da8>] (ip_local_deliver+0x44/0xcc) [ 7856.189217] [<c0702da8>] (ip_local_deliver) from [<c07030bc>] (ip_rcv+0x28c/0x378) [ 7856.224818] [<c07030bc>] (ip_rcv) from [<c06c94fc>] (__netif_receive_skb_core+0x76c/0xb24) [ 7856.261256] [<c06c94fc>] (__netif_receive_skb_core) from [<c06cc3e8>] (process_backlog+0x58/0xd8) [ 7856.298716] [<c06cc3e8>] (process_backlog) from [<c06cbb9c>] (net_rx_action+0x1c0/0x2f8) [ 7856.335711] [<c06cbb9c>] (net_rx_action) from [<c002a4c4>] (__do_softirq+0xb0/0x290) [ 7856.372376] [<c002a4c4>] (__do_softirq) from [<c002a938>] (irq_exit+0xc4/0x10c) [ 7856.408706] [<c002a938>] (irq_exit) from [<c005c898>] (__handle_domain_irq+0x50/0xa8) [ 7856.445578] [<c005c898>] (__handle_domain_irq) from [<c000936c>] (bcm2835_handle_irq+0x34/0x4c) [ 7856.483580] [<c000936c>] (bcm2835_handle_irq) from [<c079ffa0>] (__irq_svc+0x40/0x54) [ 7856.520723] Exception stack(0xc0a9df60 to 0xc0a9dfa8) [ 7856.555127] df60: da539e20 00000000 01616376 00000000 c0b2cf4c 00000000 c0a9c000 c0a9e0b4 [ 7856.592731] df80: c0b2cf00 c0b227c4 c0b21cef c0950d28 00000000 c0a9dfb0 c000f710 c0051358 [ 7856.630345] dfa0: 60000013 ffffffff [ 7856.663164] [<c079ffa0>] (__irq_svc) from [<c0051358>] (cpu_startup_entry+0x114/0x15c) [ 7856.700436] [<c0051358>] (cpu_startup_entry) from [<c0a4ac18>] (start_kernel+0x344/0x3b8) [ 7857.773177] bat0: hw csum failure [ 7857.805894] CPU: 0 PID: 0 Comm: swapper Tainted: G O 4.4.26-1-ARCH #1 [ 7857.842773] Hardware name: BCM2708
于 2016年10月24日 14:29, Sven Eckelmann 写道:
On Montag, 24. Oktober 2016 13:11:38 CEST johnzeng wrote:
Hello Dear Sven and Linus:
You are right , and When icheck /sys/class/net/bat0/mesh/* and i found archlinux lost network-coding .
No, they/you just haven't compiled network coding for batman-adv. And you don't need it.
They were connected via a single cable as you .What about the rest mentioned in my other mails?
Whether i need use older batman version (batman-adv and batctl 2015.2 ) ?No. Use a recent version (unless you know that this is a regression).
and our version is newest version ( Linux alarmpi 4.4.26-1-ARCH ) and hardware platform is raspberry pi B , but i search wiki , i found kernel 4.4 will usebatman 2015.2It just means that kernel 4.4 includes (more or less) batman-adv 2015.2. You can still use batman-adv 2016.2 as external module for this kernel version.
[...]
if batman-adv don't support archlinux really , whether ubuntu will support batman-adv .Hm? This doesn't make a lot of sense. batman-adv doesn't require special distribution support. It is just a Linux kernel module. You have to find out what other things (hw/drivers/tc/iptables/...) are causing the problems on your system.
And I even know of people that use Arch Linux on their Freifunk supernodes together with batman-adv.
Kind regards, Sven
On Montag, 24. Oktober 2016 17:08:44 CEST johnzeng wrote:
What kind of "caution" info? When i start ping hostb from hosta , i catch error info via dmesg , this is parts info please see attactment of email about more error info .
Try on both systems to disable rx/tx checksum offloading:
ethtool -K eth0 rx off tx off
Kind regards, Sven
b.a.t.m.a.n@lists.open-mesh.org
-
johnzeng -
Sven Eckelmann -
tiger