☑ SO_REUSEADDR on Windows

The SO_REUSEADDR option has quite different functionality on Windows than it does on Unix.

boy spying

Anybody who’s done more than a little work at the sockets layer will have encountered the SO_REUSEADDR socket option. For anybody who hasn’t, first a little background: when a TCP socket is closed, it’s kept lingering around for a little while in a state called TIME_WAIT. This is essentially a safeguard to prevent the port number being reused for another service until there can be a fair degree of confidence that there aren’t any outdated packets from the connection bouncing around that might get erroneously delivered to the new service, royally confusing everyone.

This option is great for client sockets because the number of outgoing ports is huge enough that typically it’s not a big deal having some sockets kicking around the place (it can cause issues on extremely busy systems that are making connections at a rapid rate, but we’ll gloss over that). It’s a bit more annoying for servers which listen for connections, however, since they typically need to re-acquire the same port number when they get restarted.

To work around this issue, the SO_REUSEADDR socket option was created which allows the port number to be reused by a new socket immediately. On Unix systems this means that if the old socket is in TIME_WAIT (and perhaps some of the other idle states) then a new socket can come along and steal the port number. Since the TIME_WAIT state is really just a precaution then this is generally pretty safe.

So far I’ve been discussing the behaviour of this option on Unix systems, but the same option also exists on Windows. However, I recently discovered that its operation is actually quite different. Instead of allowing a socket to “steal” the port number from an inactive previous one, it actually allows a socket to “steal” the port from any other socket, including actively listening ones. This could be fine if one socket is UDP and the other TCP, for example, but Windows will happily allow two or more active TCP sockets to share port numbers.

This MSDN page explains how the option works under Windows — the upshot is that if two sockets end up sharing a port then the behaviour of an incoming connection is undefined. Helpful.

As the article goes on to point out, this is a bit of a security problem — you can have a trusted service listening on a particular port and some other piece of malware can come along and silently steal the port, intercepting all the connections — this is a brilliant opportunity for a man-in-the-middle attack (admittedly requiring the ability to run code on the server machine).

Microsoft’s solution to this was not to change the operation of SO_REUSEADDR as you might expect, but to add a new option SO_EXCLUSIVEADDRUSE which explicitly prevents any other sockets listening on the same port, even if they use SO_REUSEADDR. Ah, why use one socket option when two will do?

Anyway, definitely something to bear in mind when writing Windows services (and, perhaps more importantly, when debugging them).

1 Feb 2013 at 12:42PM by Andy Pearce in Software  | Photo by Dmitry Ratushny on Unsplash  | Tags: windows sockets  |  See comments

☑ Sharing pthreads locks between processes

How to share pthreads primitives across processes.

share tomatoes

The POSIX threads library has some useful primitives for locking between multiple threads, primarily mutexes and condition variables.

Typically these are only effective to lock between threads within the same process. However, pthreads defines a PTHREAD_PROCESS_SHARED attribute for both of these primitives which can be used to specify that they should also be used between processes.

This attribute simply indicates that the primitives be used in a way which is compatible with shared access, however — application code must still arrange to store them in shared memory. This is fairly easily arranged with an anonymous mmap(), or shmget() and shmat() if your processes don’t have a parent/child relationship.

The use of shared memory makes things a little more complicated, which is disappointing, but it still seems to me that using these primitives to synchronise processes is probably still a little more elegant than using pipes or something similar (even if that’s probably a little more portable).

I’ve added a code example to my wiki which illustrates this. I’ve used an anonymous mmap() for shared memory — the previous revision of the page used System V shared memory, but since this isn’t cleaned up automatically on application exit then the mmap() approach is safer.

31 Jan 2013 at 1:02PM by Andy Pearce in Software  | Photo by Elaine Casap on Unsplash  | Tags: pthreads  linux  ipc posix  |  See comments

☑ apport in a storm

Ubuntu’s apport service is less then helpful for developers — learn how to disable it.

port storm

I’m not sure quite when it appeared, but Ubuntu 12.04 has a service called apport which is a bit of a pain.

It’s started by default and appears to attempt to collect crash dump information, presumably to send back to Ubuntu. I’ve seen little notification icons appearing at one time or another which I assume is this service doing its job. I’m not going to get into the potential privacy implications of sending core dumps of possibly commercial third party software (the rest of the system may filter the core dumps, I’m not sure), but if you’re a developer trying to get hold of core dumps this is annoying. I discovered this application when trying to figure out where my core dumps were disappearing to.

What happens is that the Upstart job for the service alters the value of /proc/sys/kernel/core_pattern, which changes where core dump files are stored, to pipe the core dump into /usr/share/apport/apport, which is a Python script. This script attempts to write the core dump to the local directory first, and then writes an annotated copy elsewhere, which is presumably picked up by some other background job which puts cutesy little exclamation marks into the notification area or something similar.

In principle, this isn’t all that terrible — after all, general users wouldn’t know a core dump if it bit them on the rear (and you really wouldn’t want a dump biting you in the rear). However, one rather crucial problem is that it ignores any previously set value of core_pattern and simply dumps its own value over it. The script always attempts to dump the core file into the current directory, regardless of the old value of core_pattern.

This is a bit of an issue because I use union mounts for building software, to avoid cluttering up my source directories with build artifacts, and these often confuse the kernel when it tries to generate core dumps. As a result, I change core_pattern to the following to store all core dumps in a central location:

/var/log/cores/core.%e.%p

This worked fine until I rebooted for some reason and suddenly apport stuck its ugly nose in.

Anyway, fortunately it’s pretty easy to disable. First edit /etc/default/apport and set enabled to 0:

1
2
3
4
# set this to 0 to disable apport, or to 1 to enable it
# you can temporarily override this with
# sudo service apport start force_start=1
enabled=0

Then, just stop the service:

sudo service apport stop

At this point you’ll want to check that it’s restored the value of core_pattern to something sensible, and update it yourself if not.

That’s one more developer annoyance in Ubuntu taken care of.

29 Jan 2013 at 1:16PM by Andy Pearce in Software  | Photo by Anna Goncharova on Unsplash  | Tags: linux  ubuntu debugging  |  See comments

☑ Bash expansion weirdness

Expanding a substring of “$*” in bash seems to magically add command-line parameter zero.

inflatable flamingo

Here’s a quirky one. In the bash shell, "$*" expands to a single string which is a whitespace-separated list of arguments starting at one. So if you have the following script as script.sh:

1
2
#!/bin/bash
echo Arguments: "$*"

… and you call it as script.sh arg1 arg2 arg3 then you’ll get the following output:

Arguments: arg1 arg2 arg3

So far so tedious. However, if we use some of bash’s parameter expansion rules to select a substring (in this case the substring starting at zero, or the whole string in fact):

1
2
#!/bin/bash
echo Arguments: "${*:0}"

… then suddenly you get parameter zero (the filename of the script) included:

Arguments: ./script.sh arg1 arg2 arg3

I’m not sure if that’s a bug or I’m missing some subtlety and it’s expected behaviour, but it’s one of those issues that’s pretty tough to Google around so I suspect it’ll remain a mystery.

25 Jan 2013 at 11:12AM by Andy Pearce in Software  | Photo by Vicko Mozara  | Tags: linux bash  |  See comments

⇐ Page 1   |   ← Page 5   |   Page 6 of 6