Hello Gabriel,
first of all thank you very much for testing the bw meter :-) answers follow inline.
On Mon, Jun 03, 2013 at 12:57:24PM -0300, Gabriel Tolón wrote:
Hi Antonio,
As you suggested, I've tested the bandwidth meter with batman-adv-devel 38a1b72. I've installed it on two TP-Link WDR-3500 routers.
oky. However, since the bw_meter has not been merged yet, its branch changes from time to time because it gets rebased on top of the very latest development code. Therefore, when you decide to update your testbed, I'd suggest you to look at: http://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/ordex/bw_meter and pick the commit ID of the last patch at the top.
If you have problems in doing this, please ask.
Running normal iperf inside the routers, and without unloading any kernel module, I get 60 Mbps using UDP, 80 Mbps using TCP (I don't understand why TCP works better), and about 4 Mbps with batctl bw -t 10000. Any ideas? By the way, the batctl ping between routers doesn't work, I get time-out. Besides, there's another strange behaviour, when I try to pass traffic from a PC client connected to one router, to the other router using iperf, if I use UDP values of about 100 Mbps, the router that receives the traffic and redirects it, reboots. Thanks.
Ok..well, first of all I'd rather check what is wrong in the mesh. If batctl ping does not work, then it means that there is something else which is not working/configured properly.
For this reason I'll first suggest you to update to this commit id: d672369 . Then, does "batctl o" properly shows the other node with a "reasonable TQ"?
By the way, your iperf tests have been done on top of batman-adv? or directly on the wifi interface?
Cheers,
Hi Antonio,
El 03/06/13 13:08, Antonio Quartulli escribió:
Hello Gabriel,
first of all thank you very much for testing the bw meter :-) answers follow inline.
You're welcome, I think it's an interesting idea.
On Mon, Jun 03, 2013 at 12:57:24PM -0300, Gabriel Tolón wrote:
Hi Antonio, As you suggested, I've tested the bandwidth meter with batman-adv-devel 38a1b72. I've installed it on two TP-Link WDR-3500 routers.oky. However, since the bw_meter has not been merged yet, its branch changes from time to time because it gets rebased on top of the very latest development code. Therefore, when you decide to update your testbed, I'd suggest you to look at: http://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/ordex/bw_meter and pick the commit ID of the last patch at the top.
If you have problems in doing this, please ask.
I don't understand what commit ids should I use. For example, how could I find the ones you suggested me before for batman (38a1b72b6) and for batctl (eebba0bfb). Because on the top of the git I see for example the commit d672369c3476f002662fa7e83b76ee56a93a76db for "batman-adv: set maximum number of BW session", which seems in a different format, right?
Running normal iperf inside the routers, and without unloading any kernel module, I get 60 Mbps using UDP, 80 Mbps using TCP (I don't understand why TCP works better), and about 4 Mbps with batctl bw -t 10000. Any ideas? By the way, the batctl ping between routers doesn't work, I get time-out. Besides, there's another strange behaviour, when I try to pass traffic from a PC client connected to one router, to the other router using iperf, if I use UDP values of about 100 Mbps, the router that receives the traffic and redirects it, reboots. Thanks.Ok..well, first of all I'd rather check what is wrong in the mesh. If batctl ping does not work, then it means that there is something else which is not working/configured properly.
Yes, it's weird, specially because there's connectivity between routers thanks to batman-adv.
For this reason I'll first suggest you to update to this commit id: d672369 . Then, does "batctl o" properly shows the other node with a "reasonable TQ"?
So, in menuconfig I should select that id for batman-adv-devel right? I wanted to see that commit on the git page using the search field but I couldn't. By the way, how to know which batctl version use with each batman-adv-devel commit? Sorry if all these questions are too basic, but I've tried to compile with this d672369 version and I got some errors, so I'd like to understand if it was related to these things.
By the way, your iperf tests have been done on top of batman-adv? or directly on the wifi interface?
Cheers,
I got the results mentioned using interfaces managed by batman-adv.
Regards
Gabriel
On Mon, Jun 03, 2013 at 05:54:15PM -0300, Gabriel Tolón wrote:
Hi Antonio,
El 03/06/13 13:08, Antonio Quartulli escribió:
Hello Gabriel,
first of all thank you very much for testing the bw meter :-) answers follow inline.
You're welcome, I think it's an interesting idea.
On Mon, Jun 03, 2013 at 12:57:24PM -0300, Gabriel Tolón wrote:
Hi Antonio, As you suggested, I've tested the bandwidth meter with batman-adv-devel 38a1b72. I've installed it on two TP-Link WDR-3500 routers.oky. However, since the bw_meter has not been merged yet, its branch changes from time to time because it gets rebased on top of the very latest development code. Therefore, when you decide to update your testbed, I'd suggest you to look at: http://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/ordex/bw_meter and pick the commit ID of the last patch at the top.
If you have problems in doing this, please ask.
I don't understand what commit ids should I use. For example, how could I find the ones you suggested me before for batman (38a1b72b6) and for batctl (eebba0bfb). Because on the top of the git I see for example the commit d672369c3476f002662fa7e83b76ee56a93a76db for "batman-adv: set maximum number of BW session", which seems in a different format, right?
Right. Becuase it changes everytime the tree is rebased. Now you won't fin that commit ID anymore. Now you should use the _new_ commit ID of: "batman-adv: set maximum number of BW session" (it is not important to change everytime it changes on the git, but in case of troubles, it may be a good idea to use the current one to see if the problems are still there).
Running normal iperf inside the routers, and without unloading any kernel module, I get 60 Mbps using UDP, 80 Mbps using TCP (I don't understand why TCP works better), and about 4 Mbps with batctl bw -t 10000. Any ideas? By the way, the batctl ping between routers doesn't work, I get time-out. Besides, there's another strange behaviour, when I try to pass traffic from a PC client connected to one router, to the other router using iperf, if I use UDP values of about 100 Mbps, the router that receives the traffic and redirects it, reboots. Thanks.Ok..well, first of all I'd rather check what is wrong in the mesh. If batctl ping does not work, then it means that there is something else which is not working/configured properly.
Yes, it's weird, specially because there's connectivity between routers thanks to batman-adv.
For this reason I'll first suggest you to update to this commit id: d672369 . Then, does "batctl o" properly shows the other node with a "reasonable TQ"?
So, in menuconfig I should select that id for batman-adv-devel right? I wanted to see that commit on the git page using the search field but I couldn't. By the way, how to know which batctl version use with each batman-adv-devel commit? Sorry if all these questions are too basic, but I've tried to compile with this d672369 version and I got some errors, so I'd like to understand if it was related to these things.
no problems. These are not basic questions :) Actually the user usually do not enter these dev details and therefore it is normal to find issues.
For batctl, you should use the last commit ID in this branch (ordex/bw_meter) http://git.open-mesh.org/batctl.git/shortlog/refs/heads/ordex/bw_meter
By the way, your iperf tests have been done on top of batman-adv? or directly on the wifi interface?
Cheers,
I got the results mentioned using interfaces managed by batman-adv.
mh...maybe the pign is not working because of some changes brought by the bw_meter in the icmp packets. I'll check and I'll let you know.
Cheers,
On Tue, Jun 04, 2013 at 07:13:26AM +0200, Antonio Quartulli wrote:
On Mon, Jun 03, 2013 at 05:54:15PM -0300, Gabriel Tolón wrote:
So, in menuconfig I should select that id for batman-adv-devel right? I wanted to see that commit on the git page using the search field but I couldn't. By the way, how to know which batctl version use with each batman-adv-devel commit? Sorry if all these questions are too basic, but I've tried to compile with this d672369 version and I got some errors, so I'd like to understand if it was related to these things.
no problems. These are not basic questions :) Actually the user usually do not enter these dev details and therefore it is normal to find issues.
For batctl, you should use the last commit ID in this branch (ordex/bw_meter) http://git.open-mesh.org/batctl.git/shortlog/refs/heads/ordex/bw_meter
By the way, your iperf tests have been done on top of batman-adv? or directly on the wifi interface?
Cheers,
I got the results mentioned using interfaces managed by batman-adv.
mh...maybe the pign is not working because of some changes brought by the bw_meter in the icmp packets. I'll check and I'll let you know.
I juested the current ordex/bw_meter branches (batctl and batman-adv) and the ping works fine.
Please, let me know your results.
Cheers,
Hi,
Now I'm with batman-adv 5ffa8f201d085764365d202ace14675032cc3a74, batctl 6d3d4d1f80dca31b6400f3794772016cdbc19a73, and openwrt r36826.
The results are almost the same, no batctl pings, and batctl bw much slower than iperfs. wdr3500 have 2 radios, these are the routes:
El 04/06/13 02:38, Antonio Quartulli escribió:
On Tue, Jun 04, 2013 at 07:13:26AM +0200, Antonio Quartulli wrote:
On Mon, Jun 03, 2013 at 05:54:15PM -0300, Gabriel Tolón wrote:
So, in menuconfig I should select that id for batman-adv-devel right? I wanted to see that commit on the git page using the search field but I couldn't. By the way, how to know which batctl version use with each batman-adv-devel commit? Sorry if all these questions are too basic, but I've tried to compile with this d672369 version and I got some errors, so I'd like to understand if it was related to these things.
no problems. These are not basic questions :) Actually the user usually do not enter these dev details and therefore it is normal to find issues.
For batctl, you should use the last commit ID in this branch (ordex/bw_meter) http://git.open-mesh.org/batctl.git/shortlog/refs/heads/ordex/bw_meter
By the way, your iperf tests have been done on top of batman-adv? or directly on the wifi interface?
Cheers,
I got the results mentioned using interfaces managed by batman-adv.
mh...maybe the pign is not working because of some changes brought by the bw_meter in the icmp packets. I'll check and I'll let you know.
I juested the current ordex/bw_meter branches (batctl and batman-adv) and the ping works fine.
Please, let me know your results.
Cheers,
Sorry, I sent the mail incomplete,
So these are the routes:
Equipo1:
root@Equipo 1:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:42 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E3-5GHz 0.680s (251) E3-5GHz [ wlan1-1]: E3-5GHz (251) E3-2GHz 0.430s (255) E3-5GHz [ wlan1-1]: E3-5GHz (255) E3-2GHz (252)
Equipo3:
root@Equipo 3:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:d6 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E1-2GHz 0.310s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255) E1-2GHz (255) E1-5GHz 0.550s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255)
The results of batctl pings:
Equipo1:
root@Equipo 1:~# batctl ping E3-2GHz PING E3-2GHz (66:70:02:4e:d9:d6) 20(48) bytes of data Reply from host E3-2GHz timed out Reply from host E3-2GHz timed out
root@Equipo 1:~# batctl ping E3-5GHz PING E3-5GHz (66:70:02:4e:d9:d7) 20(48) bytes of data Reply from host E3-5GHz timed out Reply from host E3-5GHz timed out
Equipo3:
root@Equipo 3:~# batctl ping E1-2GHz PING E1-2GHz (66:70:02:4e:d9:42) 20(48) bytes of data Reply from host E1-2GHz timed out Reply from host E1-2GHz timed out
root@Equipo 3:~# batctl ping E1-5GHz PING E1-5GHz (66:70:02:4e:d9:43) 20(48) bytes of data Reply from host E1-5GHz timed out Reply from host E1-5GHz timed out
If there is more info I could send you just tell me.
Regards
Gabriel
El 05/06/13 12:17, Gabriel Tolón escribió:
Hi,
Now I'm with batman-adv 5ffa8f201d085764365d202ace14675032cc3a74, batctl 6d3d4d1f80dca31b6400f3794772016cdbc19a73, and openwrt r36826.
The results are almost the same, no batctl pings, and batctl bw much slower than iperfs. wdr3500 have 2 radios, these are the routes:
El 04/06/13 02:38, Antonio Quartulli escribió:
On Tue, Jun 04, 2013 at 07:13:26AM +0200, Antonio Quartulli wrote:
On Mon, Jun 03, 2013 at 05:54:15PM -0300, Gabriel Tolón wrote:
So, in menuconfig I should select that id for batman-adv-devel right? I wanted to see that commit on the git page using the search field but I couldn't. By the way, how to know which batctl version use with each batman-adv-devel commit? Sorry if all these questions are too basic, but I've tried to compile with this d672369 version and I got some errors, so I'd like to understand if it was related to these things.
no problems. These are not basic questions :) Actually the user usually do not enter these dev details and therefore it is normal to find issues.
For batctl, you should use the last commit ID in this branch (ordex/bw_meter) http://git.open-mesh.org/batctl.git/shortlog/refs/heads/ordex/bw_meter
By the way, your iperf tests have been done on top of batman-adv? or directly on the wifi interface?
Cheers,
I got the results mentioned using interfaces managed by batman-adv.
mh...maybe the pign is not working because of some changes brought by the bw_meter in the icmp packets. I'll check and I'll let you know.
I juested the current ordex/bw_meter branches (batctl and batman-adv) and the ping works fine.
Please, let me know your results.
Cheers,
Hello Gabriel,
On Wed, Jun 05, 2013 at 12:27:48PM -0300, Gabriel Tolón wrote:
Sorry, I sent the mail incomplete,
So these are the routes:
Equipo1:
root@Equipo 1:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:42 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E3-5GHz 0.680s (251) E3-5GHz [ wlan1-1]: E3-5GHz (251) E3-2GHz 0.430s (255) E3-5GHz [ wlan1-1]: E3-5GHz (255) E3-2GHz (252)
Equipo3:
root@Equipo 3:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:d6 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E1-2GHz 0.310s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255) E1-2GHz (255) E1-5GHz 0.550s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255)
routing tables look good. I am wondering where the problem can be.. Can you try to do a "batctl td wlan0-1" while pinging? this may help to understand where the process is blocking. It would be helpful if you could do that on both the nodes while pinging in only one direction This way we see who receives what.
(commit IDs are ok) Thank you very much for helping us in debugging this :)
Cheers,
Hi Antonio,
El 06/06/13 02:51, Antonio Quartulli escribió:
Hello Gabriel,
On Wed, Jun 05, 2013 at 12:27:48PM -0300, Gabriel Tolón wrote:
Sorry, I sent the mail incomplete,
So these are the routes:
Equipo1:
root@Equipo 1:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:42 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E3-5GHz 0.680s (251) E3-5GHz [ wlan1-1]: E3-5GHz (251) E3-2GHz 0.430s (255) E3-5GHz [ wlan1-1]: E3-5GHz (255) E3-2GHz (252)
Equipo3:
root@Equipo 3:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:d6 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E1-2GHz 0.310s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255) E1-2GHz (255) E1-5GHz 0.550s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255)
routing tables look good. I am wondering where the problem can be.. Can you try to do a "batctl td wlan0-1" while pinging? this may help to understand where the process is blocking. It would be helpful if you could do that on both the nodes while pinging in only one direction This way we see who receives what.
I did it, but the text files for the logs of the nodes with "batctl td" have a size of about 250 kB each one, with just 1 or 2 seconds logging. Is that too much for sending them to the list?
(commit IDs are ok) Thank you very much for helping us in debugging this :)
No problem! I've asked things to this list many times and I've got useful answers, so I'm pleased to cooperate.
Regards
Gabriel
On Thu, Jun 06, 2013 at 03:19:00PM -0300, Gabriel Tolón wrote:
Hi Antonio,
El 06/06/13 02:51, Antonio Quartulli escribió:
Hello Gabriel,
On Wed, Jun 05, 2013 at 12:27:48PM -0300, Gabriel Tolón wrote:
Sorry, I sent the mail incomplete,
So these are the routes:
Equipo1:
root@Equipo 1:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:42 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E3-5GHz 0.680s (251) E3-5GHz [ wlan1-1]: E3-5GHz (251) E3-2GHz 0.430s (255) E3-5GHz [ wlan1-1]: E3-5GHz (255) E3-2GHz (252)
Equipo3:
root@Equipo 3:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:d6 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E1-2GHz 0.310s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255) E1-2GHz (255) E1-5GHz 0.550s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255)
routing tables look good. I am wondering where the problem can be.. Can you try to do a "batctl td wlan0-1" while pinging? this may help to understand where the process is blocking. It would be helpful if you could do that on both the nodes while pinging in only one direction This way we see who receives what.
I did it, but the text files for the logs of the nodes with "batctl td" have a size of about 250 kB each one, with just 1 or 2 seconds logging. Is that too much for sending them to the list?
maybe you can upload them somewhere and then send the link here?
Thanks
El 06/06/13 15:29, Antonio Quartulli escribió:
On Thu, Jun 06, 2013 at 03:19:00PM -0300, Gabriel Tolón wrote:
Hi Antonio,
El 06/06/13 02:51, Antonio Quartulli escribió:
Hello Gabriel,
On Wed, Jun 05, 2013 at 12:27:48PM -0300, Gabriel Tolón wrote:
Sorry, I sent the mail incomplete,
So these are the routes:
Equipo1:
root@Equipo 1:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:42 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E3-5GHz 0.680s (251) E3-5GHz [ wlan1-1]: E3-5GHz (251) E3-2GHz 0.430s (255) E3-5GHz [ wlan1-1]: E3-5GHz (255) E3-2GHz (252)
Equipo3:
root@Equipo 3:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:d6 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E1-2GHz 0.310s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255) E1-2GHz (255) E1-5GHz 0.550s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255)
routing tables look good. I am wondering where the problem can be.. Can you try to do a "batctl td wlan0-1" while pinging? this may help to understand where the process is blocking. It would be helpful if you could do that on both the nodes while pinging in only one direction This way we see who receives what.
I did it, but the text files for the logs of the nodes with "batctl td" have a size of about 250 kB each one, with just 1 or 2 seconds logging. Is that too much for sending them to the list?
maybe you can upload them somewhere and then send the link here?
Yes, should be here:
the batctl ping was from E1 to E3.
Regards
Gabriel
On Thu, Jun 06, 2013 at 04:04:35PM -0300, Gabriel Tolón wrote:
El 06/06/13 15:29, Antonio Quartulli escribió:
On Thu, Jun 06, 2013 at 03:19:00PM -0300, Gabriel Tolón wrote:
Hi Antonio,
El 06/06/13 02:51, Antonio Quartulli escribió:
Hello Gabriel,
On Wed, Jun 05, 2013 at 12:27:48PM -0300, Gabriel Tolón wrote:
Sorry, I sent the mail incomplete,
So these are the routes:
Equipo1:
root@Equipo 1:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:42 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E3-5GHz 0.680s (251) E3-5GHz [ wlan1-1]: E3-5GHz (251) E3-2GHz 0.430s (255) E3-5GHz [ wlan1-1]: E3-5GHz (255) E3-2GHz (252)
Equipo3:
root@Equipo 3:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:d6 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E1-2GHz 0.310s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255) E1-2GHz (255) E1-5GHz 0.550s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255)
routing tables look good. I am wondering where the problem can be.. Can you try to do a "batctl td wlan0-1" while pinging? this may help to understand where the process is blocking. It would be helpful if you could do that on both the nodes while pinging in only one direction This way we see who receives what.
I did it, but the text files for the logs of the nodes with "batctl td" have a size of about 250 kB each one, with just 1 or 2 seconds logging. Is that too much for sending them to the list?
maybe you can upload them somewhere and then send the link here?
Yes, should be here:
the batctl ping was from E1 to E3.
Hello Gabriel, there is a lot of noise because you are also generating traffic on the network. However I can see the ICMP Echo Request and then an Echo Reply, therefore the two nodes seem to be exchanging ICMP packets correctly.
I'm checking again to try to understand what went wrong.
Meanwhile, can you please report the output of "batctl l" during a bw test after having set the bw_meter log level by running "batctl ll bwm" ?
To get the exact log of one test, you can first run batctl l (this will print all the past log), then you run the test and then you run batctl l again to obtain the interesting log. Please upload it on pastebin too.
Thanks a lot!
El 06/06/13 16:18, Antonio Quartulli escribió:
On Thu, Jun 06, 2013 at 04:04:35PM -0300, Gabriel Tolón wrote:
El 06/06/13 15:29, Antonio Quartulli escribió:
On Thu, Jun 06, 2013 at 03:19:00PM -0300, Gabriel Tolón wrote:
Hi Antonio,
El 06/06/13 02:51, Antonio Quartulli escribió:
Hello Gabriel,
On Wed, Jun 05, 2013 at 12:27:48PM -0300, Gabriel Tolón wrote:
Sorry, I sent the mail incomplete,
So these are the routes:
Equipo1:
root@Equipo 1:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:42 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E3-5GHz 0.680s (251) E3-5GHz [ wlan1-1]: E3-5GHz (251) E3-2GHz 0.430s (255) E3-5GHz [ wlan1-1]: E3-5GHz (255) E3-2GHz (252)
Equipo3:
root@Equipo 3:~# batctl o [B.A.T.M.A.N. adv 5ffa8f2, MainIF/MAC: wlan0-1/66:70:02:4e:d9:d6 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... E1-2GHz 0.310s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255) E1-2GHz (255) E1-5GHz 0.550s (255) E1-5GHz [ wlan1-1]: E1-5GHz (255)
routing tables look good. I am wondering where the problem can be.. Can you try to do a "batctl td wlan0-1" while pinging? this may help to understand where the process is blocking. It would be helpful if you could do that on both the nodes while pinging in only one direction This way we see who receives what.
I did it, but the text files for the logs of the nodes with "batctl td" have a size of about 250 kB each one, with just 1 or 2 seconds logging. Is that too much for sending them to the list?
maybe you can upload them somewhere and then send the link here?
Yes, should be here:
the batctl ping was from E1 to E3.
Hello Gabriel, there is a lot of noise because you are also generating traffic on the network. However I can see the ICMP Echo Request and then an Echo Reply, therefore the two nodes seem to be exchanging ICMP packets correctly.
I'm checking again to try to understand what went wrong.
Meanwhile, can you please report the output of "batctl l" during a bw test after having set the bw_meter log level by running "batctl ll bwm" ?
To get the exact log of one test, you can first run batctl l (this will print all the past log), then you run the test and then you run batctl l again to obtain the interesting log. Please upload it on pastebin too.
Thanks a lot!
Sure, here they are:
Hi Gabriel,
thank you for your logs
On Fri, Jun 07, 2013 at 10:49:10AM -0300, Gabriel Tolón wrote:
Hello Gabriel, there is a lot of noise because you are also generating traffic on the network. However I can see the ICMP Echo Request and then an Echo Reply, therefore the two nodes seem to be exchanging ICMP packets correctly.
I'm checking again to try to understand what went wrong.
Meanwhile, can you please report the output of "batctl l" during a bw test after having set the bw_meter log level by running "batctl ll bwm" ?
To get the exact log of one test, you can first run batctl l (this will print all the past log), then you run the test and then you run batctl l again to obtain the interesting log. Please upload it on pastebin too.
Thanks a lot!
Sure, here they are:
From this log I can see that the protocol is entering Fast Retransmit many times and this happens due to reordering or small losses (the latter option is more realistic on a single hop network - but is it really one hop? I never asked).
The other strange thing I see is the final SRTT value which is 260ms and looks pretty high. Is there anything else going on the network (other traffic or..)?
Cheers,
Hi,
El 07/06/13 10:57, Antonio Quartulli escribió:
Hi Gabriel,
thank you for your logs
On Fri, Jun 07, 2013 at 10:49:10AM -0300, Gabriel Tolón wrote:
Hello Gabriel, there is a lot of noise because you are also generating traffic on the network. However I can see the ICMP Echo Request and then an Echo Reply, therefore the two nodes seem to be exchanging ICMP packets correctly.
I'm checking again to try to understand what went wrong.
Meanwhile, can you please report the output of "batctl l" during a bw test after having set the bw_meter log level by running "batctl ll bwm" ?
To get the exact log of one test, you can first run batctl l (this will print all the past log), then you run the test and then you run batctl l again to obtain the interesting log. Please upload it on pastebin too.
Thanks a lot!
Sure, here they are:
From this log I can see that the protocol is entering Fast Retransmit many times and this happens due to reordering or small losses (the latter option is more realistic on a single hop network - but is it really one hop? I never asked).
Yes, it's one hop. Just two routers at a distance of 2 meters. They have two radios, but in the last tests I've unloaded one of them (the 5 Ghz one) to make it simpler, so they see each other just by one radio interface.
The other strange thing I see is the final SRTT value which is 260ms and looks pretty high. Is there anything else going on the network (other traffic or..)?
Mmm, I don't know what's that SRTT, but no, there shouldn't be anything else in the air, at least not from me. But If there were interference or something like that, normal iperf would be slower I guess.
Besides, now I've tested connecting my PC via Ethernet to log avoiding interference from myself, also unloading the 2GHz, and loading the 5GHz in the routers (the 5GHz band should be cleaner), and the batctl bw keeps with slower values than iperf, 5Mbps this time.
If you want I could sniff the air with wireshark or something.
Maybe other possibility could be testing the bw meter connecting the routers by etnernet and not wirelessly?
Just for curiosity, you have already tested this on other scenarios and worked OK?
Regards
Gabriel
On Fri, Jun 07, 2013 at 11:38:26AM -0300, Gabriel Tolón wrote:
Hi,
El 07/06/13 10:57, Antonio Quartulli escribió:
Hi Gabriel,
thank you for your logs
On Fri, Jun 07, 2013 at 10:49:10AM -0300, Gabriel Tolón wrote:
Hello Gabriel, there is a lot of noise because you are also generating traffic on the network. However I can see the ICMP Echo Request and then an Echo Reply, therefore the two nodes seem to be exchanging ICMP packets correctly.
I'm checking again to try to understand what went wrong.
Meanwhile, can you please report the output of "batctl l" during a bw test after having set the bw_meter log level by running "batctl ll bwm" ?
To get the exact log of one test, you can first run batctl l (this will print all the past log), then you run the test and then you run batctl l again to obtain the interesting log. Please upload it on pastebin too.
Thanks a lot!
Sure, here they are:
From this log I can see that the protocol is entering Fast Retransmit many times and this happens due to reordering or small losses (the latter option is more realistic on a single hop network - but is it really one hop? I never asked).
Yes, it's one hop. Just two routers at a distance of 2 meters. They have two radios, but in the last tests I've unloaded one of them (the 5 Ghz one) to make it simpler, so they see each other just by one radio interface.
The other strange thing I see is the final SRTT value which is 260ms and looks pretty high. Is there anything else going on the network (other traffic or..)?
Mmm, I don't know what's that SRTT, but no, there shouldn't be anything else in the air, at least not from me. But If there were interference or something like that, normal iperf would be slower I guess.
Besides, now I've tested connecting my PC via Ethernet to log avoiding interference from myself, also unloading the 2GHz, and loading the 5GHz in the routers (the 5GHz band should be cleaner), and the batctl bw keeps with slower values than iperf, 5Mbps this time.
If you want I could sniff the air with wireshark or something.
Maybe other possibility could be testing the bw meter connecting the routers by etnernet and not wirelessly?
Yes, you can try ethernet too. it works the same way.
Just for curiosity, you have already tested this on other scenarios and worked OK?
yeah, I tested it using my routers (OM2Ps) and it worked good.
You can try to sniff one or two seconds of traffic with "batctl td" on the nodes. This will give us what is exactly going in the air.
Cheers,
El 07/06/13 11:40, Antonio Quartulli escribió:
On Fri, Jun 07, 2013 at 11:38:26AM -0300, Gabriel Tolón wrote:
Hi,
El 07/06/13 10:57, Antonio Quartulli escribió:
Hi Gabriel,
thank you for your logs
On Fri, Jun 07, 2013 at 10:49:10AM -0300, Gabriel Tolón wrote:
Hello Gabriel, there is a lot of noise because you are also generating traffic on the network. However I can see the ICMP Echo Request and then an Echo Reply, therefore the two nodes seem to be exchanging ICMP packets correctly.
I'm checking again to try to understand what went wrong.
Meanwhile, can you please report the output of "batctl l" during a bw test after having set the bw_meter log level by running "batctl ll bwm" ?
To get the exact log of one test, you can first run batctl l (this will print all the past log), then you run the test and then you run batctl l again to obtain the interesting log. Please upload it on pastebin too.
Thanks a lot!
Sure, here they are:
From this log I can see that the protocol is entering Fast Retransmit many times and this happens due to reordering or small losses (the latter option is more realistic on a single hop network - but is it really one hop? I never asked).
Yes, it's one hop. Just two routers at a distance of 2 meters. They have two radios, but in the last tests I've unloaded one of them (the 5 Ghz one) to make it simpler, so they see each other just by one radio interface.
The other strange thing I see is the final SRTT value which is 260ms and looks pretty high. Is there anything else going on the network (other traffic or..)?
Mmm, I don't know what's that SRTT, but no, there shouldn't be anything else in the air, at least not from me. But If there were interference or something like that, normal iperf would be slower I guess.
Besides, now I've tested connecting my PC via Ethernet to log avoiding interference from myself, also unloading the 2GHz, and loading the 5GHz in the routers (the 5GHz band should be cleaner), and the batctl bw keeps with slower values than iperf, 5Mbps this time.
If you want I could sniff the air with wireshark or something.
Maybe other possibility could be testing the bw meter connecting the routers by etnernet and not wirelessly?
Yes, you can try ethernet too. it works the same way.
Just for curiosity, you have already tested this on other scenarios and worked OK?
yeah, I tested it using my routers (OM2Ps) and it worked good.
You can try to sniff one or two seconds of traffic with "batctl td" on the nodes. This will give us what is exactly going in the air.
Cheers,
This time, I logged just from Equipo 1, to generate less traffic.
I noticed something weird. When I run batctl bw I get this time something like 12 Mbps. If I wait for about 10 seconds and repeat the command, I get something similar, but, if I run the command inmediatly after the bw test finishes, the result improves a lot, here you can see the commands with the seconds between them:
root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:09 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 3064500 Bytes. Throughput: 1.46 MB/s (12.26 Mbps) root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:15 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 3201000 Bytes. Throughput: 1.53 MB/s (12.80 Mbps) root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:18 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 14545500 Bytes. Throughput: 6.94 MB/s (58.18 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:20 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 18729000 Bytes. Throughput: 8.93 MB/s (74.91 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:23 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 21067500 Bytes. Throughput: 10.05 MB/s (84.26 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:26 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 22351500 Bytes. Throughput: 10.66 MB/s (89.40 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:37 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 13281000 Bytes. Throughput: 6.33 MB/s (53.12 Mbps) root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:49 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 3204000 Bytes. Throughput: 1.53 MB/s (12.82 Mbps) root@Equipo 1:~#
Maybe something in the time calculation is wrong?
The logs are too heavy for pastebin, so here it's just the part corresponding to the first batctl bw in Equipo1:
If you want to watch the whole log I can send you, or paste it in parts.
Regards
Hello Gabriel,
On Fri, Jun 07, 2013 at 02:13:18PM -0300, Gabriel Tolón wrote:
This time, I logged just from Equipo 1, to generate less traffic.
I noticed something weird. When I run batctl bw I get this time something like 12 Mbps. If I wait for about 10 seconds and repeat the command, I get something similar, but, if I run the command inmediatly after the bw test finishes, the result improves a lot, here you can see the commands with the seconds between them:
root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:09 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 3064500 Bytes. Throughput: 1.46 MB/s (12.26 Mbps) root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:15 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 3201000 Bytes. Throughput: 1.53 MB/s (12.80 Mbps) root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:18 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 14545500 Bytes. Throughput: 6.94 MB/s (58.18 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:20 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 18729000 Bytes. Throughput: 8.93 MB/s (74.91 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:23 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 21067500 Bytes. Throughput: 10.05 MB/s (84.26 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:26 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 22351500 Bytes. Throughput: 10.66 MB/s (89.40 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:37 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 13281000 Bytes. Throughput: 6.33 MB/s (53.12 Mbps) root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:49 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 3204000 Bytes. Throughput: 1.53 MB/s (12.82 Mbps) root@Equipo 1:~#
Maybe something in the time calculation is wrong?
This strange. The point is that the receiver takes at least 1 second to shutdown the session. Theoretically (and this is what happened during my tests) the receiver should refuse any "second new" connection and the sender should then get 0 throughput. Can I ask you what wifi driver is your device using? Anyway, there must be something wrong in the bw meter given that you see this behaviour only with it and not with iperf.
Did you try a short run over Ethernet? I'm curious to see if the behaviour will be the same.
The logs aretoo heavy for pastebin, so here it's just the part corresponding to the first batctl bw in Equipo1:
Thanks for the log.
I saw something strange:
16:40:09.533172 BAT 64:70:02:4e:d9:43 > E3-5GHz: ICMP BW type MSG (0), id 0, seq 2018499, ttl 50, v 15, length 1510 16:40:09.533392 BAT 64:70:02:4e:d9:43 > E3-5GHz: ICMP BW type MSG (0), id 0, seq 2049999, ttl 50, v 15, length 1510
These are two packets sent one after the other but the second sequence number is not equal to the first + 1500 (payload size)
If you want to watch the whole log I can send you, or paste it in parts.
This gave me already some hints. I'll dig into the code to try to spot what's wrong. But strange that I did not see any problem during my tests..maybe something introduced later by accident.
Thank you so far. I'm still curious about the Ethernet test, then I'll try to upload some more code to test :)
Cheers,
On Fri, Jun 07, 2013 at 07:27:34PM +0200, Antonio Quartulli wrote:
Thanks for the log.
I saw something strange:
16:40:09.533172 BAT 64:70:02:4e:d9:43 > E3-5GHz: ICMP BW type MSG (0), id 0, seq 2018499, ttl 50, v 15, length 1510 16:40:09.533392 BAT 64:70:02:4e:d9:43 > E3-5GHz: ICMP BW type MSG (0), id 0, seq 2049999, ttl 50, v 15, length 1510
These are two packets sent one after the other but the second sequence number is not equal to the first + 1500 (payload size)
After looking at the log again I think this issue is due to batctl td not being able to dump all the packets rather than some strange bw_meter behaviour...
clueless again :(
However, let's see if the Ethernet test gives us some more hints.
Cheers,
El 07/06/13 14:27, Antonio Quartulli escribió:
Hello Gabriel,
On Fri, Jun 07, 2013 at 02:13:18PM -0300, Gabriel Tolón wrote:
This time, I logged just from Equipo 1, to generate less traffic.
I noticed something weird. When I run batctl bw I get this time something like 12 Mbps. If I wait for about 10 seconds and repeat the command, I get something similar, but, if I run the command inmediatly after the bw test finishes, the result improves a lot, here you can see the commands with the seconds between them:
root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:09 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 3064500 Bytes. Throughput: 1.46 MB/s (12.26 Mbps) root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:15 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 3201000 Bytes. Throughput: 1.53 MB/s (12.80 Mbps) root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:18 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 14545500 Bytes. Throughput: 6.94 MB/s (58.18 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:20 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 18729000 Bytes. Throughput: 8.93 MB/s (74.91 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:23 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 21067500 Bytes. Throughput: 10.05 MB/s (84.26 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:26 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 22351500 Bytes. Throughput: 10.66 MB/s (89.40 Mbps) root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:37 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 13281000 Bytes. Throughput: 6.33 MB/s (53.12 Mbps) root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-5GHz Fri Jun 7 16:40:49 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d7 Test over in 2000ms. Sent 3204000 Bytes. Throughput: 1.53 MB/s (12.82 Mbps) root@Equipo 1:~#
Maybe something in the time calculation is wrong?
This strange. The point is that the receiver takes at least 1 second to shutdown the session. Theoretically (and this is what happened during my tests) the receiver should refuse any "second new" connection and the sender should then get 0 throughput. Can I ask you what wifi driver is your device using?
It's using ath9k.
Anyway, there must be something wrong in the bw meter given that you see this behaviour only with it and not with iperf.
Yes, with iperf I didn't notice anything strange.
Did you try a short run over Ethernet? I'm curious to see if the behaviour will be the same.
The logs aretoo heavy for pastebin, so here it's just the part corresponding to the first batctl bw in Equipo1:
Thanks for the log.
I saw something strange:
16:40:09.533172 BAT 64:70:02:4e:d9:43 > E3-5GHz: ICMP BW type MSG (0), id 0, seq 2018499, ttl 50, v 15, length 1510 16:40:09.533392 BAT 64:70:02:4e:d9:43 > E3-5GHz: ICMP BW type MSG (0), id 0, seq 2049999, ttl 50, v 15, length 1510
These are two packets sent one after the other but the second sequence number is not equal to the first + 1500 (payload size)
If you want to watch the whole log I can send you, or paste it in parts.
This gave me already some hints. I'll dig into the code to try to spot what's wrong. But strange that I did not see any problem during my tests..maybe something introduced later by accident.
Yes, that's strange, that's why I asked if you had tested the same. It couldn't be due to hardware differences? Just in case WDR3500 have AR9344 SoC.
Thank you so far. I'm still curious about the Ethernet test, then I'll try to upload some more code to test :)
Now I've made some tests with ethernet, with similar results:
root@Equipo 1:~# root@Equipo 1:~# root@Equipo 1:~# date; batctl bw -t 2000 E3-eth0 Fri Jun 7 18:36:10 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d5 Test over in 2000ms. Sent 1354500 Bytes. Throughput: 661.13 KB/s (5416.00 Kbps) root@Equipo 1:~# date; batctl bw -t 2000 E3-eth0 Fri Jun 7 18:36:14 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d5 Test over in 2000ms. Sent 1393500 Bytes. Throughput: 679.69 KB/s (5568.00 Kbps) root@Equipo 1:~# date; batctl bw -t 2000 E3-eth0 Fri Jun 7 18:36:17 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d5 Test over in 2000ms. Sent 5550000 Bytes. Throughput: 2.65 MB/s (22.20 Mbps) root@Equipo 1:~# date; batctl bw -t 2000 E3-eth0 Fri Jun 7 18:36:19 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d5 Test over in 2000ms. Sent 9412500 Bytes. Throughput: 4.49 MB/s (37.65 Mbps) root@Equipo 1:~# date; batctl bw -t 2000 E3-eth0 Fri Jun 7 18:36:26 UTC 2013 Bandwidth meter called towards 64:70:02:4e:d9:d5 Test over in 2000ms. Sent 1389000 Bytes. Throughput: 677.73 KB/s (5552.00 Kbps) root@Equipo 1:~#
Here the batctl td on Equipo1, like before, cut because of size:
This time there's a warning about an unknown batman packet type.
Regards
Gabriel
Hello Gabriel,
On Fri, Jun 07, 2013 at 03:57:29PM -0300, Gabriel Tolón wrote:
Yes, that's strange, that's why I asked if you had tested the same. It couldn't be due to hardware differences? Just in case WDR3500 have AR9344 SoC.
I guess it's the same:
system type : Atheros AR9344 rev 2
and this is one test I just performed:
# batctl bw a6:86:74:00:0f:12 Bandwidth meter called towards a6:86:74:00:0f:12 Test over in 10030ms. Sent 187528500 Bytes. Throughput: 17.83 MB/s (149.57 Mbps)
There must be something different in our setup that is probably triggering a bug in the bw_meter (I guess).
Here you have more results from tests performed a couple of weeks ago.
Maybe I find a couple of WDR3500 on which I can remotely try to debug the problem....
Cheers,
On Sat, Jun 08, 2013 at 02:29:39PM +0200, Antonio Quartulli wrote:
Here you have more results from tests performed a couple of weeks ago.
I forgot the link, sorry :-)
http://www.open-mesh.org/projects/batman-adv/wiki/Bandwidth_meter_tests
Cheers,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/08/2013 09:29 AM, Antonio Quartulli wrote:
Hello Gabriel,
On Fri, Jun 07, 2013 at 03:57:29PM -0300, Gabriel Tolón wrote:
Yes, that's strange, that's why I asked if you had tested the same. It couldn't be due to hardware differences? Just in case WDR3500 have AR9344 SoC.
I guess it's the same:
system type : Atheros AR9344 rev 2
and this is one test I just performed:
# batctl bw a6:86:74:00:0f:12 Bandwidth meter called towards a6:86:74:00:0f:12 Test over in 10030ms. Sent 187528500 Bytes. Throughput: 17.83 MB/s (149.57 Mbps)
There must be something different in our setup that is probably triggering a bug in the bw_meter (I guess).
Here you have more results from tests performed a couple of weeks ago.
Maybe I find a couple of WDR3500 on which I can remotely try to debug the problem....
Antonio, maybe you can use the WDR4300 routers from the battlemesh. Ufo reported on the WBM list they were still available online for testing. P4u (guifi) also mentioned he has a WDR... testbed.
cheers, Nico
Hi Antonio
El 08/06/13 09:29, Antonio Quartulli escribió:
Hello Gabriel,
On Fri, Jun 07, 2013 at 03:57:29PM -0300, Gabriel Tolón wrote:
Yes, that's strange, that's why I asked if you had tested the same. It couldn't be due to hardware differences? Just in case WDR3500 have AR9344 SoC.
I guess it's the same:
system type : Atheros AR9344 rev 2
and this is one test I just performed:
# batctl bw a6:86:74:00:0f:12 Bandwidth meter called towards a6:86:74:00:0f:12 Test over in 10030ms. Sent 187528500 Bytes. Throughput: 17.83 MB/s (149.57 Mbps)
Great!
There must be something different in our setup that is probably triggering a bug in the bw_meter (I guess).
Maybe. If you find something you want to try just tell me. Thanks!
Here you have more results from tests performed a couple of weeks ago.
Maybe I find a couple of WDR3500 on which I can remotely try to debug the problem....
Cheers,
Regards
Gabriel
b.a.t.m.a.n@lists.open-mesh.org
-
Antonio Quartulli -
Gabriel Tolón -
NicoEchániz