I’ve still been talking to HTC regarding my faulty Touch Pro 2. I even managed to get the case escalated to someone who says they do this all the time. He has agreed that HTC should cover the postage costs as per the Warranty Statement in my previous post and that he’d get back to me with more details within 24 hours. Sadly, this timeframe expired yesterday.

He did however inform me that the repairs may take up to 4 weeks plus shipping. I objected to that as this would mean that the phone has been off under warranty repair for 8 weeks in its lifetime. Apparently this has been raised with HTC management - I’ll wait and see what that actually means!

Just recently I had to set up a sendmail server for an office with 7 local users and more roaming users. The current setup had all users checking email via POP3 to the ISP. This is an issue as email sent locally within the office passed over the ADSL connection twice. Sendmail however is quite difficult to work with when it can’t handle the entire domain. As not all users on the domain have an account on the office server, email would bounce back as user unknown - even though a POP3 account existed with the ISP.

I’ll write up a dummy scenario to make this clearer.

• local1 - Checks email on the local server via IMAP. Server downloads email via fetchmail and throws it in the users IMAP mailstore.
• local2 - Same configuration as local1.
• remote1 - This user doesn’t have an account on the local server but gets email via the ISPs POP3 mail account.

All users have the same domain name in their email address. For this example, we’ll use mydomain.com.au.

The issue starts with a couple of common problems.

a) If we put mydomain.com.au in /etc/mail/local-host-names, then email between local1 and local2 will be handled locally - which is great. The problem though is that mail between local1 and remote1 will bounce with a ‘user unknown’ error.

b) Having a smarthost defined to send email out via the ISPs mail server will also mean that mail between local1 and local2 will also go to the smarthost - essentially uploading it to be downloaded again. This adds delay and also slows things down.

To fix this, we can use the virtusertable to rewrite the addresses of the email addresses - but by default, sendmail does not run the virtusertable on any addresses of domains it does not own.

We can however modify our sendmail.mc with the following code to tell sendmail to run domains we specify through the virtusertable! The code is as follows:

1
2
3

FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl
LOCAL_CONFIG
F{VirtHost}/etc/mail/virtual-domains

Now we can add the domains we want to run the virtusertable on in /etc/mail/virtual-domains: mydomain.com.au

The final step in this solution is to then specify what users we want to rewrite to be local users. This is in /etc/mail/virtusertable:

1
2

local1@mydomain.com.au     local1@localhost
local2@mydomain.com.au     local2@localhost

Now when we test these addresses using sendmail -bt from the server, we see the address translation happen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /parse local1@mydomain.com.au
Cracked address = $g
Parsing envelope recipient address
canonify           input: local1 @ mydomain . com . au
Canonify2          input: local1 < @ mydomain . com . au >
Canonify2        returns: local1 < @ mydomain . com . au . >
canonify         returns: local1 < @ mydomain . com . au . >
parse              input: local1 < @ mydomain . com . au . >
Parse0             input: local1 < @ mydomain . com . au . >
Parse0           returns: local1 < @ mydomain . com . au . >
ParseLocal         input: local1 < @ mydomain . com . au . >
ParseLocal       returns: local1 < @ mydomain . com . au . >
Parse1             input: local1 < @ mydomain . com . au . >
Recurse            input: local1 @ localhost
canonify           input: local1 @ localhost
Canonify2          input: local1 < @ localhost >
Canonify2        returns: local1 < @ intranet . mydomain . com . au . >
canonify         returns: local1 < @ intranet . mydomain . com . au . >
parse              input: local1 < @ intranet . mydomain . com . au . >
Parse0             input: local1 < @ intranet . mydomain . com . au . >
Parse0           returns: local1 < @ intranet . mydomain . com . au . >
ParseLocal         input: local1 < @ intranet . mydomain . com . au . >
ParseLocal       returns: local1 < @ intranet . mydomain . com . au . >
Parse1             input: local1 < @ intranet . mydomain . com . au . >
Parse1           returns: $# local $: local1
parse            returns: $# local $: local1
Recurse          returns: $# local $: local1
Parse1           returns: $# local $: local1
parse            returns: $# local $: local1
2                  input: local1
2                returns: local1
EnvToL             input: local1
EnvToL           returns: local1
final              input: local1
final            returns: local1
mailer local, user local1

