Hi, i am having problems compiling BTest in CentOS
Here is my output.

[root@localhost btest-opensource]# gcc -o btest *.c -lpthread
/tmp/ccL6QCDF.o: In function test_udp_tx': btest.c:(.text+0x1455): undefined reference to clock_gettime'
btest.c:(.text+0x15dc): undefined reference to clock_nanosleep' /tmp/ccL6QCDF.o: In function test_udp_rx':
btest.c:(.text+0x16f2): undefined reference to clock_gettime' /tmp/ccL6QCDF.o: In function test_udp':
btest.c:(.text+0x1b7f): undefined reference to clock_gettime' btest.c:(.text+0x1bba): undefined reference to clock_gettime'
btest.c:(.text+0x1e92): undefined reference to clock_gettime' /tmp/ccu5j117.o: In function itimer_start':
timing_mach.c:(.text+0x20e): undefined reference to clock_gettime' /tmp/ccu5j117.o: In function itimer_step':
timing_mach.c:(.text+0x25f): undefined reference to `clock_nanosleep'
collect2: ld returned 1 exit status

What is wrong?

Thanks

I see most commits are a very long time ago, did you ever get this finished? Did you get it working? Having a btest server running on a headless linux system would be awesome! Since for some reason MikroTik does not seem to want to actually make this... (Pretty stupid if you ask me)

cmd[6:7] is a client buffer size. Maximum value for TCP is 65535 (FF:FF).
I'm currently writing a custom btest client and this value greatly affects single connection performance.

Hi, and thanks for taking the time to create this. Its saved me a bunch of time while working on some validation of a new homelab setup with a bunch of Mikrotik gear today!

While testing I ran into some weird behavior with bitrates greater than ~4.2 Gbps on a 32-bit arm7l system - a QNAP TS-431KX NAS running an Anapurna Labs AL214 quad Cortex-A15 @ 1.7 GHz CPU. However, I was able to work around this by manually setting the bandwidth to less than 4295M.

[~/btest-opensource] # ./btest -c 192.168.88.1 -t -b 4295M
Tx speed: 32704
Interval:  1:0
gettime:  13511:660314092
Remote: Seq: 2550136833, Rate: 1551.6Mb/s
Remote: Seq: 2399141890, Rate: 0.0kb/s
Remote: Seq: 2382364675, Rate: 0.0kb/s
Remote: Seq: 2399141892, Rate: 0.0kb/s
^C
[~/btest-opensource] # ./btest -c 192.168.88.1 -t -b 4294M
Tx speed: 4294000000
Interval:  0:16767
gettime:  13541:760491272
Remote: Seq: 2583691265, Rate: 4288.0Mb/s
Remote: Seq: 2684354562, Rate: 4291.9Mb/s
Remote: Seq: 2667577347, Rate: 4294.1Mb/s
Remote: Seq: 2684354564, Rate: 4294.2Mb/s
^C

Its been a long time since I've worked in C so I'm not sure I'll be able to cook up a proper PR for a fix (sorry!) but it feels like an overflow. I did take a few runs at a fix (tried moving a few things from 'lu' to 'llu', for instance) but had no success in the time I've got available today. Probably not a huge deal given that there can't be many 32-bit platforms with 5G/10G network support out there anyway.

At the very least I hope the workaround here is helpful for anyone else that's crazy enough to try using btest on a 10G-equipped 32-bit ARM platform. 😂

p.s. - To get btest working with higher bitrates I had to change the hard-coded tx_size of 1500 to match my jumbo frame MTU of 9000 to avoid choking the tx system with packet generation overhead. At 1500 the QNAP system could do about Might be worth making that a command-line option but its easy enough to just edit btest.c and recompile I guess. :)

I'm running btest -s on the server, and /tool bandwidth-test 192.0.2.1 protocol=tcp on RouterOS 6.45.8.

It connects successfully, in a packet trace I can see the client sending all the options, the server acknowleding with 01:00:00:00 - and then the client terminates the connection and prints

                status: test unsupported

A packet trace from a RouterOS bandwidth-server shows that it sends 01:XX:YY:00 instead, where XX:YY is somehow reused by the client in the newly established connections. Other than that, I was unable to see any difference.

Hi, been digging around with the bserver.pl code and decided to have a crack at UDP. I'm wondering if you have run into/got past a wierd issue. From what I can tell the UDP protocol is quite similar, however unlike TCP where the server just starts sending data down the existing connection, for UDP the server is supposed to respond with another 'hello' and then the server port number that it will send or receive the data on. This is from looking at the data traffic from a Mikrotik btest server.

However what is wierd is that the standard server then just starts sending UDP data back to the client to what appears to be just a random port around 2200. At no point from what I can see does the client tell the server what port to use. I am beginning to wonder if the only way to do this is to use pcap and filter on the source port.

Any ideas?

Damian

Hi, this was a great contribution however I couldn't get it to work:

1. Installed on Ubuntu 20.04 using
   git clone https://github.com/samm-git/btest-opensource
   cd btest-opensource
   gcc -o btest *.c -lpthread

2. ran: ./btest -s -a admin -p password

3. On the router, ran:
   /tool bandwidth-test dur=5s dir=both user=admin pass=password prot=tcp addr=10.1.0.1
   status: test unsupported
   tx-current: 0bps
   tx-10-second-average: 0bps
   tx-total-average: 0bps
   rx-current: 0bps
   rx-10-second-average: 0bps
   rx-total-average: 0bps
   random-data: no
   direction: both
   connection-count: 20
   On the linux side, the output is:
   Running in server mode
   Listening
   Cmd buffer: 01030114008000000000000000000000
   proto=1
   direction=3
   random=1
   tcp_conn_count=20
   tx_size=32768
   client_buf_size=0
   remote_tx_speed=0
   local_tx_speed=0
   remoteIP=10.1.10.33
   Listening on TCP cmdsock
   Complete

4. same results with no username/password on either end, and same results with dir=transmit or dir=receive

5. Other direction: ran ./btest -c 10.1.10.33 -r -t -a admin -p password
   Remote did not return correct hello response
   Response: 03000000
   Same result with only -r or only -t

6. Installed on a different Ubuntu 20.04 system and ran the server there (with user/password) and the client on the first Ubuntu system as: ./btest -c 10.1.13.248 -r -t -a admin -p password - that produced results as expected.
   The first time I tried with -r only I got a series of 0.00kbps. However running it later with -r -t and then -t and then -r, all three cases produced realistic bandwidths.

I am trying to test my LHG-LTE6 (RouterOS v6.46.4) against server build from latest sources (under Ubuntu 16.04.6 LTS with 'cc -o btest -pthread btest.c md5.c')

Server says
user@server:~/src/btest$ ./btest -s -u -b 0 -a btest -p btest
Running in server mode
Listening
Cmd buffer: 00030100e80300002c0100002c010000
proto=0
direction=3
random=1
tcp_conn_count=0
tx_size=1000
client_buf_size=2883584
remote_tx_speed=300
local_tx_speed=300
remoteIP=1.2.3.4
Tx speed: 300
Interval: 1:0
gettime: 1586199784:139478028
Local : Seq: 1, Rate: 0.0kb/s
Remote: Seq: 3825205249, Rate: 0.0kb/s
Local : Seq: 2, Rate: 0.0kb/s
Remote: Seq: 2852126722, Rate: 0.0kb/s
Local : Seq: 3, Rate: 0.0kb/s
Remote: Seq: 2231369731, Rate: 0.0kb/s
...
and so on, until client finishes testing

client says
[admin@MikroTik] > /tool bandwidth-test 4.3.2.1 duration=15s direction=both local-udp-tx-size=1000 protocol=udp remote-udp-tx-size=1000 user=btest password=btest local-tx-speed
=300 remote-tx-speed=300
status: done testing
duration: 15s
tx-current: 0bps
tx-10-second-average: 0bps
tx-total-average: 0bps
rx-current: 0bps
rx-10-second-average: 0bps
rx-total-average: 0bps
lost-packets: 0
random-data: no
direction: both
tx-size: 1000
rx-size: 1000
connection-count: 1
local-cpu-load: 8%

Could Mikrotik change something in testing protocols?

P.S. LHG has no fw (but I am not shure about LTE ISP), and ubuntu box was updated with 'ufw allow 2000' and 'ufw allow 2256'

Running btest for transmitting seems to max out at ~300 Mbps.

If I comment out this clock_nanosleep() call, it can get higher:

Not yet sure why it doesn't work with that, though. Doesn't depend on the Tx Speed either.

Please update readme.md with instructions how to install and run server and client