Anti Veeranna

They look like this one on the picture, nice and small. Available form Ebay. USB id is 0x148F,0×3370. It is not really supported by any of the drivers included with the latest kernel (2.6.34) and the official Ralink drivers available from their site do not support it either. This specific device id is not even in the source, and I did not manage to get it fully working after adding the id either.

Thankfully there are Windows drivers for this chipset and there is also ndiswrapper which allows Windows network drivers to be used in other operating systems, like Linux.

Sadly the windows drivers are distributed as one single Installshield .exe installer. I have no Windows machines in my home and none of the tools I had available (cabextract, etc) could not deal with this file. Finally managed to get the drivers (2780.sys and 2780.inf for WinXP) out of the installer with a help of a friend, who had a Windows machine.

First attempt to load this driver with ndiswrapper ended with the following error message in syslog:

ndiswrapper (import:242): unknown symbol: ntoskrnl.exe:'MmGetSystemRoutineAddress'

Then, I thankfully found this piece of information from Dirk Schwendemann, which I will reproduce here:

the ralink driver 1.4.0.0 (09/25/2008) for a rt2870 usb stick complains about a missing symbol MmGetSystemRoutineAddress.

I’ve just added an empty stub:

wstdcall void* WIN_FUNC(MmGetSystemRoutineAddress,1)
(struct unicode_string *name)
{
struct ansi_string ansi;
if (RtlUnicodeStringToAnsiString(&ansi, name, TRUE) == STATUS_SUCCESS) {
WARNING("MmGetSystemRoutineAddress: %s", ansi.buf);
RtlFreeAnsiString(&ansi);
}

return 0;
}

So I got the latest ndiswrapper (1.56), doublechecked the source, did not find this stub, added it to ntoskrnl.c somewhere after the other Mm* stubs, recompiled ndiswrapper, installed it and lo and behold .. my USB stick is now working.

Thanks Dirk ;)

OsX does not have ssh-copy-id. The following is a nice replacement for that:

cat ~/.ssh/id_dsa.pub | ssh user@otherserver "cat - >> ~/.ssh/authorized_keys"

I found the following gem over at Stackoverflow.com today. Given the following code, what do you think the result is?

<?php
var_dump("01a4" == "001a4");
var_dump("01e4" == "001e4");

The correct answer is:
bool(false)
bool(true)

Why?

PHP doesn’t like strings. It’s looking for any excuse it can find to treat your values as numbers. Change the hexadecimal characters in those strings slightly and suddenly PHP decides that these aren’t strings any more, they are numbers in scientific notation (PHP doesn’t care that you used quotes) and they are equivalent because leading zeros are ignored for numbers. To reinforce this point you will find that PHP also evaluates “01e4″ == “10000″ as true because these are numbers with equivalent values.

Previously.

Lets suppose you are learning to build PEAR packages (Pirum is a very nice PEAR channel server btw). You managed to create and publish the initial version of the package and it even installed just fine after you ‘pear install’-ed it.

Then you fixed a bug in the source, increased the version number in package.xml, built and published the next version. The new version is listed at the Pirum generated page.

• But ‘pear upgrade channel/Package’ does not ugprade to newest version.
• Forcing upgrade with -f does not help either.
• Uninstalling and reinstalling the package still gets the previous version.
• channel-update does not help.
• After uninstalling the package, removing the source from Pirum, regenerating the index and trying to reinstall you get a nice error stating that this version does not exist at the server.

I was really puzzled by all that. Then I discovered the reason – by looking at pear configuration.

$ pear config-get cache_ttl
3600

Channel contents are cached for that many seconds (3600 = 1 hour). The solution is to either reduce this number, or – preferrably – nuke the cache by

$ pear cache-clear

After this your package will upgrade just fine ;)

Its very logical to cache this information of course to avoid killing package servers and I feel really stupid for not figuring it out earlier.

I have had to deal with Soap lately. Mostly it works, except when it doesn’t. In my case I found out that its not exactly straightforward to make a Nusoap client talk to a PHP5 Soap server. Of course, it also depends on the WSDL. Probably. Maybe. In any case I was in a world of pain, which I do really not want to describe in more detail.

But then I found this article, and it made my day :) S stands for Simple. I have been suspecting this, but now its proven. Sigh.

Let me sum up. The definition of SOAP is in constant flux, SOAP is anything but simple, and it is no longer meant for accessing objects-even though that’s what all the tools still do.

Given the following piece of PHP code:

$a = '1112000000001779149';
$b = '1112000000001779148';
var_dump($a == $b);

Can you tell, without trying to run it, what the result is?

The answer – it depends on your platform. On a 64bit platform you will get boolean false, on a 32bit platform you will get boolean true.

Why? Because PHP does type juggling, if strings are compared and they look like numbers, then they will be convereted to numbers before doing the comparision. And the following piece of code demonstrates the behaviour:

print php_uname('m');
print "\n";
print PHP_INT_SIZE;
print "\n";
print (int)1112000000001779149;
print "\n";

If you run it on different platforms, then this is the result that you will get:

x86_64
8
1112000000001779149

i386
4
-1

From this its already obvious, why the above string comparision resulted in true on 32bit platform. Its because -1 indeed equals -1.

Solution?

Either use === for comparisions, or if you care about your numbers, use the bcmath extension