Checking against any other email address should show the normal delivery method - either normal MX lookup and delivery, or via a defined smarthost.

As a lot of you know, I got myself a HTC Touch Pro 2 a few months ago - and boy - am I starting to regret it. I bought the phone in March - it was returned under warranty in April, and now has to go back under warranty again. Read on for the full details of how HTC support is more than useless in looking after its customers.

The full story: Optus (my carrier) have rolled out an extensive 900Mhz 3G network over most of the regional and non-metro areas - so it makes sense to have 900Mhz 3G support. Sadly, Telstra seem to be the only carrier that has the Touch Pro 2 in Australia - which means it only supports 850Mhz & 2100Mhz. For this reason, I purchased my Touch Pro 2 directly from Singapore - as they are the only location I could find (other than Europe) that has support for 900Mhz & 2100Mhz 3G services.

I purchased my phone on 12th of March 2010. The phone arrived on the 18th of March. Great so far! I unwrapped the box and fired it up and was VERY impressed. I spent hours exploring every new feature. After a few days, I had it set up in a way that was just right for me and was getting very used to using it quickly and efficiently. Then after 2 weeks, the USB port died.

It was certainly a hardware fault. The USB port was not detected via Windows, nor could the bootloader show it connecting via USB. With all my time dealing with HTC devices, I knew this meant a warranty return.

I started off contacting HTC Australia - which then handballed me off to the “Global Warranty Service” area of HTC - which means calling HTC in Singapore. Sure I thought, after reading the Warranty Card. This should be nice and easy. How wrong I was.

First, I’ll draw your attention to the HTC Warranty Card. Specifically this part:

In the event of Product failure, the Customer should take the following actions:

a) Refer to the user manual in order to identify and possibly correct the problem.

b) If the problem cannot be resolved by reference to the user manual the Customer should then contact the dealer where such Product was purchased or visit your local HTC website, or HTC service center or www.htc.com for further information.

c) Before the Customer contacts HTC service agent, please ensure the following information is at hand:
•- The model and serial number, IMEI number of the Product.
•- The Customer’s full address and contact information.
•- A copy of the Customers original invoice, receipt or bill of sale of the purchase of the Product.

HTC will provide the Customer with instructions regarding how and when the defective Product should be returned. HTC will pay costs in connection with both the return of the defective product to HTC and the repaired Product back to the Customer if the Defective Product is within the Warranty Period.

Awesome! HTC really stand by their product - or so it seems. In reality, as soon as you contact HTC regarding the warranty, you realise that not only do you have to pay for shipping directly to HTC, they will also hold your device to ransom until you pay the shipping costs back to you FROM HTC as well! Sadly, I didn’t find this out until AFTER HTC already had my device. After lots of arguing with HTC Singapore, they decided to be nice and pay the return shipping costs. To make matters worse, until HTC contacted me to say I had to pay the shipping costs, I couldn’t find out if my phone had even been received by HTC!

So after 3 weeks of having no idea where my phone is or even if HTC were going to send my phone back to me, a package arrived with my repaired phone. In the box was a report telling me that they had replaced the LCD module and main board. Essentially, all they left the same was the case. This would normally be good news - however it goes further than that. When I received the phone back, the keyboard didn’t fit in its spot properly and felt warped. To add to this, the LED behind one of the keys is always stuck on full brightness. Surely this shouldn’t have even passed the QA on the repair - let alone be shipping back to a customer in this shape! That being said, I figured I could live with this - as I really did not want to go through the support process with HTC again!

Now lets fast forward to October. Oh no. The USB port has died again. The exact same symptoms as before. This time however, there is a new twist. The battery drains VERY fast. A full charge that used to last 48+ hours now only lasts 12. This is not good.

I started talking to HTC Singapore again. After a while of talking to them on the phone, I realised that this wasn’t going to get anywhere. Anything beyond basic English is well beyond them. They cannot understand why I am annoyed at the whole process and they refuse to do anything but ‘ship it back to us, pay us and we’ll look at it’ - paraphrased from broken English of course. After almost 4 weeks of waiting for them to get back to be via either email or phone, I decided to contact HTC America.

