Thu, 27 Mar 2014

Bug reports

I've noticed that many testers, project/program/product managers, ... have no idea on how to properly report bugs, or request new features.

It's well known that developers will do everything they can to avoid actually writing code, so it's vitally important to avoid falling for their traps when reporting a bug. My fellow developers will be angry with me for giving away this secret information, but, well, it wants to be free!

Here are a few hints:

In conclusion, the ideal bug report is "It breaky. You fix.".

In case someone doesn't get it, the above suggestions are NOT something you should do in bug reports. Unfortunately just about all of these are based on one or more bug reports I have received over the years.

posted at: 22:22 | path: /rant | [ 0 comments ]

Sun, 29 Dec 2013

Hotmail

No, I don't use them, but sometimes I send e-mail to people who do. It turns out that they don't like my e-mail. It sends up in the spam bucket.

After finding someone with a little clue who still remembered having a hotmail address I obtained the headers for one of my mails. It had this in it:

Authentication-Results: hotmail.com; spf=temperror ...

The OpenSPF people explain what this means:
Hotmail does not use live DNS for Sender ID. They have a DNS cache that they update twice per day. All TempError means is that your domain's SPF record is not in their cache. To get your record added to their cache, send an e-mail message to senderid@microsoft.com with your domain in it. They will add it, but be patient as it's a manual process and the cache only updates twice a day.

It appears that Microsoft don't even understand DNS (or e-mail). Why does that still surprise me?

posted at: 16:42 | path: /rant | [ 0 comments ]

Sun, 26 May 2013

AsciiDoc is great, but...

I was recently(-ish) introduced to AsciiDoc by a rather strange individual.

Suffice to say I've pretty much fallen in love with it. It pretty much mirrors the way I type plain text documentation, but it manages to generate quite pretty HTML output. All of the advantages of plain text (I get to use Vim, version control Just Works, ...), with only one downside: no previews of what I'm doing.

So I did something about that: qinotify is a small Qt utility which monitors .asciidoc files with for changes, and displays the latest version of the HTML output.

posted at: 23:12 | path: / | [ 3 comments ]

Wed, 06 Mar 2013

Sometime I hate Google

Sometimes I hate Google, or at least their mail admins. They seem to have entirely missed the point of SPF records.

I publish them, not because I believe they'll fix the spam problem, but because a spammer has taken to forging their sender address to appear to originate from my domain. Obviously none of my servers are involved in such loathsome activities.
I publish these records to give other mail admins the chance to reject such e-mail outright, or at least to assign it a higher spam probability but mostly so they won't bug me about having rejected it.

Google rather seem to have missed the point though because they use them to reject the spam, which is good, and then send delivery failures to me. They know that it's spam with a forged sender, that's why they're rejecting it in the first place, yet they bug me about it.

Delivery to the following recipient failed permanently:

     efqrbsuglyjfuhxy3uca3w1b@jbinup.com

----- Original message -----

X-Received: by 10.68.42.9 with SMTP id j9mr23765326pbl.142.1362320729989;
        Sun, 03 Mar 2013 06:25:29 -0800 (PST)
Return-Path: 
Received: from [41.143.193.146] ([41.143.193.146])
        by mx.google.com with ESMTP id tv4si18179919pbc.155.2013.03.03.06.25.24;
        Sun, 03 Mar 2013 06:25:29 -0800 (PST)
Received-SPF: fail (google.com: domain of B37FBAB0D@sigsegv.be does not designate 41.143.193.146 as permitted   
+sender) client-ip=41.143.193.146;
Authentication-Results: mx.google.com;
       spf=hardfail (google.com: domain of B37FBAB0D@sigsegv.be does not designate 41.143.193.146 as permitted s
+ender) smtp.mail=B37FBAB0D@sigsegv.be
From: "Tanya Guerrero" 
Subject: hi there
To: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; chars="iso-8859-1"
Date: Sun, 03 Mar 2013 14:25:21 -0000
Message-ID: <20130303142521.244356B88AC8AC5DC029.4744484@SARA-PC>

SPAM SPAM SPAM

posted at: 19:59 | path: / | [ 0 comments ]

Sun, 06 May 2012

Open sores

After complaining about Microsoft last time I figured I'd do something different this time: I'm going to complain about a piece of open source software.

It needs no introduction, but I'll give it one anyway: The ISC DHCP server and client are the standard DHCP(v4/v6) implementations and they're used all over the place.
Recently I was fixing a bug in a dhclient-script.sh. It incorrectly parsed an IAID value because it contained an '='.

The relevant bits of source code:

	ient_envadd(client, prefix, "iaid", "%s",
			print_hex_1(4, ia->iaid, 12));
This just adds the IAID value to the environment encoded, you'd expect, as a hex string.
Hang on? Hex string? Didn't I just say that we got an '=' in the data?

Looking a little deeper there's the first disturbing bit:

#define print_hex_1(len, data, limit) print_hex(len, data, limit, 0)
#define print_hex_2(len, data, limit) print_hex(len, data, limit, 1)
#define print_hex_3(len, data, limit) print_hex(len, data, limit, 2)
Umm, ok then.

