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 ]
Wed, 12 May 2010
Reverse the polarity!
It was a dark and stormy night. Well, not really. It was more of a sunny afternoon but I promised Wouter I would start my next blog post with the famous Bulwer-Lytton sentence.
So, anyway, it wasn't a dark and stormy night but a bright and sunny afternoon a few weeks ago when I ordered a USB charging cable for my cell phone. They're unreasonably expensive in Belgium but I found a great deal on DealExtreme. A Genuine© Immitation™ Nokia®-Like one even.
Today the cable arrived but when I plugged in my phone it refused to charge.
Linux complained too:
[959307.552135] hub 5-0:1.0: over-current change on port 2
Clearly something was wrong with the cable. Two minutes with a multimeter and a working cable for comparison
showed that somehow the ground and +5V connections were inverted.
15 minutes with a soldering iron fixed that. All in all I got a great deal: a charging cable, half an hour of
entertainment and that lovely feeling of having fixed something for less than a quarter of the price of
a genuine Nokia cable.
Beware of geeks with soldering irons.
posted at: 23:34 | path: / | [ 0 comments ]
Tue, 13 Apr 2010
You're doing it wrong!
It's been far too long since I've really complained about something.
${Work} has decreed that passwords must be changed regularly and today it was my turn. Fine, despite the usual silliness in reducing the key space (by enforcing certain sets of characters to be present) and a ridiculous maximum length of 8 characters, I can deal with that. pwsafe generates and remembers the password for me. After a while I even manage to remember it myself.
Clearly that's not a good rant. This, however, is worth complaining about:
I did the obvious thing:
dd if=/dev/urandom bs=1k count=10 | md5sumJust divide the result in four more or less equal parts and there's the answers to the insecurity questions. Simple, except it rewards me with the above session timeout.
Note that 'back' and 'forward' should not be used, in defiance of 20 years of precedent. Also note that if you're a slow reader you'll just get the login page again.
After all, it's not nice to show error messages to the users. It upsets them so it's best to hide them as soon as possible.
posted at: 21:19 | path: / | [ 2 comments ]
Sun, 21 Feb 2010
Lies, damned lies and ...
The build system at work needed a bit of a cleanup. It's a fairly standard autoconf/automake deal which has been extended by people who don't understand those tools. This is understandable. There are after all very few people who truly do. I certainly don't.
Still, seeing HOST be confused with TARGET does indicate there's a problem.
While I don't know much about autotools I do know a thing or two about plain old make.
I spent some time setting up a non-recursive build system, borrowing heavily from the
Linux kernel build system bag of tricks.
After a little work I got the first few applications building with the new system.
Before committing it I wanted some performance numbers. Sure, the new system is
(at least in my opinion) much cleaner, simpler, and powerful, but a faster build
is something every developer cares about.
Measuring build times can be a little tricky as they could vary significantly due to
caching, other processes running on the system, ...
The mathematical tools to deal with this exist, but who wants to spend hours refreshing
statistics courses? Fortunately there's a very simple tool to do exactly the kind of statistical
calculations benchmarks call for: ministat.
All you need to do is hand it two files with the results to compare.
It's a FreeBSD tool, getting it to work on Linux is a (trivial) exercise left for the reader.
Here's the output of 11 test runs of both the old (autotools, recursive make) and the new (plain make, non-recursive) system when running 6 jobs simultaneously.
x old-system.txt
+ new-system.txt
+------------------------------------------------------------------------------+
|+ x |
|+ x |
|+ x |
|++ x |
|++ x |
|++ xx |
|++ xxx|
|A| A| |
+------------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 11 662.44 673.03 663.69 665.20545 3.224591
+ 11 324.47 329.55 326.46 326.61364 1.8295151
Difference at 95.0% confidence
-338.592 +/- 2.3318
-50.9003% +/- 0.350539%
(Student's t, pooled s = 2.62156)
The results surprised me a little: because there's so little variation in the results, but mostly because the build time with the new system is so much better. There's little variance in these results so simply comparing the first measurements would have told us the same thing. On the other hand, now we know.
I believe I'll have little trouble convincing my coworkers that the new system is better.
posted at: 11:37 | path: / | [ 0 comments ]