MikroTik

Ok, my current IP ban list blocked from my network:
/ip firewall address-list
add address=176.0.0.0/4 list=blocklist
add address=192.0.0.0/5 list=blocklist
add address=200.0.0.0/7 list=blocklist
add address=77.xx.xxx.132 list=blocklist
add address=160.0.0.0/4 list=blocklist

/ip firewall raw
add action=accept chain=prerouting comment="allow lan" src-address=192.168.0.0/24
add action=drop chain=prerouting comment="testers to block" src-address-list=blocklist
add action=accept chain=prerouting comment="testers accepted" src-address-list=tracking
add action=accept chain=prerouting comment="testers accepted" disabled=yes src-address-list=tester
add action=drop chain=prerouting comment="previous testers drop" disabled=yes src-address-list=previous
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" disabled=yes dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" disabled=yes dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" disabled=yes dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" disabled=yes dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp

I will also be changing my btest rules. I will remove the 5 minute limitation and the every 2 hour rules. The past 8 hours have proved effective and my CHR has not been abused otherwise. Enjoy.

planetcoop

Is this all I need to do to try your settings ?

[admin@207-32-195-2-CHR-P10] > ip
[admin@207-32-195-2-CHR-P10] /ip> firewall
[admin@207-32-195-2-CHR-P10] /ip firewall> export
# jun/07/2017 08:15:57 by RouterOS 6.39.2
# software id =
#
[admin@207-32-195-2-CHR-P10] /ip firewall> raw
[admin@207-32-195-2-CHR-P10] /ip firewall raw> export
# jun/07/2017 08:16:29 by RouterOS 6.39.2
# software id =
#
[admin@207-32-195-2-CHR-P10] /ip firewall raw> ..
[admin@207-32-195-2-CHR-P10] /ip firewall> export
# jun/07/2017 08:16:34 by RouterOS 6.39.2
# software id =
#
[admin@207-32-195-2-CHR-P10] /ip firewall> /ip firewall raw
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=accept chain=prerouting comment="testers accepted" src-address-list=tester
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=drop chain=prerouting comment="previous testers drop" src-address-list=previous
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=tcp
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=udp
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp
[admin@207-32-195-2-CHR-P10] /ip firewall raw>

planetcoop - is this correct and should work ?
I am not experienced with ROS firewalls. For core, in-house, for business firewalls, I generally use PfSense instead or Cisco firewalls.

North Idaho Tom Jones

That should be it with several assumptions, 5 minute test window every 2 hours based on source ip. This will also include your address ranges. Also that tcp/udp 2000-2100 for the port range.

That should be it with several assumptions, 5 minute test window every 2 hours based on source ip. This will also include your address ranges. Also that tcp/udp 2000-2100 for the port range.

OK - some questions:
- What is needed for a allow this network at all times? Such as I want to allow all of my Class C networks at all times where they skip the firewall raw configs.
- Is there a way to see what IP address are temporarily in the 2-hour blocked window & when those IPs entered that state?

/ip firewall address-list
add address=YOURNET/22 list=tester

/ip firewall raw
add action=accept chain=prerouting comment="allow lan" src-address=192.168.0.0/24
add action=drop chain=prerouting comment="testers to block" src-address-list=blocklist
add action=accept chain=prerouting comment="testers accepted" src-address-list=tracking
add action=accept chain=prerouting comment="testers accepted" disabled=yes src-address-list=tester
add action=drop chain=prerouting comment="previous testers drop" disabled=yes src-address-list=previous
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp

1st - a special thanks to planetcoop for all of his help and assistance and participation in the public btest servers for all Mikrotik admins.

Below is my 207.32.195.2 best server configuration (as of today):

[admin@207-32-195-2-CHR-P10] > export
# jun/07/2017 10:09:19 by RouterOS 6.39.2
# software id =
#
/interface ethernet
set [ find default-name=ether1 ] loop-protect=off
/queue simple
add burst-limit=3600M/3600M burst-threshold=500M/500M burst-time=11m40s/11m40s max-limit=500M/500M name=3.6-Gig
/snmp community
((( My SNMP configuration settings )))
/user group
add name=btest policy=test,winbox,romon,tikapp,!local,!telnet,!ssh,!ftp,!reboot,!read,!write,!policy,!password,!web,!sniff,!sensitive,!api,!dude
/ip address
add address=207.32.195.2/30 interface=ether1 network=207.32.195.0
/ip dns
set servers= ((( My DNS servers )))
/ip firewall address-list
add address= ((( One of my networks ))) list=tester
add address= ((( One of my networks ))) list=tester
add address= ((( One of my networks ))) list=tester
add address= ((( One of my networks ))) list=tester
add address= ((( One of my networks ))) list=tester
add address= ((( One of my networks ))) list=tester
/ip firewall raw
add action=accept chain=prerouting comment="allow lan" src-address=192.168.0.0/24
add action=drop chain=prerouting comment="testers to block" src-address-list=blocklist
add action=accept chain=prerouting comment="testers accepted" src-address-list=tracking
add action=accept chain=prerouting comment="testers accepted" disabled=yes src-address-list=tester
add action=drop chain=prerouting comment="previous testers drop" disabled=yes src-address-list=previous
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp
/ip route
add distance=1 gateway=207.32.195.1
/ip service
((( My NTP configuration setting )))
/snmp
((( My SNMP configuration settings )))
/system clock
set time-zone-autodetect=no time-zone-name=America/Los_Angeles
/system identity
set name=207-32-195-2-CHR-P10
/system ntp client
((( My NTP configuration settings )))
/tool graphing interface
add interface=ether1
/tool netwatch
add comment="btest server in Plummer at Red-Spectrum" host=207.32.195.2
[admin@207-32-195-2-CHR-P10] >

If any Mikrotik admins experience any new problems with my public 207.32.195.2 btest server, please let me know. Also, if it appears to be running normal and behaving as you have experienced in the recent past, again please let us know.

FYI - I will let some traffic pass for several hours then post a newer/updated bandwidth graph for this btest server.

Again - thanks to everybody who helps support everybody in this btest project Your comments and support help everybody

North Idaho Tom Jones

planetcoop

Question for you
what are the two grayed out items (marked inside the red box) and what do they do if I enable them - should they be enabled ?

Thanks
North Idaho Tom Jones

Sorry for the delay, but you should enable them. It enforces the 5 minute and 2 hour rules.

info btest server 207.32.195.2

I have some new rules in place in the configuration to block and stop "robo-btest testing". Where a remote mikrotik is scripted to perform robo btests to 207.32.195.2
Also
Please limit your btest tests to 1 minute. Anything longer will auto place you in a block for a period of time.

Note: When we see robo automated btest tests to the public btest servers - and when we see non-stop-continouis btest tests to the public btest servers, we conclude the following:
- Somebody is abusing the public btest servers
-and/or-
- Somebody may be abusing their Internet ISP by creating sustained network loads on their ISP and all router paths to the public btest servers

Again - Everybody is welcome to manually test to the btest servers, however please limit the actual btest session to 1-minute or less - and please wait a minimum of 15 minutes before starting your next btest. Please remember, there are many many many other Mikrotik admins in many countries also using these btest servers.

Thank you

North Idaho Tom Jones

Great news for the day, the DDOS was hitting "btest.planetcoop.com" has been blocked for the moment and the CHR up time is over 48 hours now. Additionally, this should allow for more beneficial test results. Please update us if you are having any issues with btest throughput.

First things first, thank you for making those servers available.

We got a solid performance from Geneva, Switzerland, Europe.


The graph page at https://btest.planetcoop.com:10443/graphs/iface/ether1/ didn't seem to show the test however.

First things first, thank you for making those servers available.

We got a solid performance from Geneva, Switzerland, Europe.


The graph page at https://btest.planetcoop.com:10443/graphs/iface/ether1/ didn't seem to show the test however.

Depending on the length of test the graph wont show it. I think the shortest interval is 5 minutes per average. You would have to run it for 5 or more minutes to start showing detail. If you would like you may run the test longer.

Thanks for the service Tom. Very useful one, in my opinion, it's great alternative to speedtest.

Happy to report this week that i have not seen any issues without blocking select ip addresses and a 5 minute per hour rule. Please let me know if you have issue with "btest.planetcoop.com". Also as it has been said before, if you have a special use case for a longer test or other requirement, please PM or post here so that we can help test and support the Mikrotik community.

Thanks for the service Tom. Very useful one, in my opinion, it's great alternative to speedtest.

Couldn't agree more, some good tool for speed test indeed.

Happy to report this week that i have not seen any issues without blocking select ip addresses and a 5 minute per hour rule. Please let me know if you have issue with "btest.planetcoop.com". Also as it has been said before, if you have a special use case for a longer test or other requirement, please PM or post here so that we can help test and support the Mikrotik community.

Can't seem to PM you, but would really like to discuss current list of blocked IPs, suspect I was a dipstick and left a btest running on a customers router by accident as a certain portion of our IPs seem to be unable to btest to btest.planetcoop.com now.

Happy to report this week that i have not seen any issues without blocking select ip addresses and a 5 minute per hour rule. Please let me know if you have issue with "btest.planetcoop.com". Also as it has been said before, if you have a special use case for a longer test or other requirement, please PM or post here so that we can help test and support the Mikrotik community.

Can't seem to PM you, but would really like to discuss current list of blocked IPs, suspect I was a dipstick and left a btest running on a customers router by accident as a certain portion of our IPs seem to be unable to btest to btest.planetcoop.com now.

I am currently using several rule sets to block ip addresses as discussed in this thread:
viewtopic.php?f=9&t=98804

Additionally i have the 5 minute btest rule per every hour as well. I have finally created one rule for a 5 minute test every 12 hours with an ending ip of .132. If this is your ip it is not a problem and i am willing to allow it to use the 5 minute out of the hour in my main rule set. At this point i am trying to understand the traffic patterns as you have seen my previous posts about abuse from Brazil-net AS network that are un-secure.

FYI, i am also not sure on the PM part of the forum.

PM is disabled.

Happy to report this week that i have not seen any issues without blocking select ip addresses and a 5 minute per hour rule. Please let me know if you have issue with "btest.planetcoop.com". Also as it has been said before, if you have a special use case for a longer test or other requirement, please PM or post here so that we can help test and support the Mikrotik community.

Can't seem to PM you, but would really like to discuss current list of blocked IPs, suspect I was a dipstick and left a btest running on a customers router by accident as a certain portion of our IPs seem to be unable to btest to btest.planetcoop.com now.

I am currently using several rule sets to block ip addresses as discussed in this thread:
viewtopic.php?f=9&t=98804

Additionally i have the 5 minute btest rule per every hour as well. I have finally created one rule for a 5 minute test every 12 hours with an ending ip of .132. If this is your ip it is not a problem and i am willing to allow it to use the 5 minute out of the hour in my main rule set. At this point i am trying to understand the traffic patterns as you have seen my previous posts about abuse from Brazil-net AS network that are un-secure.

FYI, i am also not sure on the PM part of the forum.

Ok, no that's not our IP. Would you be able to shoot me an email to ali@airbroadband.co.uk to discuss this further in private? I'm still having issues, and just looked at it further and there is some weird behaviour going on, potentially on your servers end?

I have sent an email. If anyone else has an issue please post here. I am not trying to eliminate bandwidth usage but I am trying to keep my network from contributing to internet abuses. Thank you.

may i know if the btest server is still active or online? at first its working on my end then today. i cant get any results.
thank you for sharing your network ^^,v

may i know if the btest server is still active or online? at first its working on my end then today. i cant get any results.
thank you for sharing your network ^^,v

My 207.32.195.2 btest server is working. (However I just rebooted it to make sure).

planetcoop and I ( TomJ North Idaho ) , both run public accessible Mikrotik CHR btest servers which are connected to the Internet using 10-gig interfaces.

We both made some changes somewhat recently which block/drop extended/lengthy/non-stop/frequently-repeating btests. We both have slightly different rules for the configuration.

My 207.32.195.2 btest test server (here in North Idaho) has the following:
- Max up/down speeds of about 3-gig btest
- I have a limit of about 2 minutes for a btest then the test auto terminates - then you will need to wait a few minutes before you can btest again.

I configured the rules on my 207.32.195.2 btest server because we were seeing extended/lengthy/non-stop btests and/or auto-repeating btests every minute of every hour of every day. This was preventing other btesters from getting good/clean btest results because the btest server bandwidth was shared between everybody testing at the same time - which made slower btest results for everybody testing at the same time.

I am pretty sure planetcoop has very similar reasons for his btest limits also.

Anyways - if you are testing to my North Idaho 207.32.195.2 btest server , try waiting 4 minutes , then run a btest for about 1 minute up , wait 4 minutes then run a btest for about 1 minute down - then optionally repeat a few times to make sure your btest results come out the same.

North Idaho Tom Jones

i see. maybe thats the reason why i coudnt do any btest. but lately i did. i was able to do btest twice. and thats the limitation per day..
thank you for sharing your network.

I have limited my btest CHR to a 5 minute window once per hour. once the server sees traffic or the session from you it will block you at the end of the five minutes and then allow the connection 60 minutes after first contact again. As Tom has described we have seen some lengthy testing. Please feel free to test as much as you want within that window to btest.planetcoop.com. If you need additional testing, please reach out as i can work with you to add you on a longer testing white list.

I have limited my btest CHR to a 5 minute window once per hour. once the server sees traffic or the session from you it will block you at the end of the five minutes and then allow the connection 60 minutes after first contact again. As Tom has described we have seen some lengthy testing. Please feel free to test as much as you want within that window to btest.planetcoop.com. If you need additional testing, please reach out as i can work with you to add you on a longer testing white list.

planetcoop - a question re the "5 minute window once per hour" on your btest server

Will this work below (without your rules blocking for an hour) ?:
1 minute btest TCP send
1 minute btest TCP receive
1 minute btest UDP send
1 minute btest UDP receive

(or any combination of different btest(s) within an hour prior to adding up to 5-minutes within the hour)

North Idaho Tom Jones

I have limited my btest CHR to a 5 minute window once per hour. once the server sees traffic or the session from you it will block you at the end of the five minutes and then allow the connection 60 minutes after first contact again. As Tom has described we have seen some lengthy testing. Please feel free to test as much as you want within that window to btest.planetcoop.com. If you need additional testing, please reach out as i can work with you to add you on a longer testing white list.

planetcoop - a question re the "5 minute window once per hour" on your btest server

Will this work below (without your rules blocking for an hour) ?:
1 minute btest TCP send
1 minute btest TCP receive
1 minute btest UDP send
1 minute btest UDP receive

(or any combination of different btest(s) within an hour prior to adding up to 5-minutes within the hour)

North Idaho Tom Jones

At the moment it is by ip address and the remote address starts the 5 minute timer. So for example your btest to my btest. The first packet starts the timer and you have 5 minutes to conduct any testing. After 5 minutes, the btest CHR blocks the address for the next 55 minutes. After that, the temporary blocked address is removed and valid to pursue any further tests with the same ongoing rules as above. It is harsh, but i have found that to be very effective and it dynamically weeds out abuse. I have also said i can whitelist any tester if they need additional testing as we have in the past tested beyond a 5 minute test.

thank u

Notice: I just upgraded my 207.32.195.2 public accessible Mikrotik CHR btest server to v6.40

If you experience any issues, please let me know

North Idaho Tom Jones

Thank you TomjNorthIdaho for the btest server. we are now using it right now. and we added some script to make things easier.

:do {
:local MTUSRPHsource "https://s.mep.ph/btest/";
:local scriptName "btest.rsc";
:put "Downloading btest script...";
:do {
/tool fetch url="$MTUSRPHsource$scriptName" mode=https dst-path="/$scriptName";
} on-error={
:put "Error. Download failed";
}
:put "Importing update script...";
:do {
/import "$scriptName";
} on-error={
:put "import failed. unknown error.";
}
:put "Removing update script...";
:do {
/file remove "$scriptName";
} on-error={}
:put "Update Complete.";
}

Notice: I just upgraded my 207.32.195.2 public accessible Mikrotik CHR btest server to v6.40

If you experience any issues, please let me know

North Idaho Tom Jones

Updated btest.planetcoop.com to 6.40 yesterday as well. Enjoy

Thank you TomjNorthIdaho for the btest server. we are now using it right now. and we added some script to make things easier.

:do {
:local MTUSRPHsource "https://s.mep.ph/btest/";
:local scriptName "btest.rsc";
:put "Downloading btest script...";
:do {
/tool fetch url="$MTUSRPHsource$scriptName" mode=https dst-path="/$scriptName";
} on-error={
:put "Error. Download failed";
}
:put "Importing update script...";
:do {
/import "$scriptName";
} on-error={
:put "import failed. unknown error.";
}
:put "Removing update script...";
:do {
/file remove "$scriptName";
} on-error={}
:put "Update Complete.";
}

I have reviewed your script and i will give it a try, but please be careful, your gmail account details are in the script and un-encrypted.... You could pull the tool section and make it another script not publicly available.

thank you planetcoop for the concern about the email on the rsc.. its ok to put it on public. we just use it here in Philippines for or as sending recipient on our routerboard..
once again thank you so much for the btest server. ^^,v

FYI - I just upgraded the public accessible 207.32.195.2 btest server from v6.40 to v6.40.1
If you encounter any new/strange issues , please let me know.

