Migrating away from BGP default-information originate

Background

I recently had yet another nbn unplanned outage. Now I have a GL-MT300N-V2 which I have basic config and a floating, static route on my central/downstream multilayer switch as a backup route with a worse metric than BGP, so that I can share my mobile phone's Mobile Broadband in the event that my Fortigate (FGT) can't forward default route traffic, but for some reason it was not working as expected/intended.

Problem #1 - IPTABLES default reject on FORWARD table

I did not capture the issue in detail, but it turned out that the GL-MT300N-V2 was blocking traffic in the forwarding table, changing this setting is what allowed forward traffic to pass to the MBB tether.

Problem #2 - default-information originate

The upstream BGP default route from my FGT persisted even in the event of an outage, when it should have disappeared so that the floating static route comes takes over internet forwarding (the Fortigate article linked herein explains this however this is normal BGP behaviour, but it was initially overlooked at the time of implementation. whoops!), but this was because I was using the Fortinet option 'set capability default-information-originate` in the BGP configuration, so I ended up tuning the BGP configuration and made the default route more dynamic as follows:

The solution

1. Created a DEFAULT route prefix list
2. Created a Route-map that uses the prefix list
3. Redistributed static routes into the BGP table using the route-map

It now looks something like this:

config router prefix-list

    edit "PL_DEFAULT"

        config rule

            edit 1

                set prefix 0.0.0.0 0.0.0.0

                unset ge

                unset le

            next

        end

    next

end

config router route-map

    edit "RM_DEFAULT"

        config rule

            edit 1

                set match-ip-address "PL_DEFAULT"

            next

        end

    next

end

config redistribute "static"

    set status enable

    set route-map "RM_DEFAULT"

end

I then disconnected the nbn and enabled `debug ip routing` on my switch to test the solution.

During testing and while the nbn was offline, the floating static was in place, exactly as expected:

SWITCH#show ip route | invl 0\.0\.0\.0\/0

S*    0.0.0.0/0 [254/0] via 192.168.81.1

SWITCH#

Once the nbn service was back and the upstream FGT inserted a static default, it wasn't long before I saw this the resulting debug message:

1w0d: RT: updating bgp 0.0.0.0/0 (0x0):

    via 10.8.18.1

1w0d: RT: closer admin distance for 0.0.0.0, flushing 1 routes

1w0d: RT: add 0.0.0.0/0 via 10.8.18.1, bgp metric [20/0]

1w0d: RT: default path is now 0.0.0.0 via 10.8.18.1

I followed this up with a check on the routing table, and here is the dynamic default route from an upstream ppp(oe) link in all its glory.

SWITCH#show ip route bgp | incl 0\.0\.0\.0\/0

B*    0.0.0.0/0 [20/0] via 10.8.18.1, 00:27:41

SWITCH#

Conclusion

This method provides a more elegant solution so that the backup internet solution can be leveraged with almost no touch.

In case your wondering why I use a floating static route, this is because the GL-MT300N-V2 is extremely limited in flash storage making it difficult to install and operate Quagga/FRR and I am tired of resetting the device as it has a tendency to fall over after a while which I suspect is due to lack of space.

The only possible improvement I could do right now is improving security through policy by putting the GL-MT300N-V2 behind the firewall itself, but that is a project for another day (not to mention it runs OpenWRT under the hood and has its own IPTABLES firewall anyway). I also plan to swap out the FGT for a dedicated, OPNSense appliance hosted on an SBC.

I hope this has been informative and I'd like to thank you for reading!

Stay tuned for more...

HomeLab Mk.3 - Project Closeout

From a project methodology-standpoint, I'm missing some udates since the last post, but this is because I had since entered a redundancy, had immediate funding as a result, not to mention, limitted time to kick-off, execute and deploy before securing new employment.

The whole project is now complete with a 4RU AMD Ryzen-based custom-built server runnig Debian GNU/Linux.

Some of the improvemnts that have been made so far are as follows (in no particular order);

1. Employed cryptsetup on top of software RAID
2. Purchased and installed the 4RU system into an 18RU rack
3. Installed Cockpit for easier host/hypervisor management
4. Migrated the VMs from the previous HomeLab hypervisor to the new one
5. Built a functioning eve-ng instance as a VM using nested virtualisation for network moddeling

