Skip to content

Networking problems

SSL: WRONG_VERSION_NUMBER

When you have a python request that raises this exception, it is usually that you posted to https: instead of http:

iptables -D

This caused me some headaches, so let's document my solution. The problem is trying to delete a line created by for instance :

insert chain
iptables -I PREROUTING 1 -t nat -p tcp --dport 8200 -j DNAT --to 192.168.122.200:22

Since this works perfectly the obvious solution would be to :

delete chain
iptables -D PREROUTING -t nat -p tcp --dport 8200 -j DNAT --to 192.168.122.200:22

Note the 1 after PREROUTING, which stands for the insert rule number and that is absent in the second line. However it still does not work, since the -D syntax is far more stringent than the -I . The order must be correct and --to is unknown. For instance to really get frustrated :

This command :

delete
iptables -t nat -D PREROUTING -p tcp --dport 8200  -j DNAT

Will complain about :

output
iptables v1.4.7: You must specify --to-destination

while (yes.. -to-destination added)

retry
iptables -t nat -D PREROUTING -p tcp --dport 8200 --to-destination 192.168.122.200 -j DNAT.. code-block::

This will complain about :

error
iptables v1.4.7: unknown option `--to-destination'

Nice, no ?? To get rid of all these (probably ordering) problems do it like this :

List the rule you want with the -S option instead of -L

list rules
iptables -t nat -S

You get the format used by the service iptables save command and /etc/sysconfig/iptables. These are cut-and-paste compatible so :

output
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 

You can delete this with :

now delete
iptables -t nat -D POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535

X11 forwarding

ssh -X does not work and prints :

Error

Invalid MIT-MAGIC-COOKIE-1 keyError: Can't open display: :0.0

When you set the display variable, the Cookie message goes away:

error
1
2
3
export DISPLAY=192.168.2.36:0.0
xeyes
Error: Can't open display: 192.168.2.36:0.0

However, this is not how -X/-Y works. This is how remote display access works !!

If you do it with ssh -X then it sends the X traffic along to port 6010 for display 10.0, 6011 for Display 11.0 and so on. Issue this command on servert, where all connections are made by xterm -X calls :

netstat
netstat -l | grep 601

tcp        0      0 localhost:6011          *:*                     LISTEN
tcp        0      0 localhost:6012          *:*                     LISTEN
tcp        0      0 localhost:6013          *:*                     LISTEN
tcp        0      0 localhost:6014          *:*                     LISTEN
tcp        0      0 localhost:6015          *:*                     LISTEN
tcp        0      0 localhost:6016          *:*                     LISTEN
tcp6       0      0 localhost:6010          [.. code-block::]:*                  LISTEN
tcp6       0      0 localhost:6011          [.. code-block::]:*                  LISTEN
tcp6       0      0 localhost:6012          [.. code-block::]:*                  LISTEN
tcp6       0      0 localhost:6013          [.. code-block::]:*                  LISTEN
tcp6       0      0 localhost:6014          [.. code-block::]:*                  LISTEN
tcp6       0      0 localhost:6015          [.. code-block::]:*                  LISTEN
tcp6       0      0 localhost:6016          [.. code-block::]:*                  LISTEN

That's two connections (ip4 and ip6) for each windows you have opened.

And you should set the Display to :

set display
export DISPLAY=127.0.0.1:10.0

If you want to do the same without ssh, the X server should be configured to accept the traffic. I use the ssh forwarding so i'm not figuring out how to do that here.

remmina screen size

When you start up a remote desktop app it will by default take on the same resolution as you screen. That's great for fullscreen usage but mostly i want to use the app in a window so i can do things on the calling system (my desktop). There are various options like scaling and scroll-bars, but the basic resolution always stays the same.

Note

Use rdesktop-vrdp (from Virtualbox) instead of remmina !

Start the remote desktop with this command:

rdesktop-vrdp -g 1900x1200 192.168.2.47

chrome does not startup in rdesktop window

When you start it up by hand it issues some warnings:

error
1
2
3
4
5
Xlib: extension "XInputExtension" missing on DISPLAY ":18:0".
Xlib: extension "XInputExtension" missing on DISPLAY ":18:0".
Xlib: extension "XInputExtension" missing on DISPLAY ":18:0".
..
Created new window in exsiting browser session.

That last one says it all, you still have a session in another rdesktop or remmina window. This happens when you just kill such windows instead of really log out. If you try to connect to that session you will see all chrome windows you attempted to open.

too many open files klopt_srv

This was during a brute force test against the proxy server. By the way i think there should be another solution made than just relaying each request through another socket, .. later

The test setup was to run all scripts in grid/test at the same time :

commands
1
2
3
4
5
./nearest.py
./geo.py
./route.py
./matrix.py
./vrp.py

If you run the klopt_srv you can get the number of open files like this :

count open files
1
2
3
./klopt_srv &
pidof klopt_srv
lsof -p <pid>

The sockets are neatly at the bottom so you can see the list growing by repeatedly running lsof -p. To examine this somewhat closer, i added a counter in the socket code socket.cpp. Now note that there are two sockets opened on every connection, one in Accept(), the client, and one in Connect() the relaying to another service. both of these are closed in the destructor Socket.. code-block::~Socket().

If you print this number in the Connect function it appears neatly at the bottom of the server output. Now start each of the test scripts, you will see it stays just above 0 for the first couple of scripts but it can't take it when matrix and vrp are started as well. Also you will see it fail at 1024 open files.

And indeed if i run ulimit :

change ulimit
ulimit -n
1024

-n is for open files, or run ulimit -a to see all.

The problem is now recognized and fixed. The main loop of the server mounts down to the .. code-block::Wait() function that sets up a select with all the file descriptors involved. So that's socket's just connecting (clients) and sockets waiting for an answer from one of the other servers. The problem was that when select fires it can contain multiple file descriptors (especially when it's busy) that have information, these are all handled in turn but the new connecting clients were handled first.

That means a loop meant accept 10 incoming sockets, and send their request to the server. Then handle incoming answers. But the clients are coming in at a much higher rate then the answers so it keeps opening connections until it reaches 1024. So moving the 'work' section before the 'listen' section makes sure handling work is done before accepting new clients. This does keep the count way down and acts as it should: let clients wait until it's their turn.