(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 look after a few email servers and after implementing much stricter encryption settings at the start of the year, I noticed some emails were never making it to accounts - being rejected at the negotiation stage (where the remote server sending the email agrees an encryption protocol and cipher with the local server).
I was puzzled by this. TLS is hardly new, yet these servers were only ever attempting to use SSLv3 and then failing to 'upgrade' to TLS - not even TLS1.0. Poor show.
This isn't unique either - I periodically run a script which reports the spread of protocols and ciphers of incoming email connections; here's a sample from one server for the last hour...
...The stats don't make for pretty reading:
I noticed recently that a few web sites are miscategorising my ISP's static IP as being in the wrong country. I knew it was a recent reallocation of a new block and suspected the web sites were using a stale version of a GeoIP database - probably MaxMind's GeoLite v1 offering.
If you see stuff like this while surfing the web, your IP is probably in the same boat:
It's such a stupid problem, but it's all due to lazy server admins or designers
I've been working with Oracle Session Border Controllers and Enterprise Communications Brokers a lot recently, A couple of weeks ago I encountered what I think is a new - and quite serious - bug (it's with Oracle for investigation) regarding how the devices *mis*handle special characters. If you admin ECBs or SBCs and are planning to change their credentials to include non-alphanumeric characters, read this first.
I've been working with Oracle Session Border Controllers and Enterprise Communications Brokers a lot recently, and I encountered what I think is a new bug (it's with Oracle for investigation).
After deploying some new ECB instances, I changed the login and enable passwords, per the Oracle ACLI guide ("secret login" and "secret enable" at the SSH prompt). I used randomly generated strong passwords which included limited special characters -- "#", "%", "?" and "!".
The ECB appliances use two passwords per username - one to log on to the unit, and one to 'enable' (admin mode for configuring them, similar to Cisco's enable mode).
On one appliance, the new password I generated for it was accepted without complaint when typed and retyped at the confirmation prompt. However, attempting to then authenticate a new session using this password resulted in immediate refusal by the appliance. It effectively denied access, with no recovery method. I had to flatten and redeploy the appliance! Continue reading "Tiplet: DO NOT USE the # symbol in Oracle Enterprise Communication Broker passwords!"