One key compromise, was that I decided to reduce costs with memory so the hypervisor host is outfited with 64Gb instead of the maximum 192Gb of RAM. This was due to the higher than expected motherboard cost not to mention my requirements are farily low at this stage so the cost of that sort of outlay isn't justified.

In addition to the above, I've also embarked on a more secured and virtualised infrastructure by using OPNSense for PROD, DEV, (NET)LAB and DMZ networks which pretty much just stiches together and firewalls multiple isolated virtual networks inside of libvirt and peers with the multi-layer switch over a P2P L3 interface via a dot1q trunk while also advertising a summary route and accepts a default route only from upstream.

I think its a failry elegant design given my constraints and requirements but more importantly, it is a much more manageble setup now which reduces some technical debt for me. Now theres very few improvements to make even in the next iteration of the HomeLab in future, which will mostly be a hardware refresh - That and re-racking everything since the racks mounting rails needs adjusting to accomidate the 4RU server depth which was unfortunately not able to be done in time.

While I would love to share the overall design itself, it unfortunately has far too much information that is now considered somewhat confidential, but those who I trust and those who know me are always welcome to take a read (preferably onscreen) as I'm not in a position to re-write it for public consumption.

HomeLab Mk.3 - Planning Phase

Background

I kicked off my homelab refresh project not long ago, dubbed "HomeLab mk.3" as its the third iteration since circa 2010. I'm now well into the planning phase but I've found that I'm also overlapping into the procurement phase (as described herein).

So far, I've decided to replace my pre-Ryzen AMD-based full-tower hyperconverged system with another hyperconverged system, but this time it will be housed in an 18RU rack for providing a small amount of noise management, but also neaten up the office a little, which will have the added benefit of assisting in home improvement (flooring) later.

Key requirements;