#define HBLEN 1024
char *print_hex(len, data, limit, buf_num)
        unsigned len;       
        const u_int8_t *data;
        unsigned limit;      
        unsigned buf_num;    
{
        static char hex_buf_1[HBLEN + 1];
        static char hex_buf_2[HBLEN + 1];
        static char hex_buf_3[HBLEN + 1];
        char *hex_buf;

        switch(buf_num) {
          case 0:
                hex_buf = hex_buf_1;
                if (limit >= sizeof(hex_buf_1))
                        limit = sizeof(hex_buf_1);
                break;
          case 1:
                hex_buf = hex_buf_2;
                if (limit >= sizeof(hex_buf_2)) 
                        limit = sizeof(hex_buf_2);
                break;   
          case 2:        
                hex_buf = hex_buf_3;
                if (limit >= sizeof(hex_buf_3))
                        limit = sizeof(hex_buf_3);
                break;
          default:
                return(NULL);
        }

        print_hex_or_string(len, data, limit, hex_buf);
        return(hex_buf);
}
Wait what? What's with the three static buffers?
It's an evil, and stupid little trick to avoid having to supply a buffer from the caller. That's why there's a static buffer: the caller can just use the returned pointer without having to worry about freeing allocated memory.
There's three of them because presumably at some point someone tried to convert two strings before printing them and discovered that only both always had the same content when he used the output. Instead of solving the problem properly he decided to use this disgusting hack instead.
That's bad, but what about print_hex_or_string?

/*      
 * print a string as either text if all the characters
 * are printable or colon separated hex if they aren't
 *        
 * len - length of data 
 * data - input data
 * limit - length of buf to use 
 * buf - output buffer
 */       
void print_hex_or_string (len, data, limit, buf)
        unsigned len;
        const u_int8_t *data; 
        unsigned limit;
        char *buf;
{               
        unsigned i;
        if ((buf == NULL) || (limit < 3))
                return;
          
        for (i = 0; (i < (limit - 3)) && (i < len); i++) {
                if (!isascii(data[i]) || !isprint(data[i])) {
                        print_hex_only(len, data, limit, buf);
                        return;
                }
        }

        buf[0] = '"';
        i = len;
        if (i > (limit - 3))
                i = limit - 3;
        memcpy(&buf[1], data, i);
        buf[i + 1] = '"';
        buf[i + 2] = 0;
        return;
}       
Well, that's about as bad as the function name sounded. This converts the supplied data into a string, either by interpreting it as plain ASCII (if all of the bytes are printable), or converting it into a real hex string.
Enjoy yourself parsing that. Writing parsing and validation code is so much fun and now you get to do it twice!

posted at: 23:22 | path: / | [ 1 comments ]

Thu, 22 Dec 2011

A brief rant.

Observe the NdisAllocateMemoryWithTagPriority[1] function.

PVOID NdisAllocateMemoryWithTagPriority(
  __in  NDIS_HANDLE NdisHandle,
  __in  UINT Length,
  __in  ULONG Tag,
  __in  EX_POOL_PRIORITY Priority
);

Read the documentation:

Tag [in]
    A string, delimited by single quotation marks, with up to four characters, usually specified in reversed order. 
    The NDIS-supplied default tag for this call is 'maDN', but the caller can override this default by supplying an explicit value.

That's right. Pass that string as a ULONG please. I just don't have the words.

[1]Think kmalloc, but harder to type.

posted at: 13:20 | path: / | [ 0 comments ]

Sun, 21 Aug 2011

World IPv6 day

A little while ago (well, a long while, but I've been busy) the Internet Society organised World IPv6 day.

I'm not going to bother explaining what that was about, I'm sure everyone knows by now. Instead, I'm going to complain about a little experiment I did more than three years ago. Hopefully all the buzz around World IPv6 day and the IANA pool exhaustion has encouraged a few more people to offer their blog over modern IPv6, in addition to crusty old IPv4.

The results are, ... well, results. Three years ago there was one blog in Planet Grep which was reachable on the IPv6 internet. This blog is still there (though with a different IP) and there's all of four more. That's 5 out of 69, or 7.24%.
Just for fun I reran the test on the current list of blogs on Planet Grep. 7 of 97 sites, or 7.21% have an IPv6 address.
Not exactly great that. On the bright side: at least the sites which advertise quad-A records are indeed reachable on those addresses, and the one site which had an IPv6 address back in 2008 still has one.

Come on guys (and girls obviously), we can do better than this.

posted at: 16:45 | path: / | [ 0 comments ]

Sun, 12 Dec 2010

Change is a constant

Just in case I haven't told everyone yet, I'll be leaving my current employer mid January. From then on I'll be freelancing. I've already got a website and everything. (Well, not everything. In fact, just the website, but the rest is being worked on.)

Why? Well, two reasons really, the first is that a really interesting project and the second is the bad influence of a few friends.

If you have a problem, if no one else can help, ...
Well, you should probably call the A-Team, but you've got a software problem you should call me. The A-Team doesn't know anything about software.

posted at: 23:06 | path: / | [ 4 comments ]

Sun, 21 Nov 2010

Tcptrack 1.4.0

Tcptrack 1.4.0 is out. This version supports IPv6. Blame yours truly for any bugs you find.

posted at: 21:46 | path: / | [ 0 comments ]

Tue, 12 Oct 2010

Don't lie to me!

while toying with my little project I decided that things would be much simpler if I could netboot the board. Unfortunately the bootloader does not provide this functionality. U-boot can do this, so we'll just be evil and have the native bootloader (which I can't upgrade) boot U-boot, and have U-boot load the FreeBSD kernel (While I'm on the subject: I've gotten it to boot again.).

While adding support for my board I ran into the following error message:

	make: *** No rule to make target `ts7800_config'.  Stop.
Clearly I forgot to add something in the makefiles. After an hour of fruitless makefile reading I discovered the cause: a little shell script to generate the configuration. The mkconfig script searches a file I hadn't edited yet. Here's the relevant code:
     line=`egrep -i "^[[:space:]]*${2}[[:space:]]" boards.cfg` || {
                echo "make: *** No rule to make target \`$2_config'.  Stop." >&2
		exit 1  
Can you spot what upset me?
Don't lie to me when reporting errors! If it hadn't pretended to be make I'd have found the problem instantly.

Now to get U-boot to actually start...

posted at: 22:36 | path: / | [ 0 comments ]