2017-06-20

NBN: The Somewhat Expected Journey

In the beginning

About three and a half years ago I was planning on purchasing a house with my then-girlfriend and choose a location that was earmarked to get Fibre to the Premise (FttP) National Broadband Network (NBN)​ with a three year build date. Within a few months of settlement an election was called and my location was wiped off the NBN map completely.

Three years on and I receive an email from my ISP advising that HFC is going to be available. Then junkmail in the mailbox with offers from one random unknown and a couple of known much disliked Retail Service Providers (RSP) - in the NBN world, they are now referred to as Retail Service Providers (RSP) and formally known as Internet Service Provider (ISP). Yes there is a difference.

The only thing that I think our government may have managed to achieve with their three words slogan for NBN during their campaigning is simply "cheaper" They appear to failed on the "faster" and "sooner" parts.

Back on track with the story, I jumped at the RSP email and decided to 'pre-order' my NBN (which turned out to be a mistake) as I learned from an NBN representative that that a pre-order is actually a new order and would have created a whole new account not linked or related to my existing, long tenure one, which I want to keep at least until the day I decide to switch to a new RSP. But that's not all I learned, just not from my RSP.

Curse of the cabling

Not only did I not realise that there was an existing Telstra cable/Foxtel box out the front of the house from a previous owner/residents installation, but it was in an inconvenient location and I needed to remediate the coax cabling before the NBN appointment (to install the Network Termination Device (NTD) - otherwise known as an NBN "Connection Box".

So in preparation for the NBN appointment, I decide to cancel the NBN order (also under advise by the RSP), except I wasn't quick enough to cancel the router that was immediately sent out. No biggie. It only cost $10 to have it sent to me.

So that brings me to the next part. The cabling. I forgot about the existing Telstra cable box at the front of the house outside, but since there was also foxtel dish on the roof (I actually thought the foxtel dish was the source of the cabling point), so I decided to remove the foxtel dish, but not before a trip to Bunnings to get two blank wall plates so that I could make it appear as though nothing was cabled or points inside the house, whereby upon removing said dish, I discovered that the dishes cable didn't actually go to the wall point I expected, but I continued to remove it anyway, putting aside the dish, mounting bracket and cable once removed.

I then located the actual coax cable drop (after realising/remembering about the cable box out front. Derp) and proceeded to pull that across to the (new) location where I wanted it. At this point I realised I had to go to Bunnings again, this time for an electrical snake, electrical tape, 16mm masonry drill bit and a new coax f-type wall plate.

Thinking that I had everything I needed, I tidied up the wall plates from the previous coax cable points and started to painstaking pull the existing cable through the roof eves trying to keep minimal turns to maximise length only to find out that the cable still fell short of approximately three metres. Being the engineer that I am, I saved myself I some money by reusing the cable from the foxtel dish I removed earlier and joined the coax with a connector salvaged from a removed f-type wall plate. Brilliant!

So after wrapping the join with a generous amount of electrical tape, there was more than enough length for the cable to reach the new wall point, for which was not as straight forward as just drilling a forty five degree hole to the wall cavity as I managed to loose the coax connector after I managed to get the snake and cable wedged in the bend of the newly drilled hole thinking I could stupidly un-wedge it by pulling harder on the snake then on the actual cable (minus the connector) and then on the snake again - finally dislodging the snake (minus the connector - which now lives somewhere inside the cavity walls). All this only because I mistakenly taped the coax cable and it's connector to the top of the snake instead of the bottom to allow it to go around the the bend of the newly drilled hole for the wall plate. Lesson learned.

Once I had the coax pulled through, I went off to Jaycar this time to get the replacement F-type connector (including a spare in case I borked it), but quickly realised that they were for a coax cable with a smaller core, so after yet another trip to Bunnings for the correct F-type connector, I got the wall plates finished and titles put back on the roof. Lucky for me I didn't break any tiles during the walking about on the roof!

Order in the court!

After all the saga of cabling was completed, I contacted my RSP and requested a new NBN order, this time under my existing account. So far so good except I receive another email telling me a router is being delivered. Again.

The next day I contact my RSP via reply email for the hardware order asking to cancel it. No response. I call them the following day to cancel it. They tell me there is no evidence of any charge but by that time I already have an email telling me it's been dispatched and on its way (It arrived the next day shoved into the mailbox, whereas the previous one I had to sign for at the local post office).

At this point the NBN appointment to install the NTD had also been brought forward but in the meantime I decided to break open the HG659b since I had two of them, so one of them was doomed to become my sacrificial test unit (read on to find out how/why).

./hack

Hacking the sacrificial unit involved soldering header pins to the empty holes where a serial port has been identified thanks to an openwrt hardware wiki article on it. De-soldering the factory solder points to put the header pins took far longer than actually soldering on the header pins though.

Having access to the serial port it was easy to get into the Common Firmware Environment (CFE) by interrupting the boot sequence so that I could flash spark (NZ) firmware onto this unit as it was more likely to include the download configuration file exploit not available in the crippled TPG firmware.

After doing the configuration file download exploit on the sacrificial unit with alternative firmware, I decrypted the configuration file with the help of a whirlpool knowledge article, and then the root password from the modified unit, I was then able to successfully use those credentials to log into the unmodified unit with normal, unadulterated, uncripled access.

With noob access defeated, I quickly discovered that not only does the unit only allow static routes, on the WAN interfaces but it is very picky about its LAN management IP address and subnet mask. According to the admin UI, apparently 192.168.2.1/24 is invalid and the Command Line Interface (CLI) over telnet is cripled and you cannot get a shell whatsoever. By this stage you can probably imagine the eyetwitch starting.

By now, it was blindingly clear that the HG659b is complete rubbish (ESPECIALLY WITH TPGs CRIPLED FIRMWARE!) - even more so for a network engineer such as myself.

In between all this, the NBN contractors had attended the premises (at the very end of the appointment window no less) to install the NTD (yes, it took two of them) and found the existing Telstra cable to have no signal! Thinking that it was my fault, I simply explained that I "had the the wall point moved". They then opened up the telstra cable box out front and not only found two cables coming from it but one of them was not connected - which was obviously the one I had remediated. They switched the cabling and the line had signal and they where able to activate it. By now one of the NBN contractors - what looked like the junior of the two - had left. The NBN contractor then used the excuse that his phone battery was flat so that he didn't have to wait around for the half an hour for confirmation of the service being activated. I wonder where the other cable leads to then?

MOAR HARDWARE!

Knowing that the HG659 is completely useless to me for my requirements, I dug around for an OpenWRT compatible router (not an AP and ADSL and everything all-in-one-gateway-that-everyone-calls-a-damn-router!) and settled on a MikroTik RouterBoard RB750GL from WISP - these guys have a questionable website security wise (certificate is fine but pages may include a form(s) with a non-secure "action" attribute.) but they shipped this thing in record time!

With the new router in hand I took a quick look at the very ugly UI for RouterOS and promptly installed OpenWRT on it using a combination OpenWRT installation methods from both the device page and the general common procedures (the latter of which mentions the missing initrd).

Before I got it off the default IP address (and adding a static summary route for all my subnets), I realised was getting annoyed at this point having to deal with equipment which ships with IP addresses which conflict with my own network, so I decided to change my Local Area Network (LAN) subnet to something more sane, which took about three hours of solid uninterrupted work to migrate configuration to a previously unused Cisco 48 port PoE switch (some things are outstanding but I can defer those for another time).

Lastly, I added a new PPPoE connection to the the port already tagging on VLAN ID 2 and viola! I'm connected to the NBN with a device which I have much more trust and configuration options. Even the default firewall rules where reasonable.

Summary

I have learned a few things these last few weeks: how to save some money, how not chase a cable through a wall and not to necessarily jump onto something no matter how exiting it seems and could help with working from home and studying in the future but even more recently, how NBN HFC is delivered and more recently, how important security is with the NBN (more on this in a new post hopefully).

It has been an interesting journey and the thing I enjoyed the most about this was the hardware hacking (however futile it was) and the handyman type work (drilling holes chasing cables etc). What I least enjoyed was the level of service from my RSP and the fact that they managed to bork the username on the account, but all-in-all the actual throughput/bandwidth of the service seems reasonable for now and by the time you read this, I will probably have shut down my ADSL service.

The funniest thing about all this all is the fact that the wife hasn't noticed the improvement in speeds, since I told her (and she agreed) to the experiment of not telling her when it was actually done!

Oh and NBN sent a survey asking about how likely I was to recommend NBN, based on the "excellent" service I received with a scale of 1-10, only to tell me that I had to choose 4 or higher. Go figure.


If you have read this far, thanks for reading and feel free to share your experience with me by posting in the comments or via Google+ (link to post is best).

2015-09-03

BIND (named) server remidiation [part 2]

Following up from my previous post (BIND (named) server remidiation), I spent a good couple hours further developing and testing the configuration but failing to get a bind9 reverse lookup zone to load only to find out that I had a slight typo in the reverse lookup zone definition

named-checkzone was returning OK, but named itself was failing to load the zone file with the error:

zone X.X.X.in.addr.arpa/IN: has 0 SOA records
zone X.X.X.in.addr.arpa/IN: has no NS records
zone X.X.X.in.addr.arpa/IN: not loaded due to errors.

It wasn't until I had a friend take a closer look at then the problem became clear:

I defined the zone as .in.addr.arpa instead of .in-addr.arpa in the named.conf include file which references the zone file.

Some things I have learned is:

  • Check the logs (in my case, on a default debian/bind9 install this was /var/log/syslog) when things don't work.
  • Always check your config with the bind DNS tools before reloading
  • Always check your zones files with the bind DNS tools before reloading
  • Keep zone files neat and group together similar resource record types.

Now that I have the dev domain DNS working, I just need to look at setting up DHCP and testing dynamic DNS.

I also considered moving different resource records for each zone into a separate file, but this is not necessary, due to the (current) size of the network.

Once this is all done, tested and implemented in 'production', I will also consider keeping a similar configuration in dev as a slave for all zones from the primary DNS or just as it is and just for testing.

2015-08-26

BIND (named) server remidiation

Since I virtualised my old failing physical server into a VM, I have found it less and less easy to administer and maintain (read: configuration files).

So, I am looking and spinning up new Debian servers for more specific tasks, network services, games servers, file services etc.

The fist, and most important thing I need to migrate is DNS. That way I can have it simply running in parallel with the old, ready to essentially, stop the service (after making sure DHCP serves out this DNS IP address as well of course!).

Now, here comes the "clever" part or the goals of this approach (or so I thought):

  1. Install named.
  2. Configure it to be a slave for the existing zones
  3. re-configure it to be a master (complete with zone files)

Pretty simple right? Not so much. Well, thanks be to the 'Debian' way of doing things, it was very quick and easy to have a the zones slaved, but when I went to look at the files I was expecting, they where still empty, since I had created empty zone files to begin with.

Some poking around later and I discover that it is transferring the zones fine, but there was an issue with permissions for the zone files, or more specifically, the directory where they lived. A quick chmod -R 0777 /zone/file/directory later and a restart of the service, voila! Except.... something was not right...

The zone files seemed to be in a binary format as file would have me believe they were of type: data

I could have converted them back to plain text using the bind-tool named-compilezone(8) but, I couldn't commit my time to learning how to get the syntax correct for one small job, besides I learned that it is a crazy default in order to get a performance increase, however minuscule that would be given such a small DNS server implementation (for now).

So as per the article "Bind 9.9 – Binary DNS Slave file format" (linked above) or more authoratively as per the Chapter 6. BIND 9 Configuration Reference section of the BIND 9.9 Administrator Reference Manual (ARM) which states (incorrectly):

masterfile-format
Specifies the file format of zone files (see the section called “Additional File Formats”). The default value is text, which is the standard textual representation, except for slave zones, in which the default value is raw. Files in other formats than text are typically expected to be generated by the named-compilezone tool, or dumped by named.

So, knowing this I edited /etc/bind/named.conf.options to include the following:

masterfile-format text;

Perfect. (Just like me ;-) I now have a duplicate of the zones served on the master server, which can, and will soon be decommissioned, not to mention the new servers zones getting a makeover with many many more zones as well as a dynamic-update zone - more to come on this soon.

2015-08-05

Great Success

Finally after weeks, no months of agonising failure though trial and error, I finally managed to get the outcome I desired with my Raspberry Pi 2!



History



A few years back I acquired a Cisco 3560 and quickly realised the potential of vlans and separate subnets for the purposes of testing among other valid reasons, and came to find that the nodes on most of the vlans could not communicate with the outside world (read: internet). It was then that I realised that something was wrong...

Long story short: the Netgear DGND4000 that I own does not route/NAT anything other than its resident subnet and I sure as heck was not going to implement double NAT!




Thanks be to LIbVirt's NAT networking which gave me an interim workaround and helped confirm this.


Getting the necessary bits


NAT issues aside, I began by purchasing a second-hand Netgear DM111P v2 from some random guy on Gumtree. The ADSL Modem in itself wasn't enough because it too, seemed to suffer from the same issue as the DGND4000 did, although admittedly, I didn't put much effort into testing that theory as I wanted a solution not more testing.

I then purchased a Raspberry Pi 2 along with a bunch of accessories. In the meantime (while I was waiting the excessively long shipping time). I did some research on the distributions that are capable of running on the bcm2709-based board and decided with OpenWRT. Yes, I know that I could have used Raspbian but OpenWRT seemed the most logical choice given the fact that it is essentially an internet router anyway, just without the wireless and ADSL modem.

Turns out I made the right choice despite the fact that OpenWRT is still in trunk (RC3 at the time of writing this).

Lastly (after destroying the extremely cheap Rpi2 case) I managed to get an image booted (helps when you use the bcm2709 not the bcm2708 barrier breaker version, thats for the Raspberry Model B!).





Configuration


First of all, this would have gone a lot smother had I have just tested with the USB network adapter I bought along with the Pi, but it didn't get here in time with partial shipping.

I configured the switch with a trunk port with two vlans, one for the LAN side of things (internal link) and another for the WAN or pppoe (public/external/internets) and set the mode appropriately.

NOTE: VLANS and IP addresses have been altered so as to protect the actual configuration used in my network infrastructure. Call me paranoid.


Cisco 3650 partial configuration


!
vlan 20
vlan 69
!
interface Vlan69
 description DMZ/LAN
 ip address 192.168.69.1 255.255.255.248
 no shutdown
!
! no interface defined for WAN because we do not want any L3 traffic
!

interface GigabitEthernet0/2
 description Trunk port for Rpi2 VLAN's: 20, 69
 switchport access vlan 69
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 20,69
 switchport mode trunk
 no shutdown
!
interface GigabitEthernet0/1
 description Link to DM111Pv2 modem (bridged) for PPPoE/L2 traffic
 switchport access vlan 20
 no shutdown
exit
!
ip route 0.0.0.0 0.0.0.0 192.168.69.66
!
end


OpenWRT network configuration


root@OpenWRT# vi /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config interface 'lan'
        option proto 'static'
        option delegate '0'
        option _orig_ifname 'eth0'
        option _orig_bridge 'false'
        option ifname 'eth0.69'
        option ipaddr '192.168.69.66'
        option netmask '255.255.255.248'

config route
        option interface 'lan'
        option target '192.168.0.0'
        option netmask '255.255.0.0'
        option gateway '192.168.69.1'

config interface 'WAN'
        option proto 'pppoe'
        option ifname 'eth0.20'
        option delegate '0'
        option username 'myusername'
        option password 'mY$eCr3tP4sSw0rD'


Caveats/Adendums/Extra information


By now you may be wondering, "Why is there no IP addresses or switch virtual interface for vlan 20"? There is no need for it! That, and the fact one might only want traffic to go via one vlan and then the other (remember, this is essentially a router on a stick implementation and we want to separate the vlan's into L3 traffic for one and L2 for the other per requirements).

If you were thinking: "The netmask and destination network IP for the LAN route is wrong!", you would be incorrect. This is a perfectly legitimate summary route. It allows for much easier (read: slack) administration so one does not have to manage multiple static routes for subnets added or removed from the network (short of running a routing protocol) and it has the added benefit of consuming less memory and is a much more flexible approach for this design. Neat huh? I thought so too :-)


Conclusion


Let it be said that although this configuration is very simple, there where many hurdles accompanied by many choice words along the way. The one single most important thing that I kept getting wrong was routing. I had to remember to change the 'gateway of last resort' (Cisco's way of saying default route) on the switch so that all the subnets will route to the internet and the static (summarised) route for traffic to get back into the network from whence they came. That and trying to test this when the internet is depended upon so much by the two people in this household, was frustrating as my change windows where often short and had to be rolled back constantly.

Lastly, I must say that "out-of-the-box" pppoe/nat/routing on OpenWRT worked with like a charm with minimal configuration, however I will need to develop the scenario a little further so I can secure the connection by way of its firewall (read: iptables), but that itself is a beast I have yet to conquer.


2015-08-04

Rasbpberri Pi Internet Connectivity Lab

I have successfully built a lab for testing internet connectivity to the Raspberry Pi 2, by using my phone in a USB tethering configuration.

I followed the majority of the configuration listed in the OpenWRT wiki, except I used the LuCI web configuration instead of the final manual step of using uci to use usb0 as the WAN connection

This will now allow me to test various scenarios including multiple default routes with different metrics as well as testing firewall configurations using OpenWRT running on the Rpi2.

The one gotcha is that I forgot to set the rout back to the internal network for which was previously miss-configured.

I am getting one step closer to having much more control of my internet as well as being able to NET/Route all of my subnets!

2015-07-25

failure to focus

I have confirmed that I can get the Raspberry Pi to connect to the ISP using PPPoE through a VLAN, however, I cannot (or rather my brain cannot) get the OpenWrt to accept traffic other then ICMP to/from the device itself (I probably need to understand iptables or I am overlooking something very simple).

I'm finding it extremely hard to focus and get the networking part of this lab working right now when I don't actually have a lab to do it on and when others in the household rely on internet so much including myself, when I need to refer to something while trying to troubleshoot and find a solution to this 'router-on-a-stick' model of networking to overcome the shortfall of the existing router.

I've also lost my 4Gb micro SD for which I was planning using for building a Bluetooth (A2DP) Audio receiver from the Raspberri Pi which is making me a little less than happy considering they are not as easy to come by due to the size and I will have to spend another $10 (effectively $20 now) in order to get one.

For now, I'm going to go watch something and try again later (including looking for the SD card).

 
Google+