Archive for April 15, 2009

troy | April 15, 2009
6 comments

Lacie admits to not truly supporting AFP

After purchasing several Lacie 2Big drives and installing them at client sites, we were disappointed to find that although they had advertised support for the Apple Filing Protocol (AFP) it did not actually work.
The simple act of trying to read and write to the drive at the same time, for example copying a file from one share to another, forces the AFP server to fail, and in most cases writes corrupt .DS_Store, .AppleDB, .AppleDesktop and .AppleDouble files, causing the file server to be inoperable even after a reboot.
Once these files / directories have corrupt contents – the only way to salvage the drive is to disable the AFP server, FTP in to the drive and remove them completely from all affected shares. I have found that just removing them from the root does not always resolve the problem, and they any affected sub directories will also need to have them removed.
For the most part, the removal of these files is fine, and will not affect your operation. However, if you are using file forks – all this information will be lost and you may be left with an unserviceable collection of files.
Given a little forum hunting, it is very disappointing to find that this seems to have been a problem with Lacie Network Drives for quite a time.
After providing a great amount of information to Lacie – their support response has been

R&D have been able to replicate the problem and are currently working on a fix for this, in the meantime the suggested work around is to use the SMB protocol. At this stage I do not have an ETA for the release…

Whilst it is fine to suggest the use of the Server Message Block (SMB) protocol (also sometimes referred to as SAMBA) in our case (and I am sure many others) this is not appropriate. The availability of a working AFP server was the primary reason for the selection of this product. If our clients had of just wanted a generic SMB share, we could have chosen any one of significantly cheaper Network Attached Storage (NAS) devices.
At this point I have only been able to confirm this fault on the 1TB and 2TB 2Big Network devices, but I am very keen to hear from you if you have any other NAS device that advertises AFP support, but fails to deliver.
I have asked Lacie to have this issue resolved within five working days, and after that time will hand my findings over to the Office of Fair Trade in Queensland and New South Wales given that Lacie are misrepresenting the capabilities of their devices.

Category: information technology, rants, work |
troy | April 8, 2009
No comments

Qantas Looses a Pet

I have written a few entries about the abhorrently poor customer service that Qantas offers before.
On this occasion I am amazed at just how bad Qantas can get when it comes to looking after their customers.
My sister flew to Brisbane last night for the April holiday. She has a small dog that obviously had to fly up with her. Under Qantas’ new “easier” baggage allowances, pets are immediately charged as excess baggage. So her very small dog cost about $110.
After her flight was delayed by about two hours, she finally left for her journey home, arriving around midnight.
When she went to retrieve her dog, she found that he was not there and had been “lost” (direct quote from Qantas staff).
After some investigation, it was found that for some reason her dog had been sent to Adelaide. It’s understandable for a bag or two to go missing, but a living pet?
To add insult to injury, Qantas does not have any real provisions in place to manage this sort of situation. So all they could do was offer the dog some water, and a brief walk in the warehouse that he was to be housed in overnight.
Given the personality of my sisters dog, I can quite confidently say that by now this morning he will be exceptionally traumatised.
Qantas has offered nothing in compensation, and disappointingly they are not compelled to by law. And again, Qantas staff have hidden behind the “we only take complaints in writing”.

Category: blogging |
troy | April 4, 2009
2 comments

Sending HTTP Traffic out an alternate interface

If you have multiple interfaces on a router, and want to send (for example) your web traffic (HTTP/80 and HTTPS/443) out a different interface then your default route, then here is some information on how to do it.
Disappointingly, I thought this was a fairly simple ask – and in the end – it has turned out to be a relatively small set of instructions, but it took a long time to find much information about it at all.
My scenario is that I have a router connected to the internet, I also have a VPN to a USA Hosted VPN service. Given all this stupidity here in Australia with the “Great Australian Firewall” that the fool Senator Conroy is trying to implement, I wanted to practice redirecting web traffic out to the world via the VPN.
I use a snap gear router, but the instructions are pretty much the same for any iptables based router.

ip route flush table 200
ip rule del fwmark 0x50
iptables -t mangle -A PREROUTING -j MARK --set-mark 80 -p tcp --dport 80
iptables -t mangle -A PREROUTING -j MARK --set-mark 80 -p tcp --dport 443
ip route add table 200 default via 192.168.52.1
ip rule add fwmark 0x50 table 200

The first line flushes (empties) table 200. We are keeping our special routing table here, you can use any number you wish.
The second line deletes the reference telling the router to route all packets that are marked via the rule.

The next two iptables lines establish the rules for what gets to go out the auxiliary / secondary interface (in my case a VPN). Without explaining how iptables works, I am essentially looking for anything matching port 80 or port 443. That is HTTP and HTTPS respectively. If it does match that rule it gets marked with an “80″ or “0×50″ in hex (the hex is important in a moment).

Next we add the default route to our special routing table (table 200). It only has a default route for the moment, and it is the gateway IP of the VPN endpoint.

Finally we instruct the router to use the special routing table (table 200) for any packets marked as 0×50 (which is 80 decimal).

UPDATE
For those looking for some information about applying these sorts of rules in an OpenVPN environment, have a look at Taiter Tech Blog.

Category: information technology, work |
 

Switch to our mobile site