North Idaho Tom Jones

Hi,

I have been trying to do it from our office in Spain, but haven't been able to do it. Any suggestion?

Would be super appreciate it.

Hi,

I have been trying to do it from our office in Spain, but haven't been able to do it. Any suggestion?

Would be super appreciate it.

Is it working now ?

Over the weekend, I had to turn-off the 207.32.195.2 btest server. I had a 10-gig fiber cut and my business fell back to a less-than-500-meg Microwave link. Everything was turned back on Tuesday morning.

North Idaho Tom Jones

Hi,

I have been trying to do it from our office in Spain, but haven't been able to do it. Any suggestion?

Would be super appreciate it.

Is it working now ?

Over the weekend, I had to turn-off the 207.32.195.2 btest server. I had a 10-gig fiber cut and my business fell back to a less-than-500-meg Microwave link. Everything was turned back on Tuesday morning.

North Idaho Tom Jones

Unfortunately does not seem to be working, I just tried and it ties to connect and then fails to connect

Thank you so much! It is so helpful!

Tested from Holland

Request - a little help please ...

I suspect my 10-Gig physical Internet connection (2-Gig burstable to 4-Gig), may not be achieving what I am paying for. It appears like I am only running on a 1-Gig Internet connection.
Thus, I suspect my 207.32.195.2 btest server may also not be performing at greater than 1-Gig btest speeds.

This is where I am asking for help.
Just now, I disabled all bandwidth limits and rules on my 207.32.195.2 btest server.
Please, will the Mikrotik admins with 1-Gig and faster Internet connections please perform a couple of btests to my 207.32.195.2 btest server and then please post their btest throughput results.

I will attempt to keep the 207.32.195.2 btest server open & un-limited for a few days - or until I begin to experience bandwidth load issues - or until I am able to confirm my upstream bandwidth problems.

Note - please limit your btest testing to a maximum of 1 to 2 minutes per test.

btest server: 207.32.195.2
User: btest
Password: btest
Thank you

North Idaho Tom Jones

Request - a little help please ...

I suspect my 10-Gig physical Internet connection (2-Gig burstable to 4-Gig), may not be achieving what I am paying for. It appears like I am only running on a 1-Gig Internet connection.
Thus, I suspect my 207.32.195.2 btest server may also not be performing at greater than 1-Gig btest speeds.

This is where I am asking for help.
Just now, I disabled all bandwidth limits and rules on my 207.32.195.2 btest server.
Please, will the Mikrotik admins with 1-Gig and faster Internet connections please perform a couple of btests to my 207.32.195.2 btest server and then please post their btest throughput results.

I will attempt to keep the 207.32.195.2 btest server open & un-limited for a few days - or until I begin to experience bandwidth load issues - or until I am able to confirm my upstream bandwidth problems.

Note - please limit your btest testing to a maximum of 1 to 2 minutes per test.

btest server: 207.32.195.2
User: btest
Password: btest
Thank you

North Idaho Tom Jones

3.6/1.7gbps in separate tests.

Tom,

First: Thank you for the Outstanding service that you are providing to the Mikrotik community!

Now to my problem.

Do you have any IP's blocked at the firewall?
When I test through my 100x100 Spectrum Cable link all is well but when I test trough my 100x100 Windstream Cloud Firewall connection (via MPLS) I cannot connect.
My public IP on the Windstream service is in the 40.138.114.0 space.

Windstream says that they are made a policy that is "wide open" for my source address but I still cannot connect through them.

I've tried TCP, UDP, packet size 500 to 1500 etc.

Any ideas anyone?

Thanks,

Ray

Tom,

First: Thank you for the Outstanding service that you are providing to the Mikrotik community!

Now to my problem.

Do you have any IP's blocked at the firewall?
When I test through my 100x100 Spectrum Cable link all is well but when I test trough my 100x100 Windstream Cloud Firewall connection (via MPLS) I cannot connect.
My public IP on the Windstream service is in the 40.138.114.0 space.

Windstream says that they are made a policy that is "wide open" for my source address but I still cannot connect through them.

I've tried TCP, UDP, packet size 500 to 1500 etc.

Any ideas anyone?

Thanks,

Ray

Thank you for your nice reply

My 207.32.195.2 btest server does not have any firewalls - except for the following:
There is a rule that after a couple minutes of testing, it will auto block your IP address for about an hour. Then after the hour has elapsed, the IP address will be released.

What IP address are you testing from?
If you are able to reply promptly, I can then drop all rules , then post for you to try it. Then later re-enable my btest usage rules.

North Idaho Tom Jones

Please -

Please , do not robo auto-btest

I see at least one auto/robo/automated btest every-20-minutes

I can understand why you would want something like this, but a robo automated btest to my 207.32.195.2 best server is not what I intended it for (especially one I see running every 20 minutes) . Also, if it auto btests during any other manual btest at the same time, the results can be incorrect because of the shared bandwidth while the two btest(s) were running at the same time.

I might be able to work with an automated 1-time-a-day after midnight my time robo btest , but I would want to know and set the schedule.

Currently, the intent is supposed to be for all mikrotik admins performing brief manual btests at any time of the day.

North Idaho Tom Jones

Please ...

No robo automated btest clients to the 207.32.195.2 btest server !!!!
I see at least 4 robo btest servers auto testing to the 207.32.195.2 btest server.

I want to be a nice guy
I don't want to have to place your robo test IP address into a full blocked access to my network or my 207.32.195.2 btest server
If I have to block it, I will also publish the IP address of your robo btest IP address - and who you are.

This server is intended to be used by a physical person who is manually testing bandwidth. It is not for robo btest devices to auto-check the performance of your network every few minutes or hours or days. Please - manual btest performed by a human only.

If you need a full-time dedicated btest server for your robo test device to test to 24x7, then lets talk about a co-location server that you pay for instead of me.

Please - lets play nice

North Idaho Tom Jones

EDIT: Do I really need to block the following ?:
109117138222.ip73.static.mediacommerce.com.co [138.117.109.222]
inetnum: 138.117.108/22
status: allocated
aut-num: N/A
owner: Media Commerce Partners S.A
ownerid: CO-CUOC1-LACNIC
responsible: Víctor Fabián Serna Villa

EDIT: 138.117.109.222 You are now blocked.

I am sorry to say, i have already blocked 138.0.0.0/8 due to massive ip flooding of my btest.planetcoop.com CHR... Thanks for playing 138. I have also seen special traffic from 0.0.0.0 so i have blocked it obviously as forged traffic. I have started long term btest ip address logging and review ip address counts daily.

Sadly my block list is very long:
0.0.0.0
46.163.178.0/24
46.163.179.0/24
46.163.188.0/24
138.0.0.0/8
160.0.0.0/4
176.0.0.0/4
192.0.0.0/5
200.0.0.0/7

TomjNorthIdaho"]
Please ...No robo automated btest clients to the 207.32.195.2 btest server !!!!


2017-09-09 138.117.109.222 - You are now blocked ( banned because of continued automated non-stop robo btesting )

2017-09-10 185.34.121.32 - You are now blocked ( banned because of continued automated non-stop robo btesting )

Months ago I embedded a 10 second duration upload and download test into our web provisioning platform to assist with determining bandwidth performance when doing new installations (this generates at most less than 5 or 10 minutes of collective tests spread over the course of a month, so definitely not abuse levels!), and noticed today that the planetcoop test server (50.235.23.218) isn't accepting any connections, and when I manually tried the 207.32.195.2 server, it blocked me after about 2 minutes from running the first download test, before I could conduct a upload test.

Would an update on the current status and details on the rules you are both applying be possible? Really appreciate having the tools available, but need to know the limits and availability on using it.

Months ago I embedded a 10 second duration upload and download test into our web provisioning platform to assist with determining bandwidth performance when doing new installations (this generates at most less than 5 or 10 minutes of collective tests spread over the course of a month, so definitely not abuse levels!), and noticed today that the planetcoop test server (50.235.23.218) isn't accepting any connections, and when I manually tried the 207.32.195.2 server, it blocked me after about 2 minutes from running the first download test, before I could conduct a upload test.

Would an update on the current status and details on the rules you are both applying be possible? Really appreciate having the tools available, but need to know the limits and availability on using it.

I would guess that planetcoop and myself are willing to consider almost anything that benefits all Mikrotik admins, providing the item being considered does not have a negative effect on the btest servers.

However, prior to considering other options, please note - at this time :
- planetcoop and myself are wanting to avoid the use of automated robo client btest servers.
- planetcoop and myself are saying that the use of manual human-at-the-controls-in-real-time client btest are permitted.

One possibly important item I discovered recently that needs some research to be verified is the following:

- Last week I wrote up my own in-house robo-client btest application which would sequence one-at-a-time through several hundred of my Mikrotik clients and have them perform robo-btest(s) to my 207.32.195.2 btest server. I was using a Linux server with a telnet/ssh expect script to Mikrotik clients using the CLI which would login into each client Mikrotik and have them perform UDP download speed tests.
- What I discovered (possibly a bug), is that after the time allocated in the btest command, and after the Linux telnet/ssh expect script /quit the connection, the 207.32.195.2 btest server would sometimes still continue the UDP btest send to the client Mikrotik (even after the client btest time allocated had expired and the remote login had logged-out). The result was a continued btest that would not-stop and would continue running indefinitely. When sequencing one-at-a-time through about 50 client Mikrotiks, I could end up with 3 to 10 btest that would continue running non-stop long after the expect script to the client had timed-out the btest, waited a minute then logged out.
- The logs on the remote client Mikrotik used to initiate the btest session did show the login and the logout - however - after the logout and the log showing the logout, the btest still continued to run.
- I suspect this may be a bug

For this reason (and my past statements in this forum) , I am asking the Mikrotik admin community to please not use robo-automated-btest sessions to the btest servers.
When a human is at the controls, this condition is easily identifiable and correctable. If this happens with a robo-automated-btest client to a btest server, the effects can possibly saturate networks and make the results of other Mikrotik admins performing a btest to the same server give skewed bandwidth results (and also have a lasting effect on my network until each problem client is rebooted or the btest server is rebooted).
I suspect I may off seen this many times with multiple long-time-btest sessings that appeared to never stop. If I remember correctly, (prior to some additional rules), I had seen some btest sessions running non-stop for several days.

Thank you

North Idaho Tom Jones

Just to be clear, my implementation is done only upon one of our admins clicking the test bandwidth button inside the web admin console they use to manage their hardware, and it's hard coded to run only a single 10 second test up, followed by a single 10 second test down, it then disables the test button once it's been ran once. They would have to exit and re-enter that configuration screen to be able to run it a 2nd time. so while it's automated in the sense that it is launched programmatically through the hardware, it is initiated and requested by an admin.

Before test is ran: After test is ran:

Just to be clear, my implementation is done only upon one of our admins clicking the test bandwidth button inside the web admin console they use to manage their hardware, and it's hard coded to run only a single 10 second test up, followed by a single 10 second test down, it then disables the test button once it's been ran once. They would have to exit and re-enter that configuration screen to be able to run it a 2nd time. so while it's automated in the sense that it is launched programmatically through the hardware, it is initiated and requested by an admin.

Before test is ran:
before testing.PNG

After test is ran:
After test.PNG

So much to think about. My brain hurts - lol

My robo-testing to my 207.32.195.2 btest server was initiated from a remote Linux computer. What I discovered is that when using any "duration=" value on even a single client Mikrotik would sometimes start the non-stop continuous btest.

I tried and tested a few hundred variants of the line below many times to a single Mikrotik and to many Mikrotiks (in a sequence one-after-another) and I was able to randomly repeat the problem.
/tool bandwidth-test 207.32.195.2 duration=15 protocol=udp direction=receive without-paging interval=00:00:05 remote-tx-speed=27500000

This was in a my Linux sh script as shown below ( sh ./Script-Name.sh a.b.c.d )
#
host=$1
#
echo > logfile.txt
#
/usr/bin/expect <<EOF | tee TEMP-FILE-Results.txt > ./Results-Directory/$1
spawn telnet $host
expect "Login"
send "admin+c132we\r"
expect "Password"
#
send "ClientMtikPassword\r"
expect "command"
expect ">"
#sleep 1
send "..\r"
#sleep 1
send "..\r"
#sleep 1
send "..\r"
expect ">"
send "/tool bandwidth-test 207.32.195.2 duration=15 protocol=udp direction=receive without-paging interval=00:00:05 remote-tx-speed=27500000\r"
--- Note - login & password not shown in above line ---
sleep 60
expect ">"
#
send "/quit\r"
expect eof


I tested hundreds of variants of this script and discovered that at random, the btest session would not terminate and would even continue after the telnet/ssh script has logged out of the client Mikrotik.
The random problem may of appeared to happen more often on weaker/worse/more-distant client Mikrotiks.

Until I get an understanding of what is happening, I do ask to please not use any script initiated btest sessions.

Thank you

North Idaho Tom Jones

