pterjan's diary

  When faster WiFi means unusable connection

I recently moved home and got FTTC with PlusNet, the speed is good when measuring (almost the advertised 80Mb/20Mb) but the connection was unusable due to TCP connections hanging every few minutes (very annoying with ssh but screen helps, worse when using a website for a payment and needing to retry and trust you will only be charged once).

Yesterday I decided to sit down and investigate. Router has logs which were quite helpful. A lot of things like OUT: BLOCK [9] Packet invalid in connection (Invalid tcp flags for current tcp state: TCP [192.168.1.73]:54426-​>[46.19.168.229]:443 on ppp3)

This followed the laptop being seen moving from interface ath10 to interface ath00 and it was moving back and forth quite often.

Looking at the logs on one of the laptops those switches looked like wlan0: disconnect from AP b8:d9:4d:41:76:fb for new auth to b8:d9:4d:41:76:fa

What happened is that default settings on PlusNet router is to have “identical” 2.4GHz and 5GHz networks so the devices believe they are the same network and switch between AP, but they are actually different and the connection tracking gets reset each time such switch happens.

Disabling the 5GHz network made my connection usable, I could probably just change its settings to make it separate.

  Success

In November 2012 I started running an irregular rebuild of all Mageia packages on x86_64, discarding the built packages, to just detect build breakages.

At first it was running a few times a month, now once a week, except before releases where I run it twice a week.

For the first attempt, on 2012-11-28, we had 10949 packages and 1104 failed to build (10%), by the time of the second attempt 3 weeks later we were down to 6.7% of build failures.

Since then, the distribution has been growing and this has helped detecting packages that needs to be fixed early, really helping for the mass rebuild of each release.

• Mageia 3 was released on 2013-05-01 with 133 failures out of 11008 (1.2%), most of them being random failures due to the use of make -jN.
• Mageia 4 was released on 2014-02-01 with 24 failures out of 11739 (0.2%)
• Mageia 5 was released on 2015-06-20 with 42 failures out of 12455 (0.2%)
• Mageia 6 is going to be released on 2017-07-XX with 0 failures out of 13650 (0%)!

For those interested in the technical details, I am using iurt (the same as we use on Mageia build system) to rebuild everything, creating a new chroot for each package.

I build 16 packages at once, with -j4, on a virtual machine having 32 cores and 200G ram which I use as tmpfs for the builds.

A full rebuild takes about 20 hours.

  Résultats de l’élection présidentielle française 2017 à Londres

Pour une raison inconnue, le site du ministère de l’intérieur ne fournit pas de résultats par commune pour les français de l’étranger, contrairement à la métropole.

Les données étant fournies sur data.gouv.fr mais pas très lisibles, je les avais extraites. Je me suis dit ce matin que ça pourrait intéresser d’autres gens, donc les voici.

  Tuning systemd services

Recently my tor relay started crashing daily. I found out it was because the usage increased (approaching 10MB/s) and every night when logrotate asked it to reload, it failed with:

[May 30 04:02:01.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
May 30 04:02:01.000 [warn] Could not open "/etc/tor/torrc": Too many open files
May 30 04:02:01.000 [warn] Unable to open configuration file "/etc/tor/torrc".
May 30 04:02:01.000 [err] Reading config failed--see warnings above. For usage, try -h.
May 30 04:02:01.000 [warn] Restart failed (config error?). Exiting.
May 30 04:02:01.000 [warn] Couldn't open "/var/lib/tor/state.tmp" (/var/lib/tor/state) for writing: Too many open files

The problems comes from LimitNOFILE=4096 in the service file, and I had no idea how to fix it cleanly.

fcrozat gave me the answer which I'll summarize as:

mkdir /etc/systemd/system/tor.service.d/
echo "[Service]\nLimitNOFILE=16384" > /etc/systemd/system/tor.service.d/limit.conf
systemctl daemon-reload
service tor restart

  OpenLibernet

I saw a link to OpenLibernet and after reading there FAQ I believed there was a fundamental problem. I quickly read the full paper but found no answer.

I guess I have missed something, please explain me :)

A peer address is the hash of a cryptographic public key. It is used to encrypt certain packets as part of the routing protocol, serve as a payment address for the payment system (similar to a Bitcoin’s wallet address), but also serves as a unique identifier for a node, similar to IP Addresses in the current internet.

Also, a node may simply generate a new Peer Address anytime it chooses to.

When the balance of a neighbor hits a certain threshold, a payment request is initiated.

