docker_daemon_and_networking

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:20 +0000

2016-07-02 - docker daemon and networking

i recently had a problem with docker 1.8.x, on one of the machines. starting daemon caused the following error message:

Error starting daemon: Error initializing network controller: Error creating default "bridge" network: can't find an address range for interface "docker0"

it turns out docker has a problem with parsing network interfaces, when a lot of different routes were setup. in my case there are unusual names of the interfaces, VPN and some other custom routing to multiple networks.

it turned out that starting daemon with explicitly provided network range solved the problem. in /etc/default/docker one must add the following line, to make it work:

DOCKER_OPTS="--bip=172.17.42.1/16"

…which is the default, btw. ;)

gcm_and_signal_private_messenger

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:20 +0000

2016-07-02 - GCM and Signal private messenger

i use signal daily on my phone. recently encrypted communications got delayed. it was notorious to received messages 1-2h old, often in a wrong order. there is a great FAQ about delayed messages issues. there can be a lo of different root causes. usually it boils down to having some services disabled after screen is off. for instance this was the exact problem on my friend's phone. however it did not solved my problem.

there were two interesting things to observe. first was that is happens only when i'm not using Signal – if i do check it every few minutes, i get messages fast or with minimal delay tops. second was that it always work fine on wifi, at home.

it turned out, the problem is how GCM is working. it does open a persistent TCP channel from a phone towards the cloud. it does not however send keep-alives. this means that if you're connected via network, that has statefull firewalls, they can timeout connection tracking, on connections that does nothing for some time. apparently this was the case when connecting via my mobile operator's network, causing connection to get silently (!!) dropped every few minutes. the only way to detect that was to open signal, so that it connects to cloud explicitly and then detects connection is down and reconnects, receiving all the queued messages.

there is an interesting and a very simple hack for this – just send some dummy messages more often than TCP will timeout. there is a simple app for that, called push notifications fixer. it runs in a background and sends dummy data to GCM, in predefined intervals, ensuring the connection is still open. the default timeout is 5 minutes. it did not worked for me though. since usual TCP timeout is set to 3 minutes, i've selected 2 minutes interval and now everything works like a charm!

BaSzErr - blog:2016:07:02

docker_daemon_and_networking

2016-07-02 - docker daemon and networking

gcm_and_signal_private_messenger

2016-07-02 - GCM and Signal private messenger