The good news is that HTC America actually understand English! The bad news is that they seem to be just as unwilling to help. After expressing my deep concerns about the entire process, Alan (referred to later as HTC Guy) tells me that in all reality, after paying to ship my device to HTC, I might be waiting 2 months for the repair, then the time for shipping back to me. Oh, and I have to pay for shipping both ways.

So, after about an hour talking to HTC Guy, I finally asked for a copy of the Global Warranty Statement - as it sure as hell isn’t the one that is on their web site. After a long time on hold and lots of consulting with a supervisor, I get asked for my return number and they will get back to me with some details of what the actual Global Warranty Statement is - as nobody could seem to find it.

edit: After 24 hours, no reply from HTC at all. For some reason, I am not surprised.

At the moment, all I can see is that the lovely 12 month warranty will consist of 1 month in transit, 2 months at repair facilities, 3 months of being faulty, 6 months of normal usage (if I’m lucky!).

It even got to me so much that I wrote letters (yes, actual postal mail letters!) to both HTC Taiwan and HTC America. Surprise, surprise though - no response to them either as yet.

Its been a while since I’ve given an update on my Digital CoPilot project. Things are progressing VERY well - The new WAC charts from AirServices should now be accurate to within 85 metres - which is 1 pixel! Route planning is completed and the device is currently being flight tested. A few bugs have been found and have been ironed out, but all in all, everything is slowly coming together.

I’ve been a huge fan of XFS for many, many years. Its quick, its efficient, and it works very well. Times have changed however since the first time I used XFS. There seem to be a lot of misinformation on the web of using selinux with XFS - mainly about the size of the required inodes.

A bit of history

Ok, so in a filesystem you have these things called inodes.

Inodes basically store information about files and folders, such as (user and group) ownership, access mode (read, write, execute permissions) and file type - Wikipedia.

SELinux stores an extended attribute in the security namespace as part of the inode. Now the key part - if the inode is not big enough to fit its usual data and the extra selinux data in, then a block from the filesystem is used to store the extra data. This usually means that the system will use 4Kb of space for around 50-60 bytes of additional data.

This is a problem. Not only because we waste 90% of the 4kb, but for performance as well as for every read to this inode will also require a read of the 4Kb block associated with the inode - wherever that may be on the filesystem.

The misinformation

Many sites around the web say that it is better to use a 512 byte inode. This will just about guarantee that all information required is in the one inode. This used to hold true - however these days, XFS uses a different method to write these inodes.

This means that the data for 99.9% of files will fit within a 256 byte inode - and it may even increase performance to do this. The change can be seen in Eric Sandeen’s post to a bugzilla report regarding this subject.

This is summerised as such:

Ondisk format extension for extended attributes (attr2)

Basically, the data/attr forks now grow up/down from either end of the literal area, rather than dividing the literal area into two chunks and growing both upward. Means we can now make much more efficient use of the attribute space, incl. fitting DMF attributes inline in 256 byte inodes, and large jumps in dbench3 performance numbers. It is self enabling, but can be forced on/off via the attr2/noattr2 mount options.

So what does this mean? In short, if you are using XFS and SELinux together, you should do perfectly well with the defaults of your XFS creation by the OS installer. Running xfs_info /dev/sdaX on your system will allow you to check the size of your inodes (isize) and if attrs=2 has been set on your filesystem creation. You should see something like:

1
2
3
4
5
6
7
8

meta-data=/dev/sda3              <strong>isize=256</strong>    agcount=4, agsize=15112064 blks
         =                       sectsz=512   <strong>attr=2</strong>
data     =                       bsize=4096   blocks=60448256, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=29515, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

If you do, all is well. If not, lodge a bug with your distro!

Oh, and if you want to check your existing XFS partition for out of inode data, run the following:

1

for FILE in `find / -xdev`; do xfs_bmap -a $FILE; done | grep -v "no extents"

This will list all files that have an extra block allocated for extended attributes.