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..