Malicious nodes could however cheat their neighbors and refuse to pay them their due traffic. For that, the protocol is designed to punish such malicious behavior through ostracism. A node will be automatically isolated from the network until it pays all its dues and resolves all conflicts with its neighbors.

What is preventing some malicious node to re-join the network with a new peer address when it is getting close to receiving a payment request, and discard its balance?

The only limitation I see is First, and to eliminate the churn caused by unstable nodes, a Layer 2 link becomes active only after it has been alive for a set amount of time. but this is not a problem is you start another client in parallel when getting close to a payment threshold and switch to the new peer address when it is ready.

  Getting ready for RMLL

RMLL will be in Brussels next week, time to get prepared.

I tried to read the Mobib pass I got during FOSDEM and sent two patches to cardpeek + the new ATR to smartcard_list.txt.

  Mageia 3

Mageia 3 was released last month and the autobuild system I started 6 months ago showed very nice improvements: We went from 89.9% packages building succesfuly (9845/10949) on 2012-11-28 to 99% (10892/10996) on 2013-05-19!

Thanks everyone who helped fixing packages. Goal for Mageia 4: 100%.

  RMLL

I will be attending RMLL in Brussels next month, including Mageia Days. See you there!

  Misc

After being burgled and my landlord requesting a 10% increase of my rent following the 7% last year, I have moved into a new flat in February.

On the negative side, I replaced my 40Mb/10Mb FTTC Sky connection with non working DSL (no dial tone + 1.5Mb/200kb instead of expected ~15Mb on this line). After 3 months trying to get them to fix the line, I'm moving to TalkTalk as they will be sending an engineer to setup my connection for free so I hope he can get something working soon.

On the positive side, I now have a balcony with a view on Battersea power station.

  Thoughts on LSB

Today, during the round table at distro recipes there was a short discussion about LSB usefulness and future. I was not participating but will share my opinion here instead.

Basically, I think xdg-utils from Freedesktop is doing what LSB Desktop should have been.

LSB wants distributions to provide a set of binary API (gtk2, qt3, now also qt4...). I don’t think that’s what vendors need.

Freedesktop provides a set of commands, providing a set of features with very simple API, allowing to easily integrate in any distribution and desktop environment (not even only under Linux).

Distributing the libraries with your application is easy (I think LSB can make sense for things like libc, etc). What vendors want is to integrate with the distribution (appear in the user menu, be associated with mimetypes, be able to start a browser, disable screensaver while the play a movie, get proxy configuration, maybe send an email...) without writing much code.

Freedesktop doesn’t mandate distributions to keep obsolete unmaintained libraries, it just asks them to provide a set of simple commands implementing the features in any way they may desire.

xdg-utils is now required by LSB 4.1 and that’s a good thing, but I believe most vendors are just interested in it, not in the rest of LSB.

  Time to get out of Linkedin?

Today I received some spam from a guy, sent by linkedin (it comes from their servers).

The message had the email address of all the recipients in the To field, meaning they gave away that email address to that random people I don't know! I was annoyed at their password leak, but it seems they deliberately give email addresses away...

Their privacy policy states that Your contact information will only be shared with another User if both of you have indicated that you would like to establish contact with each other. but this is a lie, it will be also shared if someone sends a message to both of you.

I tried to contact them, the first step to prevent it is their infinite scrolling preventing from clicking on the links at the bottom of the page unless you are very fast.

The second problem is their help center (which it seems you have to go through to contact them) which doesn't load "There has been an error with your request.".

  Let's build it all over again... and again

Happy new year everyone. By posting something now I make sure I will post at least one this year :)

During Christmas I have been busy hacking an automated rebuild of Mageia.

I am using a single machine, and building only on x86_64. The machine has 12 cores and 32G ram so I am building 6 packages in parallel with -l12 -j12 on tmpfs, with some swap to prevent very large packages to break the build of others. It takes about 30 hours to build just under 11000 packages, creating a clean chroot each time.

I was happily surprised by the results of the first rebuild, 90.1% success (9845 packages built successfuly), and even more with the second (93.3%) after fixing a few packages breaking many others. I was less happy when the results went down in the recent runs (new version of rpm, new version of automake breaking 304 packages by removing AM_CONFIG_HEADER, %libexec changed to be different from %lib in our rpm config...), but at least we have the number, and better, the list of packages to fix!

Current main problems and limitations:

Ah, and I will be attending FOSDEM as usual, so see you near some Belgian beers!