Transport for London (TFL) publishes a lot of Open Data for Public consumption about the status of the London Underground, in real time. This data is updated every 30 seconds in XML format and is mostly documented.

As a proof of concept I wanted to setup Zabbix to monitor the status of the Underground Lines and present the results on a Grafana Dashboard.

The first step was getting hold of the XML data. Unfortunately the SDK does not say what the Domain is to get the XML from. A little Googling allowed me to find the XML I needed here.

The next step was to extract the data needed from the XML. I wanted to get the name of the TFL Underground Line, It's status and a description of any issues. A simple PHP script was used to get this data, format it and use the Zabbix Sender (zabbix_sender) to post it into a Zabbix Server. I organised the Zabbix data using a Zabbix host for each one of the Lines with a few Zabbix items (which must be created as "Zabbix trapper" item type) to hold the data. The PHP script is run on a Zabbix Server (just for convenience really) under cron every 60 seconds.

Finally I created a simple Grafana Dashboard using "Status Panel" panels to show the data.

In my particular case this question relates the UniFi AP v2 but has more general implications.

One would imagine this to be a simple question to answer with a yes or no answer but not for Ubiquiti it seems.

I have been asking this question of Ubiquiti for about a month now after having problems loading OpenWRT 15.05.1 into a number of UniFi AP v2 units. The answers from Level 1 support (via their forums) has been, "It shouldn't be blocked" (hoping for a Yes or No), "It's ok in the latest release" (it wasn't), "I'll have to check with Development" (still waiting for that), "We don't support Third Party Firmware" (wasn't asking for support) or (the most honest) "I don't know". So I pressed for an answer, they escalated it to the next level but were very vague about what that meant. Oh and it seems Level 1 support at Ubiquiti have no SLA what so ever with the team they escalate to. They also have no way to communicate with them after an escalation. So the question has gone some where in Ubiquiti to be answered at some unknown time.

My own feeling is that they are avoiding answering the question as they took the excuse of the FCC rules relating to unauthorised changes to Wireless parameters that could be part of Third Party Firmware, to do this. Of course the FCC rules only applied to 5Ghz not 2.4Ghz Wireless and, as the FCC have stated, was not intended to be used as a reason for blocking Third Party Firmware. TP-Link got caught up in this too. So they cant say they are blocking.

I also think they are actively blocking. Firmware Images for the UniFi AP v2 have a different device type in their header but this is easy to cater for by either making changes in the OpenWRT firmware builder to generate a correct header (sorry not going to go into derail on that here) or by using a binary editor to change it manually. The real issue is that the Ubiquiti Firmware images have a new RSA signature section at the end. The U-Boot loader, already on the device and included in Ubiquiti Firmware updates, checks the signature and rejects images that don't have it, making TFTP updates not work. fwupdate.real used to do upgrades via the command line, also checks and rejects images without the signature giving the "Invalid FW Part 3 MAGIC 'END.'" message.

I have had some difficulty in getting BT support to understand this but lets have another go, maybe someone at BT will stop trying to find reasons why this should not even be looked at and take another look at it.

I have two HH4 ADSL routers on two separate PSTN lines. Both pretty much configured the same. They both connect to two different interfaces on a single pfSense 2.1 Server both on their respective HH4's DMZ.

Due to many problems with the lines over the last 18 months, I monitor them from a Zabbix server in the Cloud. Just a simple PING to start with. The PING hits the HH4, is passed to the DMZ and so to the pfSense Server with its Firewall configured to allow PINGs. Until a couple of days ago both were PINGing away fine then one stopped. Checking the HH4 logs I found that at the exact time the PINGs started to fail, that particular HH4 had upgraded itself from 4.7.5.1.83.8.130.1.17 to 4.7.5.1.83.8.130.1.26 (at 07:50 am on the 8th of February). Nothing else had been changed.

Rebooting the offending HH4 did not help. Even a complete configuration reset and then reconfiguring the DMZ made no difference. Leaving me with the reasonable conclusion that the new Firmware (which has also introduced IPv6 support, so not a trivial change) has broken the DMZ handling.

The other HH4, on the older Firmware is still running fine while the newer Firmware continues to block DMZ traffic.

Attempts to report this as a Firmware bug via BT Support have fallen on stoney ground. Apparently nobody has reported this issue therefore it does not exist. Great logic.

Event log: Firewall entries...

IN: BLOCK [16] Remote administration (ICMP type 8 code 0 xxx.xxx.xxx.xxx->yyy.yyy.yyy.yyy on ppp0)

ICMP Type 8 is PING, xxx.xxx.xxx.xxx is where I'm PINGing from and yyy.yyy.yyy.yyy is the Public IP for the HH4.

IN: BLOCK [16] Remote administration (TCP [xxx.xxx.xxx.xxx]:54275->[yyy.yyy.yyy.yyy]:22 on ppp0)

When I try ssh to the Public IP of the HH4.

These packets should be forwarded to the DMZ Server but they are getting blocked by the "Remote Administration" filtering rules. Looks like "Remote Administration" filtering is now being done BEFORE DMZ rules. That would be a bad thing!

Oh and if someone from BT Support does read this, PLEASE focus on the Firmware issue and don't tell me that as pfSense is OpenBSD which is a Linux based Operating System, that you don't support it. I'm not asking you to "support" it, just to look at the real problem. Also, you don't need to point me to articles on setting up a DMZ or Port Forwarding, that's not the issue. Thanks.

Go on BT prove me wrong or fix it.

Update - 1st of March - BT continue to scratch their heads over this and my second HH4 has now picked up the new Firmware and has the same problem.

=======

And the answer is....

Sagem have introduced an interesting little "improvement" in the new firmware. If your HH4 uses the internal DHCP Server (as is the default) to hand out the IP address to your DMZ Server then despite the fact that the HH4's own internal DHCP server knows the IP that was handed out, the HH4 now does a DNS lookup based on the host name that your DMZ Server provides during it's DHCP request to get the IP address in the first place, as the DNS host name to find the IP. If your DMZ Server's host name is more that a single level name (has a dot in it), then the HH4 does the DNS lookup back over the Internet via BT's DNS Server, which will never work.

Apparently this is "working as designed" so a work around is needed....

1) Don't use DHCP to get the DMZ IP, use a static IP address.

2) (If your DMZ Server supports this) Only pass a single level host name in the DHCP request.