Socket library functions such as ntohs() return uint16_t, but inside
Python these return values show up as negative numbers. One possible fix
is to convert these return values using pack:

struct.unpack('H', struct.pack('h', ntohs(number)))[0] & 0xffff

Which number shows up as a negative number on your system?

Numbers returned from ntohs() turn up as negative. But ntohs() is typed as
uint16_t, so they shouldn't be. This is on solaris.

Please provide an example number

Try this on Linux and Solaris:
-----------------------
from socket import ntohs, htons

print ntohs(htons(55000))
-----------------------

On Linux:
55000

On Solaris:
-10536

This should be fixed. Maarten, can you create a patch that works for
you? (Since few of us have access to the platform where it breaks.)

Guido, the problem is that my python foo is severely lacking - but I'll
have a stab at it.

Python believes that the number coming back from the C library is
negative. We can fool it by packing the "signed short" into a
system-native format, and then unpacking it explicitly into an unsigned
short. So I propose to do precisely that on big endian systems using
sys.byteorder: wrap these functions with a converter. Would that be
acceptible?

Maarten, can you build Python 2.6 from svn?  (See
http://www.python.org/dev/faq/#subversion-svn for help.)

It looks like this has been fixed there, per r53434.  Perhaps the same
changes can be backported.

Maarten: Do you have time to try doing a test build as suggested by
Guido, to report if this issue is resolved?

This is likely fixed; setting the status to pending and priority to low.
 I believe this will eventually close it.