Josh

@zero_effect I know this is over a year old, but will you make a new version with this fix? 1.0.5 is throwing the make_shared error when trying to compile on CentOS 7, or Amazon Linux 2. When pulling the latest code via hg, the error is gone because of the fix. I prefer to lockdown our RCDCap versions, however the workaround is to pull using hq.

Robert, this is the discussion that was supposed to be posted, not the mtr question. Sorry about the mixup. Server and Client OS and iperf versions Linux - iperf version 2.0.12 (25 June 2018) pthreads I have been looking into the use of dualtest to test server -> client throughput (using reverse tells me it's not supported yet). With dualtest and a NAT device or security device in the path, is the assumption that the incoming connection to the client's port must be forwarded and or allowed? The connection...

Ugh, I am sorry Robert. I posted, even made an edit, in the wrong window. This shouldn't have been posted here. Please, if you are able, delete this topic from your discussions. Again, my apologies.

When I run the following command, mtr -4bj -c 5 -G 1 x.x.x.x, "hubs" value appears to be incorrect. I would assume an empty list should be referenced as open and closed brackets [], not an open bracket [. The situation is occurring when the endpoint is not available. Linux / mtr 0.91.1-4c982 [user]# mtr -4bj -c 5 -G 1 x.x.x.x { "report": { "mtr": { "src": "y.y.y.y", "dst": "x.x.x.x", "tos": "0x0", "psize": "64", "bitpattern": "0x00", "tests": "5" }, "hubs": [ } } The following looks correct when...

When I run the following command, mtr -4bj -c 5 -G 1 x.x.x.x, "hubs" value appears to be incorrect. I would assume an empty list should be referenced as open and closed brackets [], not an open bracket [. The situation is occurring when the endpoint is not available. [user]# mtr -4bj -c 5 -G 1 x.x.x.x { "report": { "mtr": { "src": "y.y.y.y", "dst": "x.x.x.x", "tos": "0x0", "psize": "64", "bitpattern": "0x00", "tests": "5" }, "hubs": [ } } The following looks correct when the endpoint is available....

The recent commit adding the header codecvt is causing make to fail. I am creating a RPM using cmake. In my logs, I now get: "/usr/local/src/rcdcap/source/src/rcdcap-main.cc:40:19: fatal error: codecvt: No such file or directory", " #include <codecvt>", gcc version 4.8.5-11 libstdc++48-4.8.5-11 package is installed. I think the version is 3.4.22 but I am not 100% cmake version 2.8.12.2 I've read the recommended approach is to use boost locale instead of codecvt, however I believe that is up to you...

The recent commit adding the header codecvt is causing make to fail. I am creating a RPM using cmake. In my logs, I now get: "/usr/local/src/rcdcap/source/src/rcdcap-main.cc:40:19: fatal error: codecvt: No such file or directory", " #include <codecvt>", gcc version 4.8.5-11 libstdc++48-4.8.5-11 package is installed. I think the version is 3.4.22 but I am not 100% cmake version 2.8.12.2 I've read the recommended approach is to use boost locale instead of codecvt, however I believe that is up to you...

The recent commit adding the header codecvt is causing make to fail. I am creating a RPM using cmake. In my logs, I now get: "/usr/local/src/rcdcap/source/src/rcdcap-main.cc:40:19: fatal error: codecvt: No such file or directory", " #include <codecvt>", gcc version 4.8.5-11 libstdc++-static44 is the installed package. I think the version is 3.4.22 cmake version 2.8.12.2 I've read the recommended approach is to use boost locale instead of codecvt, however I believe that is up to you to implement....