Das Werkstatt

[PROBLEM]
since IR-clients can connect to the lircd to receive IR signals from one central receiver, it's possible to control all other computers in the network.

I'm using IRAssistant (on the windows side), but when trying to perform different tasks on different computers with ONE remote, ALL listening machines are simultaneously interpreting the incoming signals. This might lead to undesired side-effects (such as one computer suddenly shutting down, because a part of a sequence was misinterpreted).

To avoid this it would be desirable to 'disconnect' certain computers from the lircd, but without their clients realizing it (since this would lead to error-messages like "failure to connect to lircd").


[SOLUTION]
The basic communication between the client and the server only produces packets of 40 to 50 bytes size. When blocking all packets above this, the client assumes an established connection, but cannot receive IR commands (they are 75 bytes and above).

This can be done by using iptables:
------------------------------------------
$IPTABLES -R OUTPUT 1 -p TCP -d $IP_ALLOW --sport 8765 -j ACCEPT
$IPTABLES -I OUTPUT 2 -m length --length 50:65535 -p TCP --sport 8765 -j DROP
------------------------------------------

the first line allows IR commands to be sent to $IP_ALLOW, the second one blocks them for all other clients.

for some (currently still unknown) reason, 'irAssistant' does not receive any more signals from the remote control after some time.

[later on that day]
hm... I've monitored the packets going from/to the lircd and it seems that although the iptables are supposed to DROP some packets, the received IR signals during the "blocked" time period are buffered.

Right after removing the iptables-block, they're sent to the client ALL at once! Maybe this kills the client?

well, well... took a long time to figure out (actually thanks to a hint from a friend): if you take a closer look at the iptables script above, you'll notice that the communication's over TCP...

and if you're familiar with the intention of TCP, it suddenly makes sense, that the packets behave "buffered". The iptables script blocks the reception-confirmation from the other side and this is when TCP kicks in: it tries to send them over and over again, since it assumes packet-loss.

the only thing which currently won't fit into this theory is, that there should be some sort of timeout, but maybe during my test-phase, I switched too fast for the timeout to do its job.

finally... now I AM sure that the packets are kept in the send-queue, but since they never arrive at their target-host, they can't be acknowledged and are thus kept forever.

...and 'yes', there IS a timeout for those packets, but unfortunately they're not just thrown away, but the timeout kills the connection - and THIS is why the client won't receive any IR-commands even if switched on. (so the application is not dying due to too many received commands, as I've assumed before)

when doing a 'netstat', I can see that the 'send-q' gets filled up, but I haven't found any way of flushing it (which would probably solve this problem for good)