1. Costs must be kept as low as possible
2. Software RAID (due to #1)
3. Hyperconverged system (due to item #1 and power constraints)
4. Nested virtulisation for EVE-NG/network modelling

Therefore based on requirements, the system (excluding the rack) will comprise of the following;

• One SSD for the hypervisor stack/host OS
• Up to six (6) 8Tb CMR disks for the storage of guests etc.
• 4RU ATX rackmount case (including rails of course) ✅
• As much memory as the mainboard allows which relates to key requirement #4

Challenges

The current challenges surrounding the build are;

1. Choice of Hypervisor (oVirt, libvirt, OpenStack, EVE-NG)
2. Choice of CPU architecture (due to key requirement #4 and likely challenge #1)
3. Possible Network re-architecture required to support the system including possible infrastructure Re-IP addressing.

Choice of Hypervisor

For item #1 the choices don't look that great, and I will probably stick with libvirt and the various virt toolsets, only because;

• oVirt appears to no longer be supported downstream by RedHat which means contributions to the upstream project (oVirt) will likely and eventually kill the project
• OpenStack is a pain to set up, even the all-in-one "packstack" which also means that could impact scalability in future if required
• EVE-NG appears to be an inappropriate choice. While it supports KVM/QEMU/qcow2 images, I'm not sure I want this as the underlying HomeLab hypervisor (unless certain constraints can be overcome - these are considered not in scope of this post).

Choice of CPU architecture

For item #2 the CPU architecture is important only because network vendor (QEMU/qcow2) images highlight strict CPU architecture requirements as being Intel-based, and AFAIK nested virtulisation requires that the guest architecture matches that of the host.

Possible Network re-architecture

Item #3 is not insurmountable, but it is still a challenge nonetheless as I'm not sure about whether I will change the Hypervisor guest networks (dev, prod, lab etc) to connect back upstream at L2 or L3.

Procurement

As I mentioned already, the project planning phase is somewhat overlapping with the procurement phase, the reason for this is so that I can not only procure certain less tech-depreciating items over time to allow project budget flexibility, but also allow a certain level of reduced risk in operation of the system:

Case in point: HDD's - I never risk buying them from the same batch in case of multiple catastrophic failures.

I've already purchased 3 HDD's, the 4RU rackmount case and rails and an 18RU rack to house the new gear along with the existing kit (switch, router and UPS).

I'll continue to procure the HDD's until I have enough to build the system then all that left is to purchase the key parts for the rack mount case/system (CPU, mainboard, memory & PSU) once CPU architecture/hypervisor testing (see Hardware selection below) and the design is complete.

Hardware selection (CPU architecture)

In order to determine whether the new system will be Intel or AMD will depend on the testing performed on my AMD Ryzen-based desktop. If EVE-NG and the required images work in nested virtualisation (and/or bare-metal) with said CPU architecture, then I will be in a good position to stick with AMD for this iteration (and likely future iterations) of the HomeLab. After all, AMD-based systems appear to have a good pricepoint which relates back to key requirement #1

Adventures in docker and portainer

Around 2007 I was gifted some old hardware which entailed an ASUS motherboard, 8Gb or RAM and an AMD CPU.

It wasn't until a few years later that I decided to build it into a home server.

There was no hardware virtualisation and either I didn't know how to do or didn't want to do software virtualisation and software RAID, instead all my services, DHCP, DNS, SAMBA, FTP etc. and I think even Plex as well (or maybe that came later) was running co-resident on a bare-metal JBOD server.

Since it was simple design, it was relatively simple to operate and maintain. I even managed to successfully P2V the server when I did a hardware refresh and it continued operating for the most part.

One day I upgraded the system and a Python-based application which catastrophically broke and I since abandoned picking it back up until recently because I discovered Docker containers.

Fast-forward to today, now I have a big proponent of my services and apps hosted in a dedicated docker-engine VM and maintenance has never been easier.

I've even learned how to share the same network namespace as other containers such as stacking a container with a VPN container and all it took was using the following in the compose file under the containers service definition:

network_mode: "container:<container>"

Which, I leaned and adapted the above from the following YouTube video:

How to route any docker container through a VPN container

Further to this my Docker engine VM is exclusively managed now using portainer.io where I can easily create and delete (and in the process upgrade) containers with ease, which means everything stays fresh and all I have to be concerned about is backing up the persistent storage!

Armed with knowledge of how docker works, I've written up slide deck on docker to help demystify docker containers and hopefully improve overall understanding for the potentially emerging DevOps capability.

juniper-nuances-part1

Once day I was relaiming an interface on my newly aquired Juniper SRX300 (yes, I managed to get one of these nice little units!) and when trying to commit, I came accross the below error, which wile it seems a little misleading, it actually gives a very good clue at the issue (which may seem cryptic to the inexperienced user).

root@srx300# set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode trunk
[edit]
root@srx300# set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members all
[edit]
root@srx300# commit check
[edit routing-instances emetric interface]
  'ge-0/0/1.0'
    Interface with 'interface-mode' is allowed only in a virtual-switch
error: configuration check-out failed: (statements constraint check failed)

In the above example, the system claims that 'the interface-mode is allowed only in a virtual-switch' however upon removing the associated interface from the routing-instance (in this case I just deleted the routing instance) and making sure that the following was in place, then commit was successful and no further errors.

[edit]
root@srx300# delete routing-instances emetric
[edit]
root@srx300# commit check
configuration check succeeds
[edit]
root@srx300# show interfaces ge-0/0/1 | display set
set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members all

So, you see the lesson here is READ the output carfeully for the clue as to why the commit is throwing an error. In my case the interface was assigned in a routing-instance and therefore mutually exclusive when the interface is a L2 trunk (highlighted text).

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).

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.

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!

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).

Xbox 1 savegames on XBOX 360

Since discovered that Burnout 3 and other Xbox 1 titles are now available through XBOX Live! games on demand, I decided to do away with disc swapping and focus my attention on purchasing games for XBOX360 and Xbox Originals online through Live!

Then it dawned on me... What about all the long and painful hours I dedicated to all those Xbox 1 Originals? Do I have to play them all over again including unlocking everything and developing perfect saves etc?

The short answer (more or less from Microsoft) is: No

The Long(er) answer is: Yes, but only with specific hardware, software and some patience (as well as unsigned savegames).


Quite a bit of research later, I discovered that it is theoretically possible as the XBOX 360 has a directory on it's HDD (Partition 3/Compatibility/Xbox1/UDATA to be precise). Besides, how else would it save normally backwards compatible game data?

So after I borrowing a Datel XPort 360 HDD adapter from an awesome friend, I was able to connect the XBOX 360 HDD onto my PC, and read (and also write to) the HDD contents within minutes, all I needed was Xport 360 Software

Next up I deleted my Halo save that I created on the XBOX360 HDD and dragged the Xbox Original savegame folder (ID: 4d530004) onto the XBOX 360 HDD disconnected it and it worked!

I then repeated this with Burnout 3 and tested it, but it failed to load save and shows Unusable in the in-game load menu for the savegam(e). Apparently this is because the savegame(s) are signed with HDD key so it will probably never work for this game *sob*

I decided to proceed with copying all my Xbox Original save games (or at least he ones I care about anyway) onto the XBOX 360 HDD, so I will update this post if and when I have the Games available to test.

iPhone battery fail

My iPhone 3GS seems to be working well but with one small problem. Battery life sux.

The stupid thing lasts anywhere from about ½ a day to about about 1 day, which doesn't seem right at all.

I had also already jailbroken the the thing within the first few weeks of owning it, but since the latest firmware (3.0.1) came out recently, I thought I would update it in the hopes that Apple had silently fixed a possible power issue and to remove any jailbreak packages that could be causing this problem. No luck here folks.

About a week later I discovered that the phone was constantly emitting RF as a cheap set of speakers that I had turned on, would pick up the RF as interference and damn was this phone was being noisy!

After calling the Virgin Mobile iPhone hotline to get some support (which still didn't help mind), I stumbled onto apple's own iPhone battery information page and went through the troubleshooting steps, I seemed to have found the answer! Push mode notification. Turning it off has quietened it and the battery bar has stopped draining quicker than a cold beer in summer.

I am happy the problem is fixed and the battery is still in reasonably good condition, but this begs the question: Why is it on by default?

10th Annual System Administrator Appreciation Day

Today marks the 10th Annual System Administrator Appreciation Day.

Treat some lonely, unforgiven and/or unloved sysadmin with a gift and/or note of appreciation today and show how much you appreciate the hard work and effort that they do (myself included).

They are usually the same people that make your internets work! so show us some love. Please.





Happy Sysadmin Day!

/respect

silence isn't golden

Not only did the internal speaker in my my old Nokia 6610i fail not long after I got it, but so too did my Openmoko Neo Freerunner (GTA-02v5) (or so it would seem)!

*Grrr*

I was testing someone else's microphone+earphone's hands-free kit on the 'moko earlier on in the day, which didn't seem to phase the device as it simply didn't work, but after putting my phone on silent a few hours later, the 'moko now has no audio output except from the headphone jack!?!

After re-installing koolu's Android (v1.0_beta7), the thing still refuses to output audio to anything but the external headphone jack and I suspect that it's either the switch pins inside the female jack are stuck or the internal speaker has broken. I am yet to boot it with 0m2008.12 via uSDHC to confirm that it's a hardware fault.

The 'moko certainly has been a very interesting device to toy around with, but it has proved to be quite troublesome, making me want an iPhone 3Gs. If I can't get the audio issue sorted out soon, I will most likely get one. Problem is trying to buy one outright as I fear that no providers will because they all seem to list plans, but fail to give full price or outright purchase details *sigh*.

UPDATE 13/07/2009 @ 15:12
The 'moko now intermittently rings, but the microphone is still muted making calls impossible.


UPDATE 14/07/2009 @ 12:38
I found out from a scumb^H^H^H^H^Hcustomer service person @ Allphones, that Apple are not allowing retailers and telcos to sell the iPhone outright because it's apparently not cost-effective for them to do so.

Lucky for me, I have a friend who is willing to sell me his 16Gb 3G one for the cost of his 3G-s upgrade.


UPDATE 21/07/2009 @ 09:42
I found the link to the Australian Apple store online and I will be using half of my tax return on buying an iPhone. *sniff* Good bye 'moko... You have served me... err... not so well... :P

internets anew

Thanks to this article I was able to transform my crappy dg632 router into a dumb modem so that I could get better control (including better security) on my internet link.

The only problems I encountered was that I found it difficult to set the router into bridged mode, but finally found the answer here. The documentation on the gentoo wiki differed slightly too, in that the iptables exported variable for the WAN interface should be ppp0 instead of eth1.

Other than that I can now enjoy a properly firewalled, dyndns capable and port-forwarding capable setup at no extra cost.

Now all I need to do is get bind, ldap and openvpn working... having all this free time without a job does have it's benefits...

moar storage

I acquired two more 1Tb HDD's effectively making my current total storage space about 4Tb.

I want to software raid my 1Tb disks, but I need a silent UPS before I can (this system sits in my room, so I don't it waking me or anyone else if the power drops during the night), so my server is going to have to stay JBOD for now *sigh*

I am also contemplating putting Vista (x64) onto my lappy to make it easier for work, but I can't bear to loose my Gentoo/KDE after all the hard work that I have done in getting it functional.

I need to make some hard decisions here...

Also, I will hopefully get around to implementing IPTABLES + bridged mode modem + pppoe on my fileserver soon :)

OPENMOKO

I have finally been able to purchase a neo freerunner from openmoko!

Due to the current market, the Australian dollar is really low compared to the US Dollar (1 USD = 1.62063 AUD). But I needed a phone real bad and I really, really really wanted this one because of it 99% open (as in open source) nature.

I'm preparing for the arrival of it by purchasing a 16Gb microSDHC card (as well as the fact that I have dfu-util installed from a gentoo overlay from some time ago).

I'm considering putting Debian onto an SD card for uBoot... maybe a little too nerdy but hey, I didn't buy this thing as a fashion accessory :P


UPDATE 13/11/2008 @ 16:01
Today I discovered a nifty hardware feature. The hone can operate without it's battery as long as it's plugged in via it's USB cable!!! See here

Also, I managed to get host USB working the other day too.

Due to the available distributions it's very hard to find one and stick with it as some have feature and/or bugs that other do/don't have. FDOM sounds like it's for me though.

There is nothing this phone can't do (that which I need it to) :D

bubs is dead

My server (named bubs after the homestarruner character of the same name) died today after a power spike/power outage.

I'm not sure if bubs actually caused the outage, but one thing is for sure: It ain't turning back on.

My initial thoughts are that the power supply was damaged in the surge, but until I can get a reliable unit to test it with, I won't know for sure.

I have an old PSU from a PII computer but I doubt that will work on an amd64-based motherboard.

I just prey that the motherboard is ok becase it's going to get expensive to rebuild with new parts...

Might need to overnight some parts (or at lease a PSU)...


UPDATE 06/09/2008 @ 14:36
Bubs is back online!
Seems that all I should have done is removed it from power for a few minutes, toggle the (PSU) switch, apply power and hit the machines power button.

Also a quick test proved that an old PII/PIII ATX PSU is capable of powering an ASUS A8V board. Who would have thought :P

openmoko freerunner units

Since one of my geek tech friend's has introduced me to the openmoko FreeRunner I have been wanting to purchase one, but unfortunately they sold out before I could place an order. They have been OUT OF STOCK since early July (7/8 July maybe... can't remember) and their webstore says that the "next batch of shipments are scheduled to arrive on July 25th", problem is it's 5-day past that initial notice and no word of any kind has surfaced as to the availability of these units...

I DON'T want an iTurd but I really need a new phone... I did read somewhere that the company is operating like an open source project, so perhaps they are emulating delays and lack of communication that is normally haunted by most open-source software projects? :P

2Tb of goodness

So I finally shelled out (about ~$400+) for some more storage capacity (2 x 1Tb WD HDD). I was planning on buying a brand new fileserver ($2.5K worth) and doing software raid across them, but due to the cost of recovering from the car incident, I decided to do this on the cheap (JBOB). So now I have about 2Tb of storage at my disposal until I can afford the 10Tb fileserver (RAID6) *grin*

Mouse Rage

So I finally "spat the dummy" and had a bit of a rage and killed my Logitech G7 mouse because it kept on randomly stopping (mouse pointer kept freezing for short periods of time). I slammed it a little too hard onto the mouse pad, causing it to stop responding. Indefinitely. Oh well. Now I have a replacement Logitech MX400 and hopefully, this one will survive more than 5 months :P