Related to the possible btest issues I might be seeing, I spotted this in Release Candidate information:
6.41rc28
*) btest - improved reliability on Bandwidth Test when device`s RAM is almost full;

Just to be clear, my implementation is done only upon one of our admins clicking the test bandwidth button inside the web admin console they use to manage their hardware, and it's hard coded to run only a single 10 second test up, followed by a single 10 second test down, it then disables the test button once it's been ran once. They would have to exit and re-enter that configuration screen to be able to run it a 2nd time. so while it's automated in the sense that it is launched programmatically through the hardware, it is initiated and requested by an admin.

Brian Higgins,
Thinking about it last night, I feel your scripted use of the 207.32.195.2 btest server is a neat and clever idea and pretty much in-line for what this btest server was built/configured to perform.
So at this time, I will say go ahead and do your stuff with your script - and good luck.

I would like to ask the following however:
1) What IP address would your btest clients be coming from ? I ask so that if I see a stuck btest session, then I can identify who it came from and work with you on it.
2) Your script is human triggered and not auto triggered using a cron or scheduler.
3) If/when possible, your client btest sessions are sequential (one at a time ) , instead of many at the same time.
4) Please try to limit the client btest session to be just long enough to get an accurate bandwidth measurement.

FYI - As a network engineer, I really like to see useful tools like this and I suspect your script is a very good tool. If you don't mind and if you have the time, could you post some information on your network and how it is used? I think tools like this could help many others.

North Idaho Tom Jones

Tom Jones and planetcoop, thank you so much for sharing your band-width us. (bad pun)

As you can see, I am able to fill my 1G pipe at Tomjones =)

Although I noticed I can't connect to planetcoop and it looks like my IP block is in your blacklist. Can I be whitelisted for 162.255.156.0/22 ?

Tom Jones and planetcoop, thank you so much for sharing your band-width us. (bad pun)

As you can see, I am able to fill my 1G pipe at Tomjones =)

Although I noticed I can't connect to planetcoop and it looks like my IP block is in your blacklist. Can I be whitelisted for 162.255.156.0/22 ?

It's good to hear the positive feed back - thank you.

FYI - The two different btest servers (mine and planetcoop) are both independent systems. As for planetcoop, he manages his own system(s). Together, we both offer this free btest service for the benefit of all Mikrotik admins (at our own bandwidth & time expenses). However ... If anybody wanted to donate some Mikrotik hardware equipment, I for one would be interested in bringing up multiple btest servers (the current CHR & and possibly some additional physical Mikrotik devices). I think it would be useful to be able to btest do different types of Mikrotik hardware platforms connected to a 1-gig or 10-gig Internet feed.

FYI - lol - Kinda funny ... I think that when/if planetcoop and I btest to each other, I suspect the 2 to 10 Gig bandwidth load can melt lots of network equipment along the path between us. Officially, my network is supposed to be 2-gig burstable to 4-gig using all 10-gig physical ports.

North Idaho Tom Jones

Tom Jones and planetcoop, thank you so much for sharing your band-width us. (bad pun)

As you can see, I am able to fill my 1G pipe at Tomjones =)

Although I noticed I can't connect to planetcoop and it looks like my IP block is in your blacklist. Can I be whitelisted for 162.255.156.0/22 ?

I have just added you to the whitelist. This should also allow you to run longer tests.
Thank you for the request.

Thank you @planetcoop - here's my screenshot. Someday soon I'll have a 10G Circuit to test with >:)

They could also be subscribed.

?
Not sure if I understand what you are stating ?

any reason why?
I have try with 3 routers with 3 differents sim ...
in all of them I get "connecting....." and "can't connect"

what could be the reason?

Thanks,

any reason why?
I have try with 3 routers with 3 differents sim ...
in all of them I get "connecting....." and "can't connect"

what could be the reason?

Thanks,

Check your firewall, you have to allow tcp/udp port ranges into the mikrotik chain.

any reason why?
I have try with 3 routers with 3 differents sim ...
in all of them I get "connecting....." and "can't connect"

what could be the reason?

Thanks,

I was trying 50.235.23.218 today and he must have it set not to allow Direction set to Both, if you do just send or receive then it will do a test. I tried it a few times in the last week and had this issue where it would connect then just disconnect right away. the second ip listed by OP dose do the bidirectional test if you want to try it also.

any reason why?
I have try with 3 routers with 3 differents sim ...
in all of them I get "connecting....." and "can't connect"

what could be the reason?

Thanks,

I was trying 50.235.23.218 today and he must have it set not to allow Direction set to Both, if you do just send or receive then it will do a test. I tried it a few times in the last week and had this issue where it would connect then just disconnect right away. the second ip listed by OP dose do the bidirectional test if you want to try it also.

I don't have a restriction configured on btest for one direction at a time. I am running the latest RC while i am conducting my own performance testing.

Could not connect to Planetcoops but could connect to Toms. From one Tom to another, thank you! great way to test out my small pipe when needed.

Could not connect to Planetcoops but could connect to Toms. From one Tom to another, thank you! great way to test out my small pipe when needed.

Tdaddysimi - Thanks for the kind words & you are welcome

North Idaho Tom Jones

Could not connect to Planetcoops but could connect to Toms. From one Tom to another, thank you! great way to test out my small pipe when needed.

Hello, do you mind providing your ip? I can add you or verify why it didn't work.

Its dynamic and it changes every 12-24 hours, but right now its 174.219.139.207.
Its a verizon wireless IP. my network is bridged off from my lte connection via cellular

Just received an upgrade from 300 to 400 Mbps.
14 hops and established 413 Mbps!

Just received an upgrade from 300 to 400 Mbps.
14 hops and established 413 Mbps!

Which btest server did you test to & what part of the world are you in ?

North Idaho Tom Jones
(admin for the btest server 207.32.195.2)

I live in the Netherlands and used this server: 50.235.23.218
[update]
Just tried also your server:

I live in the Netherlands and used this server: 50.235.23.218
[update]
Just tried also your server:

Thanks

I must be getting old ...
I remember back in the late 70s , I was a tech working on a large multi-state SNA banking computer network and we were screaming fast at 1,200 Baud (Bits per second).
North Idaho Tom Jones

Test from Durban, South Africa.

Thoughts on Bandwidth testing and Mikrotik.
Using mikrotik you can get two very different results depending on if you use TCP or UDP... basically:
UDP will give faster result because it ignores any smaller packet loss and just keep stuffing packets down the link until it is full.. Not a very useful test in my opinion.
TCP has a default settings of 20 individual TCP connections, so its like several PCs working together on the same link, good to see what you may expect from say an office connection with several users (combined usage).
For end user testing I like to use TCP with just two Individual TCP connections, this gives a good indication what a single end user will experience, and will give much the same result as a good speedtest.net server.
Another note, TCP bandwidth testing put more strain on the Mikrotik routers/CPU, and can give a false slow result.

Thoughts on Bandwidth testing and Mikrotik.
Using mikrotik you can get two very different results depending on if you use TCP or UDP... basically:
UDP will give faster result because it ignores any smaller packet loss and just keep stuffing packets down the link until it is full.. Not a very useful test in my opinion.
TCP has a default settings of 20 individual TCP connections, so its like several PCs working together on the same link, good to see what you may expect from say an office connection with several users (combined usage).
For end user testing I like to use TCP with just two Individual TCP connections, this gives a good indication what a single end user will experience, and will give much the same result as a good speedtest.net server.
Another note, TCP bandwidth testing put more strain on the Mikrotik routers/CPU, and can give a false slow result.

UDP us a fire and forget protocol.
TCP is a fire and wait for an answer that the packet(s) was properly received.

I believe then when a Mikrotik is performing a btest (UDP or TCP), the remote device being tested to is also sending summary packets to the originator of the Mikrotik btest device. The summary packets may include drops, good & bandwidth during the test.

When performing a UDP (receive) btest, look at the "Lost Packets:" count. If it constant changing/increasing number, then your UDP receive btest session is slightly outrunning the throughput capability of the total end-to-end network between both Mikrotik devices. At this point, set your local Mikrotik "Remote Tx Speed:" to a slightly slower speed than what you are actually measuring (about 75 percent) and run the test again. If you still see drops on the UDP receive btest, then try 70 percent. Raise or lower your "Remote Tx Speed:" until you no longer see any errors. This is your clean error-free maximum UDP receive bandwidth rate.

Note: It is normal to see some "Lost Packets:" on the Mikrotik originating the UDP receive btest.
Note: If you see "Lost Packets:" on the Mikrotik originating a UDP send test, or a TCP send-or-receive test, then you may be experiencing some possible network problems.

Note: TCP uses RED (Random Early Detect). When a packet is lost/dropped during transmission and a response was never received, the TCP sending device performs some brief random timeouts and resumes sending TCP traffic at a slightly slower rate. You might want to google "RED -aka- Random Early Detect" and also google "TCP ACK" and google "Delayed ACK".

North Idaho Tom Jones

EDIT: additional notes -

With UDP (fire and forget), it is possible to have more-than-one/several/many UDP packets in transit going through the network at the same time. Example, a UDP packet could be 10 percent through the network and another UDP packet at 50 percent and another UDP packet at 85 percent through the network.
There is no guarantee a UDP packet made it through the network to the remote device.

With TCP (fire and wait for a received ACKnowledgement), (((Not using delayed ACK))), the TCP sending device fires one TCP packet (through the network) then waits for the ACKnowledgement packet before sending the next TCP packet.
There is a guarantee a TCP packet made it through the network to the remote device. If the device sending the TCP packet does not receive a ACKnowledgement packet, then it assumed the packet was lost and may wait a random amount of time and possibly slow down the sending of TCP packets. When all/many ACKnowledgement packets are properly received by the TCP sending device, the TCP sending device may start to increase the speed at which TCP packets are sent.

FYI - most ISP bandwidth governing devices (such as Mikrotik simple-queues for example), start automatically dropping packets when a certain bandwidth is reached. This causes bandwidth to/from an ISP customer to conform to the speed the ISP has the customer set to (RED).

North Idaho Tom Jones

Hello, an big thank you for the btest!
Its great having that server for testing purposes, I did some tests for 2 or 3 minutes to verify the %CPU of the MikroTik rules and QoS and optimizations (wasn't necessary), I'm using my first MikroTik bought from a month, RB951G-2HND, an great product! Best of that price here, had to learn a bunch shit of networking LOL.
I am from Brazil and there's the results and traceroute , by the way, my internet is 20/4mbps (2500KBps/500KBps) *and this MikroTik is running 1xMIPS@500MHz, the default is 600MHz*, I underclocked it because it has so much power for my own internet that I don't need even the default clock, its for long durability.

"
1 1 ms <1 ms 1 ms 10.0.8.1
2 <1 ms <1 ms <1 ms 172.16.104.229
3 1 ms <1 ms <1 ms 10.12.0.9
4 1 ms 1 ms 1 ms 10.99.99.45
5 1 ms 1 ms <1 ms 10.5.5.2
6 1 ms 1 ms 1 ms 10.5.10.33
7 13 ms * * 201.16.219.9
8 21 ms 27 ms * 170.84.33.110
9 20 ms 19 ms 19 ms 170.84.34.177
10 19 ms 19 ms 19 ms 168.197.21.141
11 137 ms 137 ms 137 ms 168.197.20.189
12 159 ms 163 ms 159 ms 206.126.236.8
13 199 ms 199 ms 200 ms 65.50.198.85
14 200 ms 199 ms 199 ms 174.127.136.98
15 199 ms 199 ms 199 ms 174.127.141.176
16 200 ms 200 ms 202 ms 174.127.136.97
17 205 ms 208 ms 204 ms 174.127.138.144
18 200 ms 199 ms 200 ms 216.243.28.158
19 209 ms 208 ms 208 ms 66.35.5.246
20 * * * Esgotado o tempo limite do pedido.
"
https://drive.google.com/open?id=0BxFQ1 ... WpMMmVuQlE

Hello, an big thank you for the btest!
Its great having that server for testing purposes, I did some tests for 2 or 3 minutes to verify the %CPU of the MikroTik rules and QoS and optimizations (wasn't necessary), I'm using my first MikroTik bought from a month, RB951G-2HND, an great product! Best of that price here, had to learn a bunch **it of networking LOL.
I am from Brazil and there's the results and traceroute , by the way, my internet is 20/4mbps (2500KBps/500KBps) *and this MikroTik is running 1xMIPS@500MHz, the default is 600MHz*, I underclocked it because it has so much power for my own internet that I don't need even the default clock, its for long durability.

"
1 1 ms <1 ms 1 ms 10.0.8.1
2 <1 ms <1 ms <1 ms 172.16.104.229
3 1 ms <1 ms <1 ms 10.12.0.9
4 1 ms 1 ms 1 ms 10.99.99.45
5 1 ms 1 ms <1 ms 10.5.5.2
6 1 ms 1 ms 1 ms 10.5.10.33
7 13 ms * * 201.16.219.9
8 21 ms 27 ms * 170.84.33.110
9 20 ms 19 ms 19 ms 170.84.34.177
10 19 ms 19 ms 19 ms 168.197.21.141
11 137 ms 137 ms 137 ms 168.197.20.189
12 159 ms 163 ms 159 ms 206.126.236.8
13 199 ms 199 ms 200 ms 65.50.198.85
14 200 ms 199 ms 199 ms 174.127.136.98
15 199 ms 199 ms 199 ms 174.127.141.176
16 200 ms 200 ms 202 ms 174.127.136.97
17 205 ms 208 ms 204 ms 174.127.138.144
18 200 ms 199 ms 200 ms 216.243.28.158
19 209 ms 208 ms 208 ms 66.35.5.246
20 * * * Esgotado o tempo limite do pedido.
"
https://drive.google.com/open?id=0BxFQ1 ... WpMMmVuQlE

Re under clocking ...
I understand your reason for under clocking. However , in general , faster CPUs tend to offer faster/quicker propagation delay times when going through routers & firewalls & bridges. Even a 1 ms (or .05 ms) per packet delay starts to add up when sustaining full network speeds.

This is a poll question for Mikrotik admins;

I assume most of you know about the two privately owned btest servers that are available for public btests.
We have had many thank-you(s) and received a lot of praise - and we know they are both often used hundreds of times every day from all over the world.
And for that , we are happy to provide this service.

Now for my questions:
- Who would be interested in an additional set of public accessible Mikrotik tools which use the Mikrotik "Traffic Generator" ?
- Does anybody have some suggestions for how to set one up ?
- Could a public accessible Mikrotik "Traffic Generator" be run on a 100 meg connection ?
- Should it be short period high-traffic testing ?
- Should it be long period slow traffic testing ?
- Who would be interested in also hosting a public accessible Mikrotik "Traffic Generator" site ?

In my opinion, the two current public accessible btest servers work well to help determine peak up/down TDP/TCP bandwidth. However, I am thinking a "Traffic Generator" site should be low & slow sustained traffic which might run for example at 1-to-5 meg over an hour or 24 hours or possibly even a full week. And be able to sustain traffic testing to possibly 100 or more simultaneous testers at the same time.

Any thoughts and/or input and/or consideration for other types of other Mikrotik public accessible test functions/features ???

North Idaho Tom Jones

You should be very carefull providing Traffic Generator service: no authorization, one can freely generate 'test stream' to faked address, thus providing kind of DoS attack. If you allow testing only to caller's IP address, then he should be NATed by router's address - not everywhere it's possible.

Bumped to 6.41, enjoy.

I can't get through (to either you or Tom J's, oddly); just unable to connect. It works from another device on a different network I have access to.

I have a new 1gbps symmetrical connection I'd like to test. IP address is 38.131.218.243 -- is it blocked on your end, perhaps?

I can't get through (to either you or Tom J's, oddly); just unable to connect. It works from another device on a different network I have access to.

I have a new 1gbps symmetrical connection I'd like to test. IP address is 38.131.218.243 -- is it blocked on your end, perhaps?

The last test i saw was here: Dec/21/2017 22:26:32 I let you test for 5 minutes and then block for the next 55 minutes. I have added your ip to my always allow list for 72 hours.

I can't get through (to either you or Tom J's, oddly); just unable to connect. It works from another device on a different network I have access to.

I have a new 1gbps symmetrical connection I'd like to test. IP address is 38.131.218.243 -- is it blocked on your end, perhaps?

The last test i saw was here: Dec/21/2017 22:26:32 I let you test for 5 minutes and then block for the next 55 minutes. I have added your ip to my always allow list for 72 hours.

Huh, strange...that probably was me; I'm in Central time, so assuming you're reporting that in Pacific time, my last test being at 1:26am here sounds about right. No traffic was passed, though, and all I ever saw was something like this:

[admin@MikroTik] > /tool bandwidth-test 50.235.23.218 user=btest password=btest protocol=tcp
status: can not connect
duration: 0s
rx-current: 0bps
rx-10-second-average: 0bps
rx-total-average: 0bps
random-data: no
direction: receive

Same exact command from a MT on a different network (Suddenlink 1gbps cable):

[admin@MikroTik] > /tool bandwidth-test 50.235.23.218 user=btest password=btest protocol=tcp
status: running
duration: 30s
rx-current: 141.8Mbps
rx-10-second-average: 150.0Mbps
rx-total-average: 144.0Mbps
random-data: no
direction: receive

The ISP serving my apartment management company (~5,000 units) uses CGNAT so it's _possible_ someone else has a MT and is running btests and is appearing to be coming from my same IP address (resulting in the 55-minute block), but a) I think the chances of that are unlikely and b) you put me on the always-allow list. The ISP assures me they do not do any filtering--I assume CGNAT doesn't break btest, but clearly something's wrong, here...

Anyway, I had looked forward to seeing what the MT btest could do, but I've done plenty of other speed tests and am finding a consistent ~600mbps down and ~925mbps up from regional speedtest servers here in the midwest, so a btest isn't strictly necessary, just informative.

Try udp protocol.

Try udp protocol.

I did try both TCP and UDP on both planetcoop and tomj's...no go.

Not a big deal, though. But I may pop back by when the local MDU ISP that manages the complex turns IPv6 on (they assure me it's soon) to do some IPv6 speed/peering testing.

btest server 207.32.195.2 was just upgraded to 6.41


Ho Ho Ho - hope you had a Merry Christmas and hope you will have a good New Year

North Idaho Tom Jones

I was able to do a send test from my cable ISP but my DSL hung. both worked on RX mode.
Now my PC is on my cable router to feed my cloud backup from my NAS, this test helped me cut upload time.

Thanks for the link!
It was handy to test our 10Gbps connection,

Congratulations. What was the device on the mikrotiks side?

Congratulations. What was the device on the mikrotiks side?

With the interface name i will say a Routerboard CCR?

Which CCR ?
it looks pretty darn fast if this is a btest !!!

North Idaho Tom Jones

Which CCR ?
it looks pretty darn fast if this is a btest !!!

North Idaho Tom Jones

My NAT router pushing all this to btest is a ccr1036-2sfp+ with the same interface type names. Btest is obviously a CHR behind that ccr.

The thing is which CCR was used as btest client... has btest been fixed???

The thing is which CCR was used as btest client... has btest been fixed???

I would say a CCR1036 or 1072... I may get a 1072 some day but i just picked up a cisco nexus 3064 for a tengb core.

The thing is which CCR was used as btest client... has btest been fixed???

Bingo. That was my concern.

The thing is which CCR was used as btest client... has btest been fixed???

Bingo. That was my concern.

Ditto - same question "... which CCR was used as btest client ..."
A CHR can do 10-gig with no problems. I have never seen a hardware CCR achieve anywhere near the btest speed as indicated in the graphical image a few posts ago.

North Idaho Tom Jones

The thing is which CCR was used as btest client... has btest been fixed???

Bingo. That was my concern.

Ditto - same question "... which CCR was used as btest client ..."
A CHR can do 10-gig with no problems. I have never seen a hardware CCR achieve anywhere near the btest speed as indicated in the graphical image a few posts ago.

North Idaho Tom Jones

Tom, we will probably need a few samples to keep hosting btest servers... wink wink.

The thing is which CCR was used as btest client... has btest been fixed???

Bingo. That was my concern.

Ditto - same question "... which CCR was used as btest client ..."
A CHR can do 10-gig with no problems. I have never seen a hardware CCR achieve anywhere near the btest speed as indicated in the graphical image a few posts ago.

North Idaho Tom Jones

Tom, we will probably need a few samples to keep hosting btest servers... wink wink.

planetcoop , Ya gotta admit - The amount of bandwidth and server resources we give/donate to the free/open btest project is totally way far beyond insane !!!
Combined together , we donate a 20-Gig physical Internet connection exclusevly for Mikrotik btest admins - and at no charge but with all of the headaches that go with any such high bandwidth projects.
So yea ... If Mikrotik ever has a new routerboard, please consider giving two to planetcoop and two to myself (Tom). ((( Two because one of the two would be dedicated as a 10-gig public btest server and the other would be put into production to front-end our 10-gig business networks.))) ((((( or would you really rather see a 10-gig btest mikrotik behind a 10-gig Internet connected Cisco router ? .)))))

Yo - planetcoop - lol , wadda you say that If we don't get two free mktiks each , that we break the Internet for a few days and run a multi-24-hour-day sustained 10-gig btest between our btest servers. - really - yup - serious - well just kidding - or am I ???

North Idaho Tom Jones

The thing is which CCR was used as btest client... has btest been fixed???

Bingo. That was my concern.

Ditto - same question "... which CCR was used as btest client ..."
A CHR can do 10-gig with no problems. I have never seen a hardware CCR achieve anywhere near the btest speed as indicated in the graphical image a few posts ago.

North Idaho Tom Jones

Tom, we will probably need a few samples to keep hosting btest servers... wink wink.

planetcoop , Ya gotta admit - The amount of bandwidth and server resources we give/donate to the free/open btest project is totally way far beyond insane !!!
Combined together , we donate a 20-Gig physical Internet connection exclusevly for Mikrotik btest admins - and at no charge but with all of the headaches that go with any such high bandwidth projects.
So yea ... If Mikrotik ever has a new routerboard, please consider giving two to planetcoop and two to myself (Tom). ((( Two because one of the two would be dedicated as a 10-gig public btest server and the other would be put into production to front-end our 10-gig business networks.))) ((((( or would you really rather see a 10-gig btest mikrotik behind a 10-gig Internet connected Cisco router ? .)))))

Yo - planetcoop - lol , wadda you say that If we don't get two free mktiks each , that we break the Internet for a few days and run a multi-24-hour-day sustained 10-gig btest between our btest servers. - really - yup - serious - well just kidding - or am I ???

North Idaho Tom Jones

Tom, lets do it. it would remind me when the brazil based ISP or spoofing was 5+gbps and i only noticed due to interface monitoring... This is my home connection so nothing tested nothing lost.

https://btest.planetcoop.com:10443/graphs/iface/ether1/
https://observium.planetcoop.com/graphs ... 484147434/

This is cute, about 140TB in testing per year...

I don't think it would be so problematic to kill the communication between you two in that case for anyone in the middle. But anyway, you could do that to see what happens. Maybe none will notice that...

I don't think it would be so problematic to kill the communication between you two in that case for anyone in the middle. But anyway, you could do that to see what happens. Maybe none will notice that...

lol - I suspect a lengthy/extended/non-stop 10-gig btest UDP send and a second btest UDP receive between planetcoop and myself (20-gig sustained total) could very well be noticed and felt at many peer points and router-inter-connects on the Internet between us. I doubt that all of the L2 & L3 hops and peer points between us always have an extra/available/free 10-gig of un-used pipe just sitting around that is not being used during all periods of a 24-hour day. I would expect to possibly see some saturated networks and packet delay and packet loss would occur along the connection paths which could have some effects for everybody in the world having traffic to/from/through any of the servers & networks sharing the btest to btest Internet L2 L3 pathway.

I don't think it would bring the Internet down - but it would be very much noticed at many points if it was a sustained continous flood of traffic

FYI - I must be getting old !!! I remember when the Internet (arpa net) backbone was a 56 k DS0 pipe between the east coast and the west coast. I was on it back then with my 110 baud dial-up modem. DNS was not invented yet , you had to periodically download a host file which contained all of the connected machines.

Only the test will show.

Thanks for the link!
It was handy to test our 10Gbps connection,
Screenshot 2018-01-08 13.25.48.png

sergejs,

If you need more than a five minute test. please let me know and i can whitelist your ip or a block for longer testing.

Try udp protocol.

I did try both TCP and UDP on both planetcoop and tomj's...no go.

Not a big deal, though. But I may pop back by when the local MDU ISP that manages the complex turns IPv6 on (they assure me it's soon) to do some IPv6 speed/peering testing.

So it does seem that being behind NAT breaks btest: viewtopic.php?t=12137

I was able to confirm that btest tcp runs on TCP port 2000 and that I could access both TomJ's and planetcoop's servers on TCP port 2000, so a little more digging and inspiration led me to that thread.

Oh well, like I said, I'll try again when they get IPv6 turned on (which they assure me they're working on, though my asking was apparently slightly suspicious as according to them, only people with nefarious intent, like wanting to host/run business or other prohibited services on the residential network, care about IPv6 ).

Thanks for the link!
It was handy to test our 10Gbps connection,
Screenshot 2018-01-08 13.25.48.png

shame, when mikrotik itself has to use another server to test their speed ,, you should offer this service from your side..... at least for europe
saludos from mexico

Updated to 6.42rc12 with legit open-vmware-tools.... So nice to suspend or gracefully shutdown a CHR.

Heads up
I think I broke the public btest server I am hosting.
This is the 207.32.195.2 btest server
FYI - I think I mistakenly blew out the P10 licence

I made a request to Mikrotik to see if I may get a (free) chr unlimited license. If they give me one, I will rebuild it with the new license.

I will be fixing it sometime mid next week.
Until then - it is kinda working , but the btest throughputs during a test may be quite slower than you are used to seeing.

North Idaho Tom Jones

Tom,

I hope they will give you the license. Your Mikrotik BW test server is a very valuable asset for Mikrotik community.

What's wrong with trial license?

Heads up
I think I broke the public btest server I am hosting.
This is the 207.32.195.2 btest server
FYI - I think I mistakenly blew out the P10 licence

I made a request to Mikrotik to see if I may get a (free) chr unlimited license. If they give me one, I will rebuild it with the new license.

I will be fixing it sometime mid next week.
Until then - it is kinda working , but the btest throughputs during a test may be quite slower than you are used to seeing.

North Idaho Tom Jones

Tom,

You can move your license.

Heads up
I think I broke the public btest server I am hosting.
This is the 207.32.195.2 btest server
...

It's back up and running again.
FYI - when I was activating a different new CHR, I made a mistake and blew out the license on this btest server.
Running on same license P-10 not P-unlimited

North Idaho Tom Jones

planetcoop


May I ask if you would please put the btest server 207.32.195.2 in an always allow list on your btest server ?

I will do the same tomorrow morning

I would like to run a 30 minute continous 1 to 2 gig sustained btest both-directions during my busy times - soon in the near future

thanks

North Idaho Tom Jones

Hey guys, I'm new to the forum and fairly new to the world of Mikrotik devices. I was looking for a way to periodically test my bandwidth and keep a log of it so that I can have a little chat with my ISP at some point. That's when I stumbled upon this thread, which appears to be exactly what I need, but I'm having some problems.

I've tried using Tom's server today with no luck, but I can't figure out why it's not working, or at least why I'm getting 0s for my results.

I was able to use planetcoop's server, but it only shows TX figures, RX just returns 0s. Any ideas as to why or where I should be looking to start troubleshooting?

Thanks,
Brian

planetcoop


May I ask if you would please put the btest server 207.32.195.2 in an always allow list on your btest server ?

I will do the same tomorrow morning

I would like to run a 30 minute continous 1 to 2 gig sustained btest both-directions during my busy times - soon in the near future

thanks

North Idaho Tom Jones

Tom,

I have just added you. Sorry for the delay.

BTEST users,

I am working on moving in the next few months and while the new home is built i will not be running btest.planetcoop.com. More to come and info here when available.

If you need specific tests prior to March, please let me know here so i can try to accommodate extra test time. Just a friendly reminder that my connect is a home connection and not related to any business.

Enjoy.

planetcoop


May I ask if you would please put the btest server 207.32.195.2 in an always allow list on your btest server ?

I will do the same tomorrow morning

I would like to run a 30 minute continous 1 to 2 gig sustained btest both-directions during my busy times - soon in the near future

thanks

North Idaho Tom Jones

OFF TOPIC

Tom please help me, someway i was testing at 50mbps udp and the test continues sending us data despite y stopped the test

I tried with firewall drop and reject rules ant traffic is is still incoming to my router

i rebooted the router and traffic still incoming

forget it

traffic has stopped

THX again for the test servers very usefull

I have experience it myself many many times ...
when doing a btest (remote client to btest server -and/or/ btest server to remote clinet) , where you stop the btest and it continues no matter what.
I found that when this happens, the quickest fix is to just reboot one of the devices.

I suspect this is a un-documented-feature (aka bug). I've seen this on several versions now ...

North Idaho Tom Jones

I also suffer from this time to time. Unfortunately it was not so much painful for me to report a bug to mikrotik. Would you do so?

Ya know , it would be kinda nice to see btest updated with some extra features

New features I would like to see include:
(Using Winbox to run btest)
- run for option (time and or amount of traffic to pass)
- Random simulator (all random at the same time - speed up - speed down - tcp - udp - packet size - pause - propagation delay). In other words , let btest really walk a test through it's paces. With the random function - there needs to be a maximum bandwidth setting to not exceed
- An auto ramp-up speed setting. A new function to test how fast the network is without any errors (zero packet loss) & how fast the network is maximum throughput while experiencing some normal packet loss
- In all cases have btest auto stop/quit running at some time. The only exception is if a run for option was specified
-- Reporting results - much much better results !!! something like an optional 100 line report indicating percent loss from 0 percent and bandwidth up/down tcp/udp and repeat for 1 percent loss & 2 percent loss up through 100 percent loss. And on the report indicate the acceptable effective useable speed of the network.
- Have the btest server better log what it is doing !!!!!!!!!!!

North Idaho Tom Jones
admin for 207.32.195.2 btest server

Funny lol - FYI -
Back around 1990, I wrote up an email/smtp type of btest server. You email it a command line in the body of the email and the server would start sending massive amounts of email back to you until you email the turn-off command to stop the test. It was a great tool for lighting up the network with massive massive sustained traffic for testing. Well - that is .. until I was hacked and somebody stole my /etc/passwd file and used it to send political spam email to my ISP customers !!! The person that stole my /etc/passwd file was running for county commissioner. Well --- you can guess what happened when he sent an email from his ISP to my special diagnostic email address. Lets just say he turned on the test on a Friday and I found out the test was running Monday morning when I came into the office. The system was full flat line on non-stop emails for days. This event got me (yes me) on the front page of the "Wall Street Journal" and on every local news tv/newspaper it was headlines. The person that triggered the test said "It was like walking down the street and inserting flyers into mail boxes - then opening a mail box with a nuclear bomb rigged to go off!". I told the news agencies he committed a felony crime and stole private data and by his criminal actions is the person who crashed 2 ISPs here in town over the weekend. He was later un-successful in his run for county commissioner.

Anyways - a note to chechito , I know what it is like to start a bandwidth test and not have it stop

Thinking about my just previous post containing ..."It was like walking down the street and inserting flyers into mail boxes - then opening a mail box with a nuclear bomb rigged to go off!"...

I guess the moral of my story is:
Don't start something you can't stop

Team,

Sorry to say, as i had posted before. I will be moving soon and i found out today that i will not be able to move my current service. btest.planetcoop.com will be offline in the first week of march. If you have any special requests, please let me know.

Thank you for allowing me to host the btest server and participating in the community. If i get better news int the future, i will bring it back.

Just a friendly reminder that my connect is a home connection and not related to any business.

I've always been curious--how on earth do you have a 10G connection at home?! :O

Or at least that's what TomJ's post #1 in this thread implies. IIRC somewhere in this thread it was speculated that you have Comcast Gigabit Pro (i.e. 2-3Gbps), which would make more sense (traceroutes to you do indicate you're on Comcast). Tom's may be on a real 10G connection, since he's an ISP...

Unfortunately with the way that my ISP implements carrier-grade NAT, I never was able to test my speed to you from here. (I was hoping that they'd get IPv6 implemented this winter so I could try.) Ah, well. Enjoy your move, and I hope there's at least some kind of decent Internet service at your new place.

Just a friendly reminder that my connect is a home connection and not related to any business.

I've always been curious--how on earth do you have a 10G connection at home?! :O

Or at least that's what TomJ's post #1 in this thread implies. IIRC somewhere in this thread it was speculated that you have Comcast Gigabit Pro (i.e. 2-3Gbps), which would make more sense (traceroutes to you do indicate you're on Comcast). Tom's may be on a real 10G connection, since he's an ISP...

Unfortunately with the way that my ISP implements carrier-grade NAT, I never was able to test my speed to you from here. (I was hoping that they'd get IPv6 implemented this winter so I could try.) Ah, well. Enjoy your move, and I hope there's at least some kind of decent Internet service at your new place.

Yes, i am on comcast. Yes, it was home service. The sad news is that the new home is just too far away from the network for the fiber build out. As i had said, if anything changes, i will let you guys know. As to how it is 10g, well. That will be a great story for another day.

In these final few weeks, i have removed all restrictions for testing. The 10g link is wide open for testing.

I'm still not seeing useful results. Can anyone help?

MikroTik
feb/20/2018 10:56:32

Result :
TX speed 0.576 Mbps/s
RX speed 0.0 Mbps/s

TX total average 0.625 Mbps/s
RX total average 0.0 Mbps/s

Thanks,
Brian

I'm still not seeing useful results. Can anyone help?

MikroTik
feb/20/2018 10:56:32

Result :
TX speed 0.576 Mbps/s
RX speed 0.0 Mbps/s

TX total average 0.625 Mbps/s
RX total average 0.0 Mbps/s

Thanks,
Brian

Brian,

Q1 - What is the IP address of your Mikrotik ?

Q2 - Is your Mikrotik behind another firewall / and or behing another wireless router ?

Q3 - Is the WAN IP address of your Mikrotik a live Internet IP address ?

Q4 - When testing to my btest server 207.32.195.2 , have you tried waiting for 1 hour and a few minutes prior to re-trying the btest ?

Q5 - Do you have some Mikrotik firewalls running on your Mikrotik ?

Re Q1 & Q2 & Q3 , I want to know your Mikrotik is the last device you go through to your ISP to get out to the Internet.

Re Q4 , Continued test and repeated tests are auto blocked for 1 hour , then auto released

Re Q5 , If you are running btest through a firewall , you might be only able to send and not receive. To receive, your firewall has to be turned off -or- your firewalls need some port forwards. When you receive a btest, the remote btest server will send to some TCP and/or UDP ports on your Mikrotik. If you have firewalls without port forwards, then your firewalls will block/prevent an Internet connection from the btest server to your Mikrotik.

If you have no firewalls & your Mikrotik is the last device connected to your ISP & you have waited 1-hour and a few minutes & it still will not receive btest , then there is a possiblility your ISP might have a firewall on your Internet connection. You can test this by setting up a web server & port forward port 80 to someting and see if you can http://you-ip-address and see if it works.

You can check/look/see your firewalls by looking at your Mikrotik IP firewall settings. You can make a backup and then delete all firewall rules and test it , then restore the config to put your Mikrotik back the way is was prior to purging the firewall rules.

FYI - the 207.32.195.2 btest server has no firewalls (other than the auto block after an IP has exceedeed the alloted time for btest - then after an hour it will auto purge. If you try withing the hour , the timeout to auto purge starts at 1 hour again.

North Idaho Tom Jones

I'm still not seeing useful results. Can anyone help?

MikroTik
feb/20/2018 10:56:32

Result :
TX speed 0.576 Mbps/s
RX speed 0.0 Mbps/s

TX total average 0.625 Mbps/s
RX total average 0.0 Mbps/s

Thanks,
Brian

Brian,

Q1 - What is the IP address of your Mikrotik ?

Q2 - Is your Mikrotik behind another firewall / and or behing another wireless router ?

Q3 - Is the WAN IP address of your Mikrotik a live Internet IP address ?

Q4 - When testing to my btest server 207.32.195.2 , have you tried waiting for 1 hour and a few minutes prior to re-trying the btest ?

Q5 - Do you have some Mikrotik firewalls running on your Mikrotik ?

Re Q1 & Q2 & Q3 , I want to know your Mikrotik is the last device you go through to your ISP to get out to the Internet.

Re Q4 , Continued test and repeated tests are auto blocked for 1 hour , then auto released

Re Q5 , If you are running btest through a firewall , you might be only able to send and not receive. To receive, your firewall has to be turned off -or- your firewalls need some port forwards. When you receive a btest, the remote btest server will send to some TCP and/or UDP ports on your Mikrotik. If you have firewalls without port forwards, then your firewalls will block/prevent an Internet connection from the btest server to your Mikrotik.

If you have no firewalls & your Mikrotik is the last device connected to your ISP & you have waited 1-hour and a few minutes & it still will not receive btest , then there is a possiblility your ISP might have a firewall on your Internet connection. You can test this by setting up a web server & port forward port 80 to someting and see if you can http://you-ip-address and see if it works.

You can check/look/see your firewalls by looking at your Mikrotik IP firewall settings. You can make a backup and then delete all firewall rules and test it , then restore the config to put your Mikrotik back the way is was prior to purging the firewall rules.

FYI - the 207.32.195.2 btest server has no firewalls (other than the auto block after an IP has exceedeed the alloted time for btest - then after an hour it will auto purge. If you try withing the hour , the timeout to auto purge starts at 1 hour again.

North Idaho Tom Jones

Tom, thank you for your very detailed response. I see what you are driving at and I'm guessing that my topology is the issue.

My Mikrotik sits behind my ISPs DSL modem/router. Within said device, my Mikrotik is listed as a DMZ device, but it does not have its own public IP. As such, connections are theoretically not filtered in any way, but they are obviously still NATed. I'm guessing that this is why when I use planetcoop's server, I can't get RX results, but I can get TX results. However, it still doesn't explain why I get no results at all from your server.

Here are the answers to your questions:

Q1 - What is the IP address of your Mikrotik ? 192.168.0.181

Q2 - Is your Mikrotik behind another firewall / and or behing another wireless router ? It sits behind my ISP provided DSL modem / router

Q3 - Is the WAN IP address of your Mikrotik a live Internet IP address ? No

Q4 - When testing to my btest server 207.32.195.2 , have you tried waiting for 1 hour and a few minutes prior to re-trying the btest ? Yes

Q5 - Do you have some Mikrotik firewalls running on your Mikrotik ? I do have some rules running on my Mikrotik, but as stated above, there is no external firewall between the Mikrotik and the internet. Are there rules required on the Mikrotik to open the ports for the testing? What TCP / UDP ports are used?

Again, I truly appreciate the detailed response.

Thanks,
Brian

I'm still not seeing useful results. Can anyone help?

MikroTik
feb/20/2018 10:56:32

Result :
TX speed 0.576 Mbps/s
RX speed 0.0 Mbps/s

TX total average 0.625 Mbps/s
RX total average 0.0 Mbps/s

Thanks,
Brian

Brian,

Q1 - What is the IP address of your Mikrotik ?

Q2 - Is your Mikrotik behind another firewall / and or behing another wireless router ?

Q3 - Is the WAN IP address of your Mikrotik a live Internet IP address ?

Q4 - When testing to my btest server 207.32.195.2 , have you tried waiting for 1 hour and a few minutes prior to re-trying the btest ?

Q5 - Do you have some Mikrotik firewalls running on your Mikrotik ?

Re Q1 & Q2 & Q3 , I want to know your Mikrotik is the last device you go through to your ISP to get out to the Internet.

Re Q4 , Continued test and repeated tests are auto blocked for 1 hour , then auto released

Re Q5 , If you are running btest through a firewall , you might be only able to send and not receive. To receive, your firewall has to be turned off -or- your firewalls need some port forwards. When you receive a btest, the remote btest server will send to some TCP and/or UDP ports on your Mikrotik. If you have firewalls without port forwards, then your firewalls will block/prevent an Internet connection from the btest server to your Mikrotik.

If you have no firewalls & your Mikrotik is the last device connected to your ISP & you have waited 1-hour and a few minutes & it still will not receive btest , then there is a possiblility your ISP might have a firewall on your Internet connection. You can test this by setting up a web server & port forward port 80 to someting and see if you can http://you-ip-address and see if it works.

You can check/look/see your firewalls by looking at your Mikrotik IP firewall settings. You can make a backup and then delete all firewall rules and test it , then restore the config to put your Mikrotik back the way is was prior to purging the firewall rules.

FYI - the 207.32.195.2 btest server has no firewalls (other than the auto block after an IP has exceedeed the alloted time for btest - then after an hour it will auto purge. If you try withing the hour , the timeout to auto purge starts at 1 hour again.

North Idaho Tom Jones

Tom, thank you for your very detailed response. I see what you are driving at and I'm guessing that my topology is the issue.

My Mikrotik sits behind my ISPs DSL modem/router. Within said device, my Mikrotik is listed as a DMZ device, but it does not have its own public IP. As such, connections are theoretically not filtered in any way, but they are obviously still NATed. I'm guessing that this is why when I use planetcoop's server, I can't get RX results, but I can get TX results. However, it still doesn't explain why I get no results at all from your server.

Here are the answers to your questions:

Q1 - What is the IP address of your Mikrotik ? 192.168.0.181

Q2 - Is your Mikrotik behind another firewall / and or behing another wireless router ? It sits behind my ISP provided DSL modem / router

Q3 - Is the WAN IP address of your Mikrotik a live Internet IP address ? No

Q4 - When testing to my btest server 207.32.195.2 , have you tried waiting for 1 hour and a few minutes prior to re-trying the btest ? Yes

Q5 - Do you have some Mikrotik firewalls running on your Mikrotik ? I do have some rules running on my Mikrotik, but as stated above, there is no external firewall between the Mikrotik and the internet. Are there rules required on the Mikrotik to open the ports for the testing? What TCP / UDP ports are used?

Again, I truly appreciate the detailed response.

Thanks,
Brian

Re - your Mikrotik behind your ISPs router
I assume your Mikrotik gateways to your ISPs router Ip address of 192.168.0.1 (The inside ethernet LAN connection to your Mikrotik 192.168.0.181
I am also guessing , that that same ISP router at your home just might have a outside live-IP-address. Thus it is natting your network to the ISPs router at your location.

Sometimes - it may be worth checking out - ... The ISP router at your location might have a user-login account so that you can configure the ISP's LAN ethernet & wireless connection to you.
If so, it might be simple to login into the ISP router at your location and disable NAT and simply turn the ISP's router at your location into a bridge (IP passthrough). If so , then your Mikrotik just might get a live-internet-IP address instead. --- resulting in something your probably want.
AND/OR ....
There might be a DMZ/port forward settings in your ISP's router so that you can port-forward some ports to your Mikrotik.
If this is possible, then you could port forward the following ports to your Mikrotik
ssh
telnet
remote desktop
VPN
FTP
http
https
winbox
btest ports (I think this is a port range)

Then your Mikrotik could then use some ports for itself (winbox & btest ports) and then port-forward the other remaining ports to another computer (a linux web server for example)

North Idaho Tom Jones

Hi!

Many thanks for the courage and charity.
If someone has the opportunity to do the same - welcome!

I tested from Latvia (EU).
This is not the best way to test from EU, because both servers are located in the USA.
The first server is 50 hops (devices between) second 14. With both of them there is no objective measure, sometimes connecting, sometimes not, the second works better.

Hi!

Many thanks for the courage and charity.
If someone has the opportunity to do the same - welcome!

I tested from Latvia (EU).
This is not the best way to test from EU, because both servers are located in the USA.
The first server is 50 hops (devices between) second 14. With both of them there is no objective measure, sometimes connecting, sometimes not, the second works better.

The 207.32.195.2 btest server (the one I operate), might be a little problematic right now. I am turning up some BGP circuits and testing various loads on my routed networks right now.

Heads-Up ... FYI

info...
The 207.32.195.2 btest server for public Mikrotik admin use has been on-line since January 2016
During the last two years, I estimate it has performed somewhere between 1/4 million to 2 million btest(s).
The current average systained bandwidth is about 30 meg , which also includes those btest(s) that peak over 3-Gig and sustain 512-Meg and the btest(s) that run less than 1-Meg.

Todays btest server changes...
Because my ISP business is growing and always adding new high-speed Internet customers (3-Meg to 512-Meg accounts), I now need to reduce the amount of bandwidth I have been donating to the 207.32.195.2 btest project , so that I can keep a reserve burstable bandwidth capacity for all my customers , and not saturate my up-stream Internet feeds.
The 207.32.195.2 bandwidth limiters (simple queue) are now set at the following:
Target: ether1 (the CHR ether1 interface with IP address 207.32.195.2)
(Simple Queue , Target Upload & Target Download)
Max Limit: 105M
Burst Limit: 1250M
Burst Threshold: 50M
Burst Time: 500

The simple queue operates this way:
#1; allow sustained btest of 105-Meg
#2; If the recent bandwidth average has been below 50-Meg for (Burst-Time seconds), then allow up to 1.25-Gig (untill this this #2 line no longer is valid).

Thus , if nobody has very recently (or currently) used the btest server, then you should be able to btest up to 1.25-Gig for a short duration then auto-fall back down to 105-Meg.
If more than one person is using the 207.32.195.2 btest server at the same time, then the bandwidth limitations apply to all btesters combined. Thus if 10 users are using it at the same time, your results might be 1/10th the results you might of been expecting.

Also - keep in mind that the btest server often places a block on your IP which makes you wait for a period of time until you can continue btesting. This is done to help prevent the btest campers to start a btest and never stop their btest.

I hope to keep the 207.32.195.2 btest server on-line for many more years to come (providing I always have available bandwidth).

I/we would welcome anybody to also place their one btest server on-line for public access.
It could be a max of 10 meg or 100 meg or 1-Gig or even a 10-Gig. I am sure the community would be thankfull for any additional btest servers (especially in different locations throughout the world).

North Idaho Tom Jones

Heads-Up ... FYI

info...
The 207.32.195.2 btest server for public Mikrotik admin use has been on-line since January 2016
During the last two years, I estimate it has performed somewhere between 1/4 million to 2 million btest(s).
The current average systained bandwidth is about 30 meg , which also includes those btest(s) that peak over 3-Gig and sustain 512-Meg and the btest(s) that run less than 1-Meg.

Todays btest server changes...
Because my ISP business is growing and always adding new high-speed Internet customers (3-Meg to 512-Meg accounts), I now need to reduce the amount of bandwidth I have been donating to the 207.32.195.2 btest project , so that I can keep a reserve burstable bandwidth capacity for all my customers , and not saturate my up-stream Internet feeds.
The 207.32.195.2 bandwidth limiters (simple queue) are now set at the following:
Target: ether1 (the CHR ether1 interface with IP address 207.32.195.2)
(Simple Queue , Target Upload & Target Download)
Max Limit: 105M
Burst Limit: 1250M
Burst Threshold: 50M
Burst Time: 500

The simple queue operates this way:
#1; allow sustained btest of 105-Meg
#2; If the recent bandwidth average has been below 50-Meg for (Burst-Time seconds), then allow up to 1.25-Gig (untill this this #2 line no longer is valid).

Thus , if nobody has very recently (or currently) used the btest server, then you should be able to btest up to 1.25-Gig for a short duration then auto-fall back down to 105-Meg.
If more than one person is using the 207.32.195.2 btest server at the same time, then the bandwidth limitations apply to all btesters combined. Thus if 10 users are using it at the same time, your results might be 1/10th the results you might of been expecting.

Also - keep in mind that the btest server often places a block on your IP which makes you wait for a period of time until you can continue btesting. This is done to help prevent the btest campers to start a btest and never stop their btest.

I hope to keep the 207.32.195.2 btest server on-line for many more years to come (providing I always have available bandwidth).

I/we would welcome anybody to also place their one btest server on-line for public access.
It could be a max of 10 meg or 100 meg or 1-Gig or even a 10-Gig. I am sure the community would be thankfull for any additional btest servers (especially in different locations throughout the world).

North Idaho Tom Jones

I have managed to keep btest.planetcoop.com online yet. During my new home move, i have made arrangements to keep it online. I expect to take my btest.planetcoop.com down around June first now. if i can keep it online in any capacity, I will let you know.

Thank you,
Planetcoop

Thanks for the resource! I can't tell you how many times it's been very useful for us!

We're currently building out a new 10G datacenter in our head-end and once we have the new ESXi cluster going I'd like to host a btest server. We'll have plenty of upload available and it's not going to be used.

btest server change effective immediately , aka - right now (March 22, 2018)
btest server 207.32.195.2 was moved to 207.32.194.24
Same server , same settings .. Just IP renumbered now to 207.32.194.24

btest user:btest
btest password: btest

FYI: My business is growing. We needed the entire 207.32.195.0/24 Class C netblock for some new networks we are building. Normally , I would of given a prior notice but something came up today and I had to rush a re-number on this btest server.

North Idaho Tom Jones

The planetcoop btest is back up. it was down last week due to an unexpected server hardware failure. All good now. Enjoy. Also bumped to latest RC.

Thanks for this works great,

Bill

Heads up , on the btest server 207.32.194.24 server , I just added some IP services Available-From settings.
I think the btest server is still running for everybody on the internet - however , for the IP services such as telnet , ssh , winbox , www , ftp connections , they are now blocked (except by my networks).

If I am correct - btest uses ports from 2000 on up , which is not one of the Mikrotik - IP - Services listed services.

If btest stops working , please let me know.

North Idaho Tom Jones


EDIT - added the note below:
Whoever is winbox/dude 213.57.88.215 , I am seeing a repeated connection every 30 seconds (every 30 seconds !)
Stop it , or explain it or I will have to block your network.
Or ... I may assume you are a potential hacker trying to break into my Mikrotik (possibly trying to use a recent vulnerability in ROS which Mikrotik has informed us about)

14:31:38 warning denied winbox/dude connect from 213.57.88.215
14:32:08 warning denied winbox/dude connect from 213.57.88.215
14:32:38 warning denied winbox/dude connect from 213.57.88.215
14:33:08 warning denied winbox/dude connect from 213.57.88.215
14:33:38 warning denied winbox/dude connect from 213.57.88.215

North Idaho Tom Jones

Recently , I was asked for a copy of the configuration I use on the 207.32.194.24 btest server.

Below is an export of the configuration. Note - the addres-list part of the export configuration was originally created by planetcoop who runs the other public btest server.

So for Mark Dyer and everybody else interested :



[admin@207-32-194-24-CHR-P10] /system package> print
Flags: X - disabled
# NAME VERSION SCHEDULED
0 X dude 6.42.3
1 routeros-x86 6.42.3
2 system 6.42.3
3 X ipv6 6.42.3
4 X ups 6.42.3
5 X wireless 6.42.3
6 X hotspot 6.42.3
7 X dhcp 6.42.3
8 X mpls 6.42.3
9 routing 6.42.3
10 X ppp 6.42.3
11 security 6.42.3
12 advanced-tools 6.42.3
----------------------------------------------------------------------------------
----------------------------------------------------------------------------------
[admin@207-32-194-24-CHR-P10] > export
# jun/08/2018 11:33:54 by RouterOS 6.42.3
# software id =
#
#
#

/interface ethernet
set [ find default-name=ether1 ] loop-protect=off

/queue simple
add burst-limit=1250M/0 burst-threshold=50M/0 burst-time=8m20s/0s max-limit=105M/0 name=Ether1-A-From-Internet target=ether1
add burst-limit=0/1250M burst-threshold=0/50M burst-time=0s/8m20s max-limit=0/105M name=Ether1-B-To-Internet target=ether1

/snmp community
###### If you use SNMP - then set your SNMP community settings here

/user group
add name=btest policy=test,winbox,romon,tikapp,!local,!telnet,!ssh,!ftp,!reboot,!read,!write,!policy,!password,!web,!sniff,!sensitive,!api,!dude
/user
add comment="system default user" group=full name=admin
add group=btest name=btest
#### set your admin password
#### set the password for the btest user to btest

/ip address
add address=207.32.194.24/26 interface=ether1 network=207.32.194.0
####### You need to change the above IP address for your network ether1 Internet connection

/ip dns
###### You need to insert your DNS servers here

/ip firewall address-list
add address=z.b.c.d/24 comment=00-00-Permanently-Allow-These-IP-Addresses list=tester
### You need to modify and add-repeat the aboce line for your IPs in your networks that you want to "Permanently-Allow"

add address=10.0.0.0/8 comment=01-06-Permanently-BLOCK-These-IP-Addresses list=blocklist
add address=172.16.0.0/12 comment=01-07-Permanently-BLOCK-These-IP-Addresses list=blocklist
add address=192.168.0.0/16 comment=01-08-Permanently-BLOCK-These-IP-Addresses list=blocklist
add address=138.117.109.222 list=blocklist
add address=185.34.121.32 list=blocklist
add address=162.253.51.242 comment=00-RS-BGP-Permanently-Allow-These-IP-Addresses list=tester
add address=50.235.23.218 comment=00-2btest-Permanently-Allow-These-IP-Addresses list=tester
add address=66.35.7.130 comment=00-RS-BGP-Permanently-Allow-These-IP-Addresses list=tester
add address=207.32.194.6 comment=00-00-Permanently-Allow-These-IP-Addresses list=tester
add address=207.32.194.26 comment=00-00-Permanently-Allow-These-IP-Addresses list=tester

/ip firewall raw
add action=accept chain=prerouting comment="testers accepted" src-address-list=tester
add action=drop chain=prerouting comment="previous testers drop" src-address-list=previous
add action=add-src-to-address-list address-list=tester address-list-timeout=2m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tester address-list-timeout=2m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=previous address-list-timeout=15m chain=prerouting comment="add to previous" dst-port=2000-2100 log=yes protocol=tcp
add action=add-src-to-address-list address-list=previous address-list-timeout=15m chain=prerouting comment="add to previous" dst-port=2000-2100 log=yes protocol=udp

/ip route
add distance=1 gateway=207.32.194.17

/ip service
set telnet address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,a.b.c.d/24,a.b.c.e/24
set ftp address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,a.b.c.d/24,a.b.c.e/24
set www address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,a.b.c.d/24,a.b.c.e/24
set ssh address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,a.b.c.d/24,a.b.c.e/24
set www-ssl address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,a.b.c.d/24,a.b.c.e/24
set api address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,a.b.c.d/24,a.b.c.e/24
set winbox address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,a.b.c.d/24,a.b.c.e/24
set api-ssl address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,a.b.c.d/24,a.b.c.e/24
##### Note - you need to change/modify the above ip-service a.b.c.d/24,a.b.c.e/24 so that a.b.c.d/24 and a.b.c.e/24 IP blocks are actually your IP networks

/snmp
set contact=207-32-194-24-CHR-P10 enabled=yes location=207-32-194-24-CHR-P10
### set the /snmp for your snmp information

/system clock
set time-zone-autodetect=no time-zone-name=America/Los_Angeles
##### set your system clock time-zone

/system hardware
set multi-cpu=no
##### Although this is a CHR running on a VmWare ESXi server , I only allocate 1 CPU core for me btest server to run with

/system identity
set name=207-32-194-24-CHR-P10
#### set your system identity

/system ntp client
##### Set your ntp client settings here

/system package update
set channel=release-candidate

/tool bandwidth-server
set max-sessions=500

/tool graphing interface
add

/tool netwatch
### I might suggest putting some of your gateway and upstream router IP address here


[admin@207-32-194-24-CHR-P10] >



If I missed anything - please let me know

North Idaho Tom Jones

June 19, 2018
Heads Up - FYI - I just updated the 207.32.194.24 btest server to version 6.42.4

If you have any problems with btest , please drop a posting here

North Idaho Tom Jones

June 26, 2018
Heads Up - FYI - I just updated the 207.32.194.24 btest server to version 6.42.5

If you have any problems with btest , please drop a posting here

North Idaho Tom Jones

June 26, 2018
Heads Up - FYI - I just updated the 207.32.194.24 btest server to version 6.42.5

If you have any problems with btest , please drop a posting here

North Idaho Tom Jones

Show me Can't Connect. i use 6.40.8. Thanks.

A typical Internet speedtest ( FYI - We use Mikrotik CHR routers )

Firstly thanks to Tom for providing this Service
I dunno if you guys can help me out, we have a 360Mb connection here based in Europe. I believe that we are having a few issues on the network where as we don't seem to be able to max out the connection from normal internet use, I am unsure if the issue is with the tcp bandwidth test having so many hops to Toms server or is the issue with our provider, before I call them out i would like a bit of reassurance that i am correct.
When testing to Tom's server I can pull the full 360Mb no problem at all but by TCP I can only pull ~200Mb across the link (Am taking the figures from the Ethernet Port "Combo 1")

UDP Test Result
https://imgur.com/a/cKCv71U

TCP Test Result
https://imgur.com/JFKziaW

Check CPU load (per-CPU)

Check CPU load (per-CPU)

Thanks Chupaka, I have multi-queue-ethernet-default enabled for the interfaces combo1 and ether1-local "mq piffo" 100 packets.

CPU's included in screenshots below

UDP test
https://imgur.com/h84JwYJ
TCP Test
https://imgur.com/4LcP4k1

Sorry to say, btest.planetcoop.com is no longer available. I have completed my move and will be connecting the fiber service ASAP. It has been fun. If i am able to get the service at my new location i will bring it back up.

It would be nice of others offered free public accessible btest servers in other locations around the world.

Although 1+ gig bteset servers are nice, I suspect that even some 100 meg btest servers would be very much welcome.

Any body interested in volinterring some bandwidth for some btest servers ?

North Idaho Tom Jones
(my btest server is 207.32.194.24 btest/btest)

It would be nice of others offered free public accessible btest servers in other locations around the world.

Although 1+ gig bteset servers are nice, I suspect that even some 100 meg btest servers would be very much welcome.

Any body interested in volinterring some bandwidth for some btest servers ?

North Idaho Tom Jones
(my btest server is 207.32.194.24 btest/btest)

i just test, it run for awhile and now when i ping it become request time out..

It would be nice of others offered free public accessible btest servers in other locations around the world.

Although 1+ gig bteset servers are nice, I suspect that even some 100 meg btest servers would be very much welcome.

Any body interested in volinterring some bandwidth for some btest servers ?

North Idaho Tom Jones
(my btest server is 207.32.194.24 btest/btest)

i just test, it run for awhile and now when i ping it become request time out..

I have a firewall rule in the btest server. Connections to the btest server will eventually get blocked. Then the remote admin will need to wait for a timer to expire. After the btest FW timer expires, then the remote btest user can test again. Then is to help prevent abuse and/or excessive use - thus freeing up bandwidth for other btesters.

North Idaho Tom Jones

(my btest server is 207.32.194.24 btest/btest)

Can't get connected to this any longer. Haven't used it previously, so it's not a hog timeout. Last time I used it, you had a different name and password, so it's been some time. Now I just get a long "connecting" and a "can't connect."

macsrwe re: Can't get connected to this any longer.

What IP address are you testing from ? I can look at the fw logs and see if your IP address shows up in there.

North Idaho Tom Jones (207.32.194.24 btest admin)

FYI - btest bandwidth usage

About an hour ago , I rebooted the 207.32.194.24 btest server
Now an hour later after I rebooted it , it has sent over 10+ Gib Bytes and received 3+ Gib Bytes in btest(s).

lol - take that 1 hour of time and stretch it out over 3 years , the btest(s) send -and- receive Bytes really start to add up to one heck of alot of Bytes.


North Idaho Tom Jones

macsrwe re: Can't get connected to this any longer.

What IP address are you testing from ? I can look at the fw logs and see if your IP address shows up in there.

North Idaho Tom Jones (207.32.194.24 btest admin)

198....

macsrwe re: Can't get connected to this any longer.

What IP address are you testing from ? I can look at the fw logs and see if your IP address shows up in there.

North Idaho Tom Jones (207.32.194.24 btest admin)

198.233.88.218

I do see it is trying to connect - but no btest is starting ...
Hmmm , Try updating the ROS version of your Mikrotik to the latest. I am currently running 6.42.7
I think you might need to be on the same version
After you upgrade - give it a try again and let me know

North idaho Tom Jones

I do see it is trying to connect - but no btest is starting ...
Hmmm , Try updating the ROS version of your Mikrotik to the latest. I am currently running 6.42.7
I think you might need to be on the same version
After you upgrade - give it a try again and let me know

North idaho Tom Jones

I upgraded a non-critical unit on my network and it worked. Then I tried a non-upgraded router and it also worked. Then I retried it from my edge router where it failed this morning, and this time it worked.

I blame Russians.

Thanks for your help.

FYI - btest bandwidth usage

About an hour ago , I rebooted the 207.32.194.24 btest server
Now an hour later after I rebooted it , it has sent over 10+ Gib Bytes and received 3+ Gib Bytes in btest(s).

lol - take that 1 hour of time and stretch it out over 3 years , the btest(s) send -and- receive Bytes really start to add up to one heck of alot of Bytes.


North Idaho Tom Jones

Tom,

I was averaging 30TB total monthly in/out traffic with it on the 10gbps link. Crazy busy.

FYI - btest bandwidth usage

About an hour ago , I rebooted the 207.32.194.24 btest server
Now an hour later after I rebooted it , it has sent over 10+ Gib Bytes and received 3+ Gib Bytes in btest(s).

lol - take that 1 hour of time and stretch it out over 3 years , the btest(s) send -and- receive Bytes really start to add up to one heck of alot of Bytes.


North Idaho Tom Jones

Tom,

I was averaging 30TB total monthly in/out traffic with it on the 10gbps link. Crazy busy.

Same monthly averages here - 20 to 60 TB every month on the 207.32.194.24 btest server

Gracias por el servicio ofrecido ,es muy útil para probar los mikrotiks , para ver su poder y si el ISP ofrece realmente lo que venden tan caro .

saludos
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Thanks for the service offered, it is very useful for testing the mikrotiks, to see their power and if the ISP really offers what they sell so expensive .

regards

Gracias por el servicio ofrecido ,es muy útil para probar los mikrotiks , para ver su poder y si el ISP ofrece realmente lo que venden tan caro .

saludos
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Thanks for the service offered, it is very useful for testing the mikrotiks, to see their power and if the ISP really offers what they sell so expensive .

regards

The public access btest server 207.32.194.24 was just now updated to 6.43

North Idaho Tom Jones

We've used the public server for a long time with no issues. For the last few days we are unable to connect. We use tcp. We are getting either connect which just hangs, or Device incompatible . We tried to set the connect count to 1 and it immediately disconnects. Did something change recently? We are on the latest bug fix release.

We've used the public server for a long time with no issues. For the last few days we are unable to connect. We use tcp. We are getting either connect which just hangs, or Device incompatible . We tried to set the connect count to 1 and it immediately disconnects. Did something change recently? We are on the latest bug fix release.

I might be wrong here - but I believe I recently read that a Mikrotik btest client (one of your Mikrotiks) now needs to be the same ROS version at the Mikrotik btest server (if passwords are used).
My 207.32.194.24 btest server uses user=btest and password=btest , thus I suspect the client Mikrotik needs to be the same ROS version.
I am currently using ROS version 6.43

So - as a test , try upgrading a client btest Mikrotik to ROS version 6.43 and see if it works.

Note 1: A couple of days ago , I had somebody pm me about their btest not running to my btest server , they then upgraded to 6.43 and the btest worked.

Note 2: I think I also read that if there is no btest password configured on the btest server (or authentication not enabled "don't remember exactly" ) that any cleint of any ROS version can then perform a btest


Please try upgrading a client btest Mikrotik and test it - and - please post her to let me know if I am correct about the matching ROS versions if btest passwords are used.


Also of note - a possible work-around with different ROS versions might be for me to create a second btest user on my btest server that does not have a password. I will have to look into what security issues that opens up if not configured correctly on my btest server.


North Idaho Tom Jones

Tom,

You are correct. Here is the changelog:

MAJOR CHANGES IN v6.43:
----------------------
!) api - changed authentication process (https://wiki.mikrotik.com/wiki/Manual:API#Initial_login);
!) backup - do not encrypt backup file unless password is provided;
!) btest - requires at least v6.43 Bandwidth Test client when connecting to v6.43 or later version server except when authentication is not required;
!) cloud - added IPv6 support;
!) cloud - added support for licensed CHR instances (including trial);
!) cloud - reworked "/ip cloud ddns-enabled" implementation (suggested to disable service and re-enable after installation process);
!) radius - use MS-CHAPv2 for "login" service authentication;
!) romon - require at least v6.43 RoMON agent when connecting to v6.43 or later RoMON client device;
!) webfig - improved authentication process;
!) winbox - improved authentication process excluding man-in-the-middle possibility;
!) winbox - minimal required version is v3.15;

Would you be able to create another user? It doesn't seem like it would be an issue because everyone knows the password anyway. If you can't, then everyone would need to be on your ros version which won't work for a lot of setups. If you could, that would be great. Thanks for all the help.

Maybe the authentication requirement on the public btest servers should be switched off. What is its meaning when the user and password is publicly known?

Wow - somebody has a fast Internet connection
This image is from my 207.32.194.24 btest server just a few minutes ago.

This morning I upgraded the 207.32.194.24 btest server to 6.43.1

Wow - somebody has a fast Internet connection
This image is from my 207.32.194.24 btest server just a few minutes ago.

Thanks for running this bandwidth test server by the way!

I was able to get a 1.5Gbit test from my newly acquired 10G line but I wasn't able to grab a screenshot of it in time. Just waiting patiently for the rate limiting to settle down so I can try again.

It's hard nowadays to validate that ISPs actually deliver on what they promise, so I really appreciate you running this for free!

[If ya wanna break some graphs, I would love to schedule a time and see what happens without a rate limit! ]

I just upgraded the 207.32.194.24 btest server to : Ver 6.43.2

As always , you may want to consider upgrading your Mikrotik also to 6.43.2 and then run a btest

North Idaho Tom Jones

Thanks a lot for hosting and maintaning this service!

Any idea what could be wrong? Tried connecting the last 3-4 days..

Could be beneficial to someone if I would open the 100/100 Mbit/s public btest server in Europe? Just asking in advance...

Could be beneficial to someone if I would open the 100/100 Mbit/s public btest server in Europe? Just asking in advance...

I know a btest server in Europe would be used by many
North Idaho Tom Jones

For sure, but the 100mbits limitation might be problematic. Also I couldn't guarantee such speed to be achievable always, which could lead to lower measurements. Therefore the question if such thing makes sense.

For sure, but the 100mbits limitation might be problematic. Also I couldn't guarantee such speed to be achievable always, which could lead to lower measurements. Therefore the question if such thing makes sense.

On the forum , your server could be listed as the following limitations (what ever you want worded)
- no guarantee on bandwidth availablility for btest (ing)
- no guarantee on low/hi measurements

EDIT: Below is an export of my btest config. It includes a simple-queue which can be changed for your limits:

/interface ethernet
set [ find default-name=ether1 ] advertise=1000M-full loop-protect=off
/queue simple
add burst-limit=1250M/0 burst-threshold=50M/0 burst-time=8m20s/0s max-limit=105M/0 name=Ether1-A-From-Internet target=ether1
add burst-limit=0/1250M burst-threshold=0/50M burst-time=0s/8m20s max-limit=0/105M name=Ether1-B-To-Internet target=ether1
/user group
add name=btest policy=test,winbox,romon,tikapp,!local,!telnet,!ssh,!ftp,!reboot,!read,!write,!policy,!password,!web,!sniff,!sensitive,!api,!dude
/ip firewall address-list
add address=207.32.193.0/24 comment=00-05-Permanently-Allow-These-IP-Addresses list=tester
add address=10.0.0.0/8 comment=01-06-Permanently-BLOCK-These-IP-Addresses list=blocklist
add address=172.16.0.0/12 comment=01-07-Permanently-BLOCK-These-IP-Addresses list=blocklist
add address=192.168.0.0/16 comment=01-08-Permanently-BLOCK-These-IP-Addresses list=blocklist
add address=138.117.109.222 list=blocklist
add address=185.34.121.32 list=blocklist
add address=162.253.51.242 comment=00-RS-BGP-Permanently-Allow-These-IP-Addresses list=tester
add address=50.235.23.218 comment=00-2btest-Permanently-Allow-These-IP-Addresses list=tester
add address=66.35.7.130 comment=00-RS-BGP-Permanently-Allow-These-IP-Addresses list=tester
add address=207.32.194.6 comment=00-00-Permanently-Allow-These-IP-Addresses list=tester
add address=207.32.194.26 comment=00-00-Permanently-Allow-These-IP-Addresses list=tester
/ip firewall raw
add action=accept chain=prerouting comment="testers accepted" src-address-list=tester
add action=drop chain=prerouting comment="previous testers drop" src-address-list=previous
add action=add-src-to-address-list address-list=tester address-list-timeout=2m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tester address-list-timeout=2m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=previous address-list-timeout=15m chain=prerouting comment="add to previous" dst-port=2000-2100 log=yes protocol=tcp
add action=add-src-to-address-list address-list=previous address-list-timeout=15m chain=prerouting comment="add to previous" dst-port=2000-2100 log=yes protocol=udp
/ip service
set telnet address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,207.32.193.0/24
set ftp address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,207.32.193.0/24
set www address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,207.32.193.0/24
set ssh address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,207.32.193.0/24
set www-ssl address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,207.32.193.0/24
set api address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,207.32.193.0/24
set winbox address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,207.32.193.0/24
set api-ssl address=192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,207.32.193.0/24
/tool bandwidth-server
set max-sessions=500
/tool graphing interface
add

Thanks Tom, I am still far from the moment I could use it, I need to see if there is any demand first.

Why not just start from opening it in 'demo' mode and look at BTest traffic?

Because it requires some effort and costs.

jarda , if you decide to open up a btest server …
--- You will become rich
--- Women will flock around you for your attention
--- You will win every game at casinos and lottery
--- Your network will run faster
--- You will have lots of free time
----------or----------
--- You will go broke paying for the additional bandwidth of a btest server
--- Other that your wife , nobody knows who you are
--- You will still be a looser at everything you do
--- Your network will be slower because it now experiences high bandwidth btest loads
--- You will be busy answering questions (via this forum, email, facebook and PM) about why they can't btest to you
----------or----------
--- Somewhere between the maximums there is a medium

lol

--- Other that your wife , nobody knows who you are

Huh, it's just about me

--- Other that your wife , nobody knows who you are

Huh, it's just about me

lol

Anybody remember my original post that eventually led to a public btest server ?
I made a suggestion about everybody participating in a btest day for everybody to btest to/from to measure bandwidth around the world. Then somebody made a post stating
"The day the Internet broke".


Anyways , I believe all of us Mikrotik admins would welcome any public access btest servers of any speeds/capabilities.

North Idaho Tom Jones

Tom, it might be even much worse anyway.

The public btest server could be one of the side effects of other of my ideas, and it might take a while, but I believe I will open it finally.

i need bandwidth test server from Turkey location . please help me is is there any server in turkey.

i need bandwidth test server from Turkey location . please help me is is there any server in turkey.

As for public btest access and posted here in this forum about any Mikrotik btest server(s) , My 207.32.194.24 btest server is the only one I know of at this time.

North Idaho Tom Jones

@North Idaho Tom Jones
btest dead ?

Thanks for running this bandwidth test server

Please tell me how to create a script to record the test results to the log or send to the mail?

after what time can repeat testing?
I think re-check for a short time is blocked.

Hi tom,
I'm getting after a speedtest on your server several incoming attempts from port scans from your ip. please check your router... currently I have blocked your ip. Thanks for this server

Hi tom,
I'm getting after a speedtest on your server several incoming attempts from port scans from your ip. please check your router... currently I have blocked your ip. Thanks for this server

hmmm, My btest server should be clean and normal. I just rebooted it.

However , I have sometimes seen a stuck btest. Example - a remote btest is started and the remote Mikrotik device looses connectivity to the Internet which a few times has resulted in the btest server still running. This is rare when it happens. The solution is normally to reboot the btest server or the btest client then the problem stops. This used to happen only when under loads greater than 2-gig sustained - however I have not seen btest get stuck in at least 1/2 a year now...

Of note - I have mostly seen stuck btest(s) on x86 Mikrotiks or slower physical Mikrotiks devices running btest. I have never seen a CHR to CHR stuck btest with vmxnet3 10-gig network interfaces - but in the past , I have seen it a few times with just about everything else (other than a CHR) when a btest is saturating a link.

North Idaho Tom Jones

i made a btest server ip-103.80.55.2 with no user and password . take a test and enjoj

i made a btest server ip-103.80.55.2 with no user and password . take a test and enjoj

Nice

I just ran some btest(s) from my 207.32.194.24 btest server to your 103.80.55.2 btest server.
UDP send test and UDP receive btest each way comes close to 150 meg (130 to 148 meg).
TCP send test and TCP receive test each btest at around 80 meg.

Is this going to be a perminate btest server ?
Where are you located ?
What kind of Mikrotik hardware/software are you using ?
How fast under perfect conditions should somebody be able to btest to ?
Are you using any rate-limiting queues fire-wall rules so that you do not have continous never go away sustained btest (btest abusers) ?
Do you have a btest policy/user-rules you would like to state ?
Would you like me to post/edit-add information about your btest server on the 1'st post in this btest forum?

North Idaho Tom Jones

December 3rd 4:45 PM (Idaho time)
I just now upgraded the 207.32.194.24 btest server to version 6.43.7


North Idaho Tom Jones

Hi Tom,

This is a great service, thanks for offering to the community.

For me it works about 20 sec, then traffic is completely blocked for XX minutes. I am not sure if it is by design but this turns out to be a bit short to do any sort of stability controls. Tested using UDP with a 100mbps symmetrical connection.

For me it works about 20 sec, then traffic is completely blocked for XX minutes. I am not sure if it is by design but this turns out to be a bit short to do any sort of stability controls. Tested using UDP with a 100mbps symmetrical connection.

My bad actually, I have an automatic synflood rule that kicks in.
Maybe BTest is not behaving nicely with this regards. Sorry.

For me it works about 20 sec, then traffic is completely blocked for XX minutes. I am not sure if it is by design but this turns out to be a bit short to do any sort of stability controls. Tested using UDP with a 100mbps symmetrical connection.

My bad actually, I have an automatic synflood rule that kicks in.
Maybe BTest is not behaving nicely with this regards. Sorry.

Yea - I have a Simple-Queue that kicks in. Below is my Simple-Queue in detail

Heads up
I just upgraded the 207.32.194.24 btest server from 6.43.7 to 6.43.8

North Idaho Tom Jones

Yo , heads up to --> 131-161-104-26.rev.netcorporativa.com.br


The btest server 207.32.194.24 is intended for brief btest speed testing to show your maximum peak throughput. When any btester holds executes and holds an extended continouis btest, the simple-queue settings will kick in and limit all btest sessions for all btesters to a combined 105 Meg maximum. This means that a Mikrotik admin that would may normally acheive 1-Gig on a btest to my server will now get 105 Meg or less (because somebody is not performing a brief btest and instead keeping an extended btest session running which will then have negative slower results for anybody else also measuring a btest throughput speed test.

FYI

North Idaho Tom Jones

What about using PCQ Bursting for this? So it will affect only bad IPs, and total bursting can be relaxed or removed

What about using PCQ Bursting for this? So it will affect only bad IPs, and total bursting can be relaxed or removed

I like the idea of PCQ , however (if I am correct in my thinking) it would then be possible to have a degrading effect on my Internet feeds to my customers. With PCQs, it would then be possible to have a combined total btest throughput load greater than my Internet feeds can support which could then possibly have a negative impact effect on my many customer connections to the Internet.

You can still leave max-limit and total queue burst in place, just with possibly higher values

Feb 6th (7:50 AM PST - North Idaho USA time) , I just now updated the public btest server 207.32.194.24 from ROS version 6.43.8 to ROS version 6.43.11


If you notice any strange problems after the btest server ROS upgrade , please let me know


North Idaho Tom Jones

How do you host a server?

How do you host a server?

Re: How do you host a ( btest ) server ?
Answer - From North Idaho Tom Jones - admin for btest server 207.32.194.24

Hosting a btest server:
- 1st ; Mikrotik does not oficially endorse or host any btest servers that I know of. Back in 2016, I just made a btest server and posted it to the Mikrotik forums.
- 2nd ; All you need to do is the following:
-- a) configure a Mikrotik (I use a CHR) with a live IP address (so that remote Internet btest-ers can test to it ( TCP send & receive and also UDP send & receive )
-- b) disable any firewalls on the btest server (My btest server does not have any firewalls , I did this so that remote btesters and performs btests to/from it).
--c) on the new btest server you are creating , crease a " btest " user and a " btest " group.
My " btest " user is a member of the " btest " group
My " btest " group has only the following Policies checked " test & winbox & romon & tik.app "
--d) under IP Services , modify every IP Service to only have your IP addresses.
example: winbox Port 8282 should have one or multiple entires for your IP addresses
Note: Use IP Services to pervent others out on the Internet from telnet-ing and/or ssh-ing and/or winbox-ing (an entry for each service)

Then after your new btest server is up and running , simply post here in this forum your IP address and btest user name and password ( I would assume btest and btest ) along with information about where you are , who you are, and what speeds your server can handle for btesting , also include any policy you would like to state so that others can follow your desired btest server policies.
I will then add your btest server to the first posting of this Mikrotik btest forum topic.
If/when you have your btest server running, you are welcome to private message me so that I can take a look at it to make sure everyting looks OK.
If you would like some help , just PM me and I can winbox into your new btest server and configure it for you.

North Idaho Tom Jones

Info - I just updated the 207.32.194.24 btest server from 6.43.11 to 6.43.12

North Idaho Tom Jones

i cannot thank you enough for this

Info - I just updated the 207.32.194.24 btest server from 6.43.11 to 6.43.12

North Idaho Tom Jones

THANK YOU!!!

Info - I just updated the 207.32.194.24 btest server from 6.43.12 to 6.44

North Idaho Tom Jones


- and - also check this out …
Martooo has spun up a btest server
Here is a link to his Mikrotik forum topic: viewtopic.php?f=2&t=145303

How do you run a bandwidth server on linux?

How do you run a bandwidth server on linux?

Hmmm … How do you run a bandwidth server on linux?

Well , If I were to run a " btest " server on a Linux operating system , I would do it this way:
- 1st , install VMware ESX. This is a free hypervisor for systems such as Linux.
Note - not to be confused with VMware ESXi (which also has a Unix/BSD/Linux operating system)
- 2 , with VMware ESX , you should now be able to run several different guest operating systems at the same time.
- 3 , next , I would purchase a 64-bit Mikrotik router operating system ( CHR )
- 4 , that's 99 percent what to do , the other 1 percent is just basic configuration.

--- Another possible way to do this at zero cost , I have not tested this but it should work ---
- 1st , install Wine on your Linux operating system (Wine lets you run in a near windows environment)
- 2nd , download from Mikrotik something called " btest ". This is a Mikrotik program which will perform btest's both as a client and as a server. ( I've used Mikrotik's btest program on my Windows computers to test network throughput ).


North Idaho Tom Jones

Bizarre there is no linux program from mikrotik that does this

1st - As of this posting right now (March 14th 2019) , this forum topic "Public-Mikrotik-Bandwidth-Test-Server(s)" which was started around 3 years ago currently has 332,700 views.
Anybody have a prediction when this topic will hit 1/3 of a million (333,333) views ?
My guess is around the last day of this month.

2nd - This is more of a Mikrotik new-feature wish list:
I would like to see a new optional Mikrotik ROS package which can perform http speedtests between Mikrotiks and client connected computers (something similar to http://my-mikrotik-IP-address/speed-btest).
… Where an optional login/password could be used to perform a http UDP-or-TCP up-or-down bandwidth test
… Where a client computer behind NATted Mikrotik could perform speedtests to their inside Mikrotik gateway IP address , and/or to any Mikrotik IP address out on the Internet.
… Where the Mikrotik admin has some control for maximum bandwidth, number of simultaneous speed-btest testers, and setting to limit how often a client can perform a http speed-btest.
… The Mikrotik http speed-btest should be a simple TCP-up, then TCP-down, then UDP-up then UDP down, followed by a round-trip-ping response time.
… The output after the http speed-btest could then report all kinds of information , including the number of dropped packets during each test -and- it would also be nice to show at what speeds RED ( Random Early Detection ) begins kicking in with dropped packets.
I suspect this type of a Speed-btest server could become very very popular. And the http speed-btest web page could show some pre-configured ISP hosting information and a URL indicating "Powered by Mikrotik" which links to Mikrotik. Mikrotik just might get a boost in sales from something like this.

North Idaho Tom Jones

FYI - I just now (March 14th 2019) updated the public btest server 207.32.194.24
was ROS version 6.44
now ROS version 6.44.1

If you experience any issues after the update - please let me know

North Idaho Tom Jones

Mikrotik provide test servers

Mikrotik provide test servers

Re : Mikrotik provide test servers

Are you asking " Does Mikrotik provide public btest servers to test to ? "
Answer: No (at least I don't think so)

Are you asking " Does Mikrotik provide (free) physical routers to host a public btest server ? "
Answer: No

Are you asking " Does Mikrotik provide free ROS (CHR) software to host a public btest server? "
Answer: No

Are you asking " Does Mikrotik offset your expense to host a public btest server? "
Answer: No

Are you asking " What are the benefits of hosting a public btest server? "
Answer: You will help hundreds/thousands/tens-of-thousands of network admins by letting them test to your public btest server.

Are you asking " Do I need permission from Mikrotik to host a free public btest server? "
Answer: No

North Idaho Tom Jones
private owner of the public btest server 207.32.194.24 since January 2016

No, telling them to provide servers like ubiquiti do

No, telling them to provide servers like ubiquiti do

I think it's much easier to add speedtest.net client - they have servers all over the world

Are any of the servers still available to test 2 routers?

Are any of the servers still available to test 2 routers?

My btest server 207.32.194.24 is still available to btest to.

North Idaho Tom Jones

No, telling them to provide servers like ubiquiti do

I think it's much easier to add speedtest.net client - they have servers all over the world

It would be nice if Mikrotik came out with an optional ROS server package which would allow computers to perform http speedtests to a Mikrotik.

FYI - the public access 207.32.194.24 btest server was just now upgraded from ROS 6.44.1 to ROS 6.44.2

North Idaho Tom Jones

Any IPv6 btest servers?

Unable to connect as of today.

System upgraded, but unable to connect Tom's btest Server.

No, telling them to provide servers like ubiquiti do

I think it's much easier to add speedtest.net client - they have servers all over the world

It would be nice if Mikrotik came out with an optional ROS server package which would allow computers to perform http speedtests to a Mikrotik.

Be good if they came up with a simple Linux script you could run to host a test server, or have RouterOS test using standard files that the Speedtest web sites use like 100MB bin files.

Unable to connect as of today.

Same here.

Re : unable to connect

Try it now

I just rebooted the btest server

North Idaho Tom Jones

Holey smokes …
5 seconds after rebooting the btest server ( 207.32.194.24 ) , I had 3 btesters connected to it.
Either we have some automated bot btesters running or some in this forum are very fast at reading my prior post and then btesting -or- a combination of both.

North Idaho Tom Jones

unable to connect to 207.32.194.24

FYI - just now ( April 24th 2019 @ 2PM North Idaho time )
I updated/upgraded the 207.32.194.24 public access btest server
From: ROS version 6.44.2
To: ROS version 6.44.3

North Idaho Tom Jones

FYI

On average, per every 15 minutes , my 207.32.194.24 btest server will have around 30 different/unique IP addresses of remote Mikrotik devices which have performed a btest.
That's an average of a btest session starting every 30 seconds.

For the last 30 days , the 207.32.194.24 btest server as a 30 day sustained average rate transfer of :
35 meg-bits-per-second to the remote btest client
20 meg-bit-per-second from the remote btest clinet
Combined up/down is 55 meg-bits-per-second

Now a little math to calculate bits per year at current rate : ( ( ( ( 55 meg-bits-per-second * 60 ) * 60 ) * 24 ) * 365 ) = 1,734,480,000,000,000 bits
- that's 1,734 terra-bits !!! also known as 217 terra-bytes
- - - Question - When is the last time you moved 217 terra-bytes to/from the Internet that was not directly related to your Internet customer traffic ?

Note - the above data is "average" not "peak" !

North Idaho Tom Jones

btest still working ?
from croatia not working
207.32.194.24

btest still working ?
from croatia not working
207.32.194.24

I had to reboot it ?

Strange , this is the 3rd time in the last few months I had to reboot it.

The problem started 1 or 2 or 3 ROS versions ago.
What happens is the "BTest-Server-Settings" [x] Enabled and the [x] Authenticate check boxes both somehow become un-checked.
When I reboot my 207.32.194.24 CHR btest server, it comes back with both settings checked again.
Strange … … …
I have not made any changes to the btest server for more than a year - except when a new version of ROS comes out , then I upgrade it.

Is anybody else seeing other strange problems with btest servers or related strange things since the last version (or two) of ROS ?

If it happens again in the near future , I'll send info to Mikrotik's tech support and let them know what I am experiencing with the 207.32.194.24 btest server.

North Idaho Tom Jones

Little help here …
I am just now starting to work with IPv6 , grrrrrr
Although I've been doing IP networking for almost 30 years now , I've never played with IPv6
My bad
Anyways, I have setup a test Mikrotik running IPv4 and IPv6 ( not the 207.32.194.24 server) , and I wish to ask if somebody has a IPv6 Mikrotik I can perform a few IPv6 btest(s) to/from.
If somebody is willing to assist, you can post here or PM me.

(FYI - my test IPv6 Mikrotik is on another ISP network I do not manage)
When I get IPv6 running on my network, I may create two more btest servers so that I end up with 3 btest servers. 1-Only IPv4 , 2-Only IPv6, 3-IPv4&IPv6 btest servers. (If Mikrotik is willing to donate the CHR software when I have IPv6 running on my ISP network).


North Idaho Tom Jones

Hello,
is btest 207.32.194.24 working? I tried from 3 different locations with 6.44.1 and 6.44.3 but without any luck.

Thanks

Hello,
is btest 207.32.194.24 working? I tried from 3 different locations with 6.44.1 and 6.44.3 but without any luck.

Thanks

Nope - The 207.32.194.24 btest server was down again.
I just rebooted it - it is now up again
It looks like it quit working May 16th at about 8PM PST (Los Angeles time)

The 207.32.194.24 btest server somehow had both the btest enabled & authenticate unchecked.
A reboot of the btest server got it back on-line without making any changes.
I am pretty sure this is a Mikrotik CHR ROS problem - because I have not made any changes to it this year.
Hey Mikrotik - you reading this - I suspect there may be something going on ….

North Idaho Tom Jones

Hello,
is btest 207.32.194.24 working? I tried from 3 different locations with 6.44.1 and 6.44.3 but without any luck.

Thanks

Nope - The 207.32.194.24 btest server was down again.
I just rebooted it - it is now up again
It looks like it quit working May 16th at about 8PM PST (Los Angeles time)

The 207.32.194.24 btest server somehow had both the btest enabled & authenticate unchecked.
A reboot of the btest server got it back on-line without making any changes.
I am pretty sure this is a Mikrotik CHR ROS problem - because I have not made any changes to it this year.
Hey Mikrotik - you reading this - I suspect there may be something going on ….

North Idaho Tom Jones

Thanks all good
Hope mikrotik will fix this bug, keep on the good job

Well - rather strange - but It looks like a found a Band-Aid solution temp fix which appears to keep the 207.32.194.24 btest server on-line and available without the random problem where the btest server keeps disabling itself.
What I did was this:
- disable all IP services on the Mikrotik CHR except for www
- change the default www port from 80 to another port number

If you encounter problems with the 207.32.194.24 btest server not responding, please post & let me know.

FYI - I suspect other tik devices could possibly be experiencing the same issue where the IP service (btest in my case) for no reason suddenly quits.

North Idaho Tom Jones

Thanks for making this available, unfortunately I'm not able to make it work. I have the latest packages and firmware, just updated today.
Any thoughts on why it's not working?

For me is out as well!

K - I just rebooted it - give it a try now

Tried again, no luck, it does seem to connect now but no throughput, here's a screenshot:

[mod@MikroTikLV] > /tool bandwidth-test 207.32.195.2 user=btest password=btest protocol=udp duration=30 direction=receive
status: connecting
rx-current: 0bps
rx-10-second-average: 0bps
rx-total-average: 0bps
lost-packets: 0
random-data: no
direction: receive
rx-size: 1500
connection-count: 20

Tried again, no luck, it does seem to connect now but no throughput, here's a screenshot:

[mod@MikroTikLV] > /tool bandwidth-test 207.32.195.2 user=btest password=btest protocol=udp duration=30 direction=receive
status: connecting
rx-current: 0bps
rx-10-second-average: 0bps
rx-total-average: 0bps
lost-packets: 0
random-data: no
direction: receive
rx-size: 1500
connection-count: 20

hmmm - Some time ago it was 207.32.195.2 - but it was changes around a year ago to 207.32.194.24 ( read the posts )
North Idaho Tom Jones

Thanks Tom, I did browse through many pages trying to find the latest syntax but apparently missed it. Works great now, really appreciate it.
Dan

Thanks Tom, I did browse through many pages trying to find the latest syntax but apparently missed it. Works great now, really appreciate it.
Dan

Dan - you're a good man
I don't care about any mistakes and/or overlooks you make - lol

Happy to know yer working now

North Idaho Tom Jones

Again not working??

User pass btest
Disconnected

Without pass say auth faild

Same problem today, unable to connect

same today. Btest server down. I guess its because this is the only server available and many users flood it. Sorry to see only North Idaho Tom Jones hosting one. Someone should step up and offer more severs for the community. We cant realistically expect that only one server will quench the thirst of mikrotik users worldwide.

Thanks NITJ for the service so far. KUDOS

Some good news

The btest server 207.32.194.24 is now also IPv6

IPv4 address: 207.32.194.24
IPv6 address: 2605:4e40:0:1fe::

user: btest
password: btest

If I do not see any abuse , then I will keep the IPv6 address also

North Idaho Tom Jones

FYI - update on the btest server(s) for:
IPv4 address: 207.32.194.24
IPv6 address: 2605:4e40:0:1fe::

A few moments ago , I made the following changes to the public accessible btest server:
#1 - Instead of having a single ether1 with both IPv4 and IPv6 addresses , I changed the server so that it is now:
ether1: IPv4 address: 207.32.194.24
ether2: IPv6 address: 2605:4e40:0:1fe::
I did this so that I can get clear graphs for IPv4 traffic and another graph for IPv6 traffic

#2 - I changed the firewall rules (for IPv4 and IPv6) where the wait-time-delay was 15 minutes , the new wait-time-delay is 1 hour.
This is the time a previous btester must wait until they can btest again. I made this test because I see there are some remote users who had scripts that would auto-script a best to my btest server every 15 minutes. This btest server is not intended to be used as a traffic graphing system for other networks. It is intended for Mikrotik admins to be able to manually perform brief btest(s) to verify and test their network reliability and throughput (from time to time - not automatically tested on a pre-configured script schedule).

I would like to ask for some feedback if you don't mind …
--- Who and where-are-you to those who use the btest server ?
--- Does the new IPv6 btest address appear to be working correctly ?
--- And comments are always welcome ……

North Idaho Tom Jones

I would like to ask for some feedback if you don't mind …
--- Who and where-are-you to those who use the btest server ?
--- Does the new IPv6 btest address appear to be working correctly ?
--- And comments are always welcome ……

North Idaho Tom Jones

Hi Tom,

Hope to be near you in Northern Idaho very soon, but for now NE Texas. When I connect to other MikroTiks on our WAN, I get a speedtest back as I would expect, but when I connect to yours, I get a flatline zero. Do I need to change any settings? Thanks for the server.

I would like to ask for some feedback if you don't mind …
--- Who and where-are-you to those who use the btest server ?

I've used it perhaps a dozen times over the past 18 months from the region surrounding Wickenburg, Arizona, to ensure periodically that WAN providers are (still) offering the speeds my clients are paying for. This would be much more difficult to do without the service you offer, so thank you so much.

I just don't get it. If I connect to another MikroTik on our WAN, I see a normal throughput graph, but if I connect to this one, it's a 0 flat-line like a patient in asystole. What am I missing?

I just don't get it. If I connect to another MikroTik on our WAN, I see a normal throughput graph, but if I connect to this one, it's a 0 flat-line like a patient in asystole. What am I missing?

Sorry for what may be an obvious question, but are you connecting to it with the bandwidth test tool, or just connecting to it?

Thanks for the reply, and no apology necessary. I realize you have to ask in these situations. I am connecting under Tools > Bandwidth Test. When I get a connect while attached to the MikroTik via a browser I get a flat line. If I connect to a remote MikroTik across on of our VPN tunnels, I get 35 Mbps which is the upload bandwidth limitation for the remote MikroTik. Last night I found that I could connect to this one via Winbox, but when I did, I got 1200 bps (12kbps). Today if I connect via Winbox I get 0 just like browser based. Again, if I connect to our other MikroTik across the VPN via Winbox I get 35 Mbps.

Is the firmware out of date by chance? I'm running 6.45.1 on a CCR but when I try to do a test to 207.32.194.24 it just sits at the connecting phase. I'm located in Central Texas trying to check the throughput of a new service upgrade on the wan.

Not working for me now, the other btest server that you linked in your original post works.

Not working for me now, the other btest server that you linked in your original post works.

If you post your WAN IP address, I can check the btest server and see if there is something stuck in my auto-updating queues and fw auto-timeout rules.

North Idaho Tom Jones

Probably something in the following range: 129.205. 144.0/24

They are changed around so can't give you a 100% on the last digit.

There simply just has to be a bug in the Mikrotik ROS !!!
On the public btest server 207.32.194.24 ( also IPv6 2605:4e40:0:1fe:: ) , the btest server settings somehow changed to :
btest server DISABLED (check box not checked)
btest server Authenticate DISABLED (check box not checked)

I re-enabled the two settings and rebooted the btest server

Give it a try and see if the btest server is now working.

((( This simply just has to be a bug in ROS )))
I have two CPUs assigned to my VMware ESXi btest server
I have 1-Gig of RAM assigned to my VMware ESXi btest server
Last time - I made a band-aid fix by disabling Winbox on the server - I will again disable it and see if those two settings again somehow get disabled

North Idaho Tom Jones

Still no joy, goes straight to disconnected.

Can traceroute to site although it looks like you have ICMP rate limiter on?

Hello, I've just tested to both IPv4 and IPv6 addresses from one of my RB2011 (Slovakia, Central Europe) on ROS 6.45.11 and both worked great, Thank you!

On IPv4 I've got approximately 75/65Mbps and IPv6 was even 95/85Mbps (UDP both way).
Those speeds are good enough for the installation site, but I wonder what would cause such a difference?
Could it be just my provider prioritizing IPv6? Configuration issue on my side? Is it to be expected?

Hello, I've just tested to both IPv4 and IPv6 addresses from one of my RB2011 (Slovakia, Central Europe) on ROS 6.45.11 and both worked great, Thank you!

On IPv4 I've got approximately 75/65Mbps and IPv6 was even 95/85Mbps (UDP both way).
Those speeds are good enough for the installation site, but I wonder what would cause such a difference?
Could it be just my provider prioritizing IPv6? Configuration issue on my side? Is it to be expected?

In my opinion …
There are two methods to implement IPv6 routers/networks (with the current IPv4 networks).
- use/build Dual-Stack routers/networks ( were routers in a network are both IPv4 and IPv6 at the same time )
- Add IPv6 routers/networks next to existing IPv4 routers/networks (where you have a mix of only IPv4 routers/networks -and- only IPv6 routers/networks)

Both methods to implement IPv6 work well. ( I'm building both types in my IPS/WISP networks - where some networks use only IPv4 sitting next to only IPv6 routers/network … and other parts of my network are Dual-Stack ( both IPv4 and IPv6 ). There are advantages of both methods to implement IPv6 into your network.
If an IPv4 router is pretty busy/saturated then you have two options , upgrade hardware to support both IPv4 and IPv6 - - - or - - - add additional IPv6 only hardware next to your existing IPv4 hardware. There are pros and cons of both methods.

Edit: Also , IPv6 traffic through the Internet may use different paths (hops) through the Internet verses IPv4 paths (hops). Thus IPv6 traffic has a high possibility of going through totally physically different routers/switches/networks that IPv4 traffic goes through.

In answer to your question - I suspect it simply comes down to what method each Internet hop and built and how busy each device is.

North Idaho Tom Jones

btest server managed by North Idaho Tom Jones
Upgraded from ver 6.45.2 to newer ver 6.45.3 (upgraded a few minutes ago)

Hey Tom,
I can't connect to 207.32.194.24
Is it up?

I have a feeling my public got accidentally put on a ban list. I can ping it from a different connection.
Can you please see if 173.27.22.214 got put on a block list?

Tom, did you ever get to fixing the speed test server?

Having a similar issue on my CCR and it only works after a reboot for a while.

Says "connecting" "disconnected" whenever I try testing.

Hi,

Are others having issues with tcp based testing? My udp tests are fine but tcp getting zero throughput.

A

FYI - re: TCP testing. I believe this is a config issue for Tom's server as I just tested successfully using TCP using Martooo's public server.

I confirm issues with BW testing server; TCP test doesn't connect at all, and UDP connects, but doesn't show let anything through.

North Idaho Tom Jones - Public btest server

Sorry about not responding to some of the posts here. I've been busy on some ISP/WISP/networking projects.

FYI - I just now ( September 13th 2019 ) updated the btest server from ROS version 6.45.3 to version 6.45.6

I also cleared out some of the btest Address-Lists ( this list auto populates when you perform a btest and is supposed to auto-unpopulated after a time-out period and elapsed )


North Idaho Tom Jones

I can confirm post upgrade the server is working again for both TCP and UDP traffic

A

Just checked 09/19/2019
This Mikrotik forum topic "Public-Mikrotik-Bandwidth-Test-Server(s)" has 408,463 Views

Soooo, do I win a free cup of coffee when it hits 1/2 million views ?

North Idaho Tom Jones

Great idea if You have a good infrastructure and inet line! Thank You!
I was always wondering why MikroTik didn't do that with few bunch of load balanced servers.
I will test it in the evening CET.

Poslano sa mog Mi-4c koristeći Tapatalk

- Sustained traffic is limited to 100 Meg up/down (after about 30 to 60 seconds)

This btest server was not designed or intended for any sustained continuous long-running btest(s). A firewall rule will kick in to prevent saturation of my ISP/WISP bandwidth.

Please only perform brief btest(s) to measure your peak Up/Down traffic.
Normally peak btest measurements can be performed in under 20 seconds.

North Idaho Tom Jones

Thank you friend for this resource i wish you the best of luck!, please tell me, still is working! , nowdays!
kindly regards from Ecuador-SouthAmerica

Thank you friend for this resource i wish you the best of luck!, please tell me, still is working! , nowdays!
kindly regards from Ecuador-SouthAmerica

Hello to South America

I currently have the btest server off-line.
I am doing some server updates on my network.
It should be back on-line in a couple of hours.

North Idaho Tom Jones

...
I would like to ask for some feedback if you don't mind …
--- Who and where-are-you to those who use the btest server ?
--- Does the new IPv6 btest address appear to be working correctly ?
--- And comments are always welcome ……

North Idaho Tom Jones

Hi Tom,
From South Africa, I make use of this service every now and then (once or twice a week), typically when a customer says he is not getting full speed.
Currently only use IPv4 for testing
Thank you

...
I would like to ask for some feedback if you don't mind …
--- Who and where-are-you to those who use the btest server ?
--- Does the new IPv6 btest address appear to be working correctly ?
--- And comments are always welcome ……

North Idaho Tom Jones

Hi Tom,
From South Africa, I make use of this service every now and then (once or twice a week), typically when a customer says he is not getting full speed.
Currently only use IPv4 for testing
Thank you

Hello CZFan
That's what my public btest server is for
Happy btest-ing

Just now updated the public access btest server from "Installed Version 6.45.6" to "Latest Version 6.45.7"

Happy btest (ing)

North Idaho Tom Jones

I have tried to check btest but it was not connecting?

The btest server 207.32.194.24 is now also IPv6
IPv4 address: 207.32.194.24
IPv6 address: 2605:4e40:0:1fe::
user: btest
password: btest

Tested, not connecting. Can't find any working public server on this forum.

Is this thread and its usefulness fully dead?

Is this thread and its usefulness fully dead?

This is an active thread.
The btest server is normally running 24 hours a day 7 days a week 365 days a year
The btest server is running right now. I just checked it.

If you are unable to connect to the btest server ..
- wait a few hours
- after waiting , try performing a 30 second btest
- If you are still unable to connect to the btest with the server , then check your firewalls. The btest server only has one firewall configuration which makes recent remote btest-ers have to wait until they can btest again.
--- Are you testing from behind a firewall ?
--- Is your Mikrotik a firewall ?

North Idaho Tom Jones

Hello team,

Any chance there is a 10G btest server out there I could use for a quick bandwidth test?

It would be a one time thing, I have recently upgraded my home fiber connection to a 10G one, just trying to push it all the way to make sure the ISP is really delivering.

Here are the latest test results I achieve with the current btest server mentioned in the first post (Thank you @TomjNorthIdao!).
Best regards

Hello team,

Any chance there is a 10G btest server out there I could use for a quick bandwidth test?

It would be a one time thing, I have recently upgraded my home fiber connection to a 10G one, just trying to push it all the way to make sure the ISP is really delivering.

Here are the latest test results I achieve with the current btest server mentioned in the first post (Thank you @TomjNorthIdao!).

Code: Select all

[mikrotik] > /tool bandwidth-test 207.32.194.24 user=btest password=btest direction=both            
                    ;;; results can be limited by cpu, note that traffic generation/termination 
                        performance might not be representative of forwarding performance
                status: running
              duration: 21s
            tx-current: 584.0Mbps
  tx-10-second-average: 584.2Mbps
      tx-total-average: 574.6Mbps
            rx-current: 1222.9Mbps
  rx-10-second-average: 1224.4Mbps
      rx-total-average: 1243.7Mbps
          lost-packets: 14441
           random-data: no
             direction: both
               tx-size: 1500
               rx-size: 1500
      connection-count: 20
        local-cpu-load: 23%
       remote-cpu-load: 92%

Best regards

shugnet - I wish I had the ability to briefly drop my bandwidth queues on the 207.32.194.24 public btest server. However , I do not have the extra reserve capacity to offer a btest server at anything beyond what it is already doing because as an ISP, WISP , I am already running near capacity on my Internet connection feeds.
North Idaho Tom Jones

FYI - I just upgraded the ROS firmware on the public access btest server.
It's now; 6.46

If you encounter any issues with the btest server, please post and let me/us know.

North Idaho Tom Jones

IPv4 address: 207.32.194.24
IPv6 address: 2605:4e40:0:1fe::
user: btest
password: btest

[admin@MikroTik] > /tool bandwidth-test 207.32.194.24 user=btest password=btest direction=both
status: can not connect

[admin@MikroTik] > /tool bandwidth-test 207.32.194.24 user=btest password=btest direction=both
status: can not connect

If you are unable to connect to the btest server ..
- wait a few hours
- after waiting , try performing a 30 second btest
- If you are still unable to connect to the btest with the server , then check your firewalls. The btest server only has one firewall configuration which makes recent remote btest-ers have to wait until they can btest again.
--- Are you testing from behind a firewall ?
--- Is your Mikrotik a firewall ?

WIth your IP information, I can look at my logs

North Idaho Tom Jones

Ran a btest this morning with my new ccr1036-12g-4s and reached 438 mbps of the 500 i'm paying for. Not bad!!! Thanks!!!
You provide a beautiful service to the Mikrotik community and I appreciate having a resource like this to test against from time to time.

Ran a btest this morning with my new ccr1036-12g-4s and reached 438 mbps of the 500 i'm paying for. Not bad!!! Thanks!!!
You provide a beautiful service to the Mikrotik community and I appreciate having a resource like this to test against from time to time.

Tdaddysimi - Thank you for your kind comments

North Idaho Tom Jones

Is the bandwidth test server down? The last successful test I ran from two different routers on three different WAN connections was Dec 28.

Is the bandwidth test server down? The last successful test I ran from two different routers on three different WAN connections was Dec 28.

can you ping the btest server ?

Hi all, I tried this morning a speed test but the router seem to be unable to connect ... "Connecting" is the last step i see in the process.

I'm running last Firmware 06.46.1 and Router Model :SXT R

There's some issue with server or is my side not properly working ?
Test server 207.32.194.24 is pingable but no connection from Mikrotik router test utility.

Thank you for some ideas,
Marco

Is the bandwidth test server down? The last successful test I ran from two different routers on three different WAN connections was Dec 28.

can you ping the btest server ?

Tom,

I could ping the btest server when it wasn't able to connect for the bandwidth test.

Not sure if you changed something but this morning was the first time since Dec 28 where I'm now able to successfully run bandwidth tests again.

Adam

207.32.194.24 test server may be down.

It doesn't respond to ping. Traceroute shows the last reachable hop as 207.32.194.6

Hmmm , this morning I had to reboot the btest server.

For some reason, the btest settings got un-checked ( login and service ).
I've seen this CHR based btest server do this a few times last year.


While I was at it, I upgraded from 6.46.1 to 6.46.2
Anyways, it should be running now.

North Idaho Tom Jones

Hi,
today your server not work: no ping and traceroute stop at 207.32.194.6.

The IPv4 address of my btest server is 207.32.194.24

FYI , This morning , I upgraded this CHR btest server from 6.46.2 to 6.46.3

North Idaho Tom Jones

Yes i tried right now and worked for two times: both direction and send direction.
Third time i tried with a send direction, was not work.
Now i wait a bit and i try again.

Hello,
I can't connect to your btest server...
it says connecting and after 12 seconds disconnected...

yep
207.32.194.24 down

Tuesday March 3rd 2020 at 8:50 AM PST , I updated the chr btest server from Version 6.46.3 to Version 6.46.4

North Idaho Tom Jones

Have you blocked any countries? (Iran)
Tried to connect to 207.32.194.24 but it says can't connect. Tried to ping and it returns timeouts ...

EDIT: It gets stuck at connecting for a while and then gives the can't connect error.

i want to test my 10Gb Traffic, can anyone help to provide btest server for 10Gb Traffic? need soon

Hello everyone,

I recently ordered a 10 Gbps upgrade for my WISP's primary internet circuit, but I don't believe that I am receiving the full 10 Gbps. Is there anyone with a 10 Gbps btest server who could help me out? I can provide my public IP for my btest server through other means if someone wants to swap test server information.

Excuse the double post, but after reading through this entire thread and employing some of the scripts that have already been posted. I feel relatively safe putting this out here. Please don't make me regret it.

IP: 38.104.52.187
Username: btest
Password: btest

Please let me know if you guys are able to achieve 10 Gbps symmetrical connections