iperf3 is a very useful network throughput testing tool, however the most prominent versions available for Windows are either old, buggy or superceded by newer builds. It's always worth keeping up to date with the latest available build, but most people on Windows won't be able to compile from source due to lack of knowledge/lack of time.
The ESNet project maintains iperf3 but doesn't release compiled binaries for Windows. Sites like the high-visibility iperf.fr only host up to v3.1.3 which dates back to 2016 - six years old as of writing, and the operator of that site appears to have gone AWOL or has stopped updating it.
Fortunately, the wonderful user BudMan on the Neowin forums decided to do something about this, and has been steadily compiling the latest iperf3 builds for Windows and hosting them for download since 2014! Someone should buy BudMan a beer. Another Neowin user CryptAnalyst has also recently begun compiling for Windows and is publishing builds to their GitHub. Spoiled for choice!
https://www.neowin.net/forum/topic/1234695-iperf-311-windows-build/ has the latest build linked directly, and you can download all previous releases from https://files.budman.pw.
For ease of use on the command line, don't forget to extract the zip to a 'persistent' location, then add that folder to your Windows PATH environment variable (it only takes a few seconds). Here's another guide on how to do it in Windows 10; the process is very similar for Windows 7 (see also https://stackoverflow.com/questions/23400030/windows-7-add-path).
Of course, adding the iperf3 path to your Windows PATH variable is optional, but it's convenient. Once done, you can just invoke "iperf3" from a prompt like anything else. Happy throughput testing.
I was recently modifying a Postfix config to do some debug logging of transactions for a specific IP addresses. To do this, I modified the
smtps services in
master.cf to get the most verbose logging possible.
However, I'd failed to remember to encapsulate the IPv6 address with brackets. And so, I got this in the log after restarting Postfix:
Feb 5 18:28:29 l03 postfix/smtpd: warning: 1111:2222::7777:8888 is unavailable. unsupported dictionary type: 2a04
Feb 5 18:28:29 l03 postfix/smtpd: warning: 1111:2222::7777:8888: table lookup problem
(To confuse me, that address was also the one listed in a
client_checks.cidr file I'd put together which was also part of my investigation).
And when that client was attempting to connect to send an email, I was seeing this:
Continue reading "Postfix "unavailable. unsupported dictionary type 1111" on restart? Check your brackets!"
(Grab an old sponge - yes, seriously)
I have a Canon Pixma MG5750, a Currys PC World purchase when I needed a cheap multifunction printer fast. Handy at £45 (another set of genuine ink for it costs the same, go figure). I never expected it to be perfect, I assumed it would at least be able to reliably accomplish basic things like print text onto paper.
Unfortunately, one of the fundamental printer requirements - loading its own paper during print jobs - was a little lacking with this unit. Research indicates it's sadly a common issue with this range of Canon printers.
Soon after buying mine, the paper feed (take-up of paper from the tray into the transport mechanism) started to behave irregularly. Soon after that, I ended up having to nudge each sheet of paper in to the printer, it was unable to take in paper itself. Not convenient.
I put up with this for a while but an attempt to print some documents evening pushed me into investigating. The fix, as it turns out, is really simple!
Click to read more and see photos of the paper feed roller fix
I encountered a weird problem on a Windows Server 2008 R2 install which had dual NICs on the same physical network (different subnets, DNS and gateways) - you could interrogate its SNMP agent and you wouldn't get a response even though the right community was set and you might initially see it working properly! This borkage would happen indefinitely after beginning, though punctuated with momentary spurts of correct operation (depending on which way the wind was blowing, how you looked at the box, whether you spoke softly to it...) but then arbitrarily breaking again. Intensely frustrating.
From my own analysis, as SNMP traffic is (usually) UDP, the responses were being routed through the wrong interface (Windows' SNMP agent binds automatically to all interfaces on 0.0.0.0:161 and doesn't care about interface order or metrics, even if you define custom metrics -- though you can force it by setting metrics on your connections' default gateways). The incorrectly-identified replies to SNMP requests were also being caught by the firewall (for whatever reason), even though it has the appropriate SNMP rules to allow ingress/egress traffic on UDP 161 and 162 (trap traffic).
But guess what, for once MS has actually issued a fix for this! It's on the Microsoft site via the snappily-named article "Incorrect source IP address is returned in the SNMP response in Windows 8, Windows Server 2012, Windows 7, Windows Server 2008 R2, Windows Vista, and Windows Server 2008". I've applied this to the servers I'm setting up monitoring for, and it works beautifully.
Big kudos to "mobilenow" who linked to this hotfix on the Solarwinds Thwack forum and explained the hotfix was produced after they opened a bug case after similarly trawling the net during production of their ServerSilo monitoring product. Probably worth checking them out. 🙂
Hopefully this avoids you wasting as much time as I spent trying to fix this...