Following on from the Virgin Media street cab article, I came across a PCP last week with the doors left unlocked (and wide open to the elements!) I phoned it in to Openreach and it's already fixed, but as I had my camera...
This is a 'vintage' BT street cabinet, so no FTTC VDSL equipment. Still hoping to grab some close-up snaps of one of those, though given the cost of equipment in them I doubt I'd find an open one which wasn't vandalised. Who knows...
Some photos for your nerdy enjoyment:
A bit of a lacklustre attempt here from their IT department. It doesn't even finish its sentence, perhaps meaning it goes on for ever and ever without end
This e-mail contains confidential information and is for the exclusive use of the addressee/s. If you are not the addressee, then any distribution, copying or use of this e-mail is prohibited. If received in error, please advise the sender and delete it immediately. We accept no liability for any loss or damage suffered by any person arising from use of this e-mail
Stupid Email Disclaimers makes its glorious return! And never mind that this is legalese nonsense, it's still not enforceable. (This instalment courtesy of QIT Labs.)
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
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...