EVA and WiFi

So I am flying EVA from SIN – TPE – JFK and back. For the first time I also went to the dark side (16hrs was too long to be locked up with just my mind) and got onboard WiFi.

This seems to come with unlimited data for ~20USD for 24hrs. I manage to stream Google Music just fine.

I totally went Matrix mode during the flight. While the flight is half empty I am wondering if they think I am haxoring it now.

EVA uses T-Mobile Germany as carrier.

Public IP routes to a German IP (and Google redirects to Google.de).

nazgul ~ $ curl canhazip.com
88.128.80.215

Whois info:

[…]

inetnum: 88.128.80.0 - 88.128.95.255
netname: ca-de
descr: Telekom Deutschland GmbH
country: DE
admin-c: TH12429-RIPE
tech-c: AS8728-RIPE
tech-c: MS47198-RIPE
remarks: ***************************************************************************
remarks: Please send any abuse complaints to: abuse@telekom.de
remarks: Behoerdenauskuenfte koennen nur ueber folgende Ruf- bzw. Faxnummern beantwortet werden:
remarks: Fax: 0180-18812-66 (0,039 Euro/Minute aus dem Festnetz der Deutschen Telekom AG.)
remarks: Tel.: 0180-18812-77 (0,039 Euro/Minute aus dem Festnetz der Deutschen Telekom AG.)
remarks: ***************************************************************************
status: ASSIGNED PA
mnt-by: MNT-TMD
created: 2008-05-06T07:54:12Z
last-modified: 2012-07-30T08:54:39Z
source: RIPE

Trace routes are quite odd:

nazgul ~ $ traceroute yeri.be
traceroute to yeri.be (83.149.69.152), 64 hops max, 52 byte packets
1 ns.evawifi.com (172.19.248.1) 3.429 ms 2.746 ms 2.921 ms
2 10.207.1.1 (10.207.1.1) 2.998 ms 2.535 ms 2.455 ms
3 172.18.15.41 (172.18.15.41) 553.837 ms 536.711 ms 541.207 ms
4 172.18.14.34 (172.18.14.34) 615.658 ms 534.722 ms 536.465 ms
5 * * *
6 yeri.be (83.149.69.152) 728.306 ms 749.172 ms 738.020 ms
7 yeri.be (83.149.69.152) 743.171 ms 735.898 ms 858.885 ms
8 yeri.be (83.149.69.152) 731.611 ms 764.056 ms 734.694 ms
9 yeri.be (83.149.69.152) 745.765 ms 745.182 ms 729.407 ms
10 yeri.be (83.149.69.152) 745.248 ms 1002.078 ms 750.183 ms
11 yeri.be (83.149.69.152) 901.702 ms 758.616 ms 898.359 ms
12 yeri.be (83.149.69.152) 750.162 ms 779.888 ms 863.083 ms
13 yeri.be (83.149.69.152) 777.654 ms 777.442 ms 750.133 ms
14 yeri.be (83.149.69.152) 745.435 ms 783.786 ms 942.607 ms
15 yeri.be (83.149.69.152) 926.653 ms 939.882 ms 830.519 ms
16 yeri.be (83.149.69.152) 1239.295 ms 754.112 ms 753.986 ms
nazgul ~ $ traceroute google.com
traceroute to google.com (172.217.17.46), 64 hops max, 52 byte packets
1 ns.evawifi.com (172.19.248.1) 1.716 ms 1.200 ms 2.627 ms
2 10.207.1.1 (10.207.1.1) 2.155 ms 1.932 ms 2.165 ms
3 172.18.15.41 (172.18.15.41) 583.366 ms 588.440 ms 730.303 ms
4 172.18.14.34 (172.18.14.34) 552.347 ms 963.682 ms 550.350 ms
5 172.30.1.34 (172.30.1.34) 841.324 ms * 637.136 ms
6 ams16s29-in-f46.1e100.net (172.217.17.46) 752.359 ms 744.614 ms 819.851 ms
7 ams16s29-in-f46.1e100.net (172.217.17.46) 735.554 ms 737.249 ms 785.678 ms
8 ams16s29-in-f46.1e100.net (172.217.17.46) 766.046 ms 738.774 ms 750.276 ms
9 ams16s29-in-f46.1e100.net (172.217.17.46) 817.491 ms 736.133 ms 765.344 ms
10 ams16s29-in-f46.1e100.net (172.217.17.46) 1047.754 ms 754.939 ms *
11 * ams16s29-in-f46.1e100.net (172.217.17.46) 761.013 ms 762.848 ms
12 * ams16s29-in-f46.1e100.net (172.217.17.46) 840.602 ms 750.186 ms
13 ams16s29-in-f46.1e100.net (172.217.17.46) 935.149 ms 808.133 ms 745.638 ms
14 ams16s29-in-f46.1e100.net (172.217.17.46) 736.075 ms 881.481 ms 788.661 ms
15 * * *
16 ams16s29-in-f46.1e100.net (172.217.17.46) 876.269 ms 1195.194 ms 754.661 ms
17 ams16s29-in-f46.1e100.net (172.217.17.46) 749.985 ms 850.065 ms 742.763 ms
18 ams16s29-in-f46.1e100.net (172.217.17.46) 737.418 ms 1079.194 ms 751.415 ms
19 ams16s29-in-f46.1e100.net (172.217.17.46) 765.339 ms 763.116 ms 754.928 ms
20 ams16s29-in-f46.1e100.net (172.217.17.46) 765.059 ms 767.733 ms 762.777 ms
21 ams16s29-in-f46.1e100.net (172.217.17.46) 860.458 ms 780.965 ms 757.507 ms
22 ams16s29-in-f46.1e100.net (172.217.17.46) 768.432 ms 747.930 ms 764.553 ms
23 ams16s29-in-f46.1e100.net (172.217.17.46) 758.869 ms 747.489 ms 751.329 ms
24 ams16s29-in-f46.1e100.net (172.217.17.46) 797.699 ms 818.899 ms *
nazgul ~ $ traceroute t-mobile.de
traceroute to t-mobile.de (46.29.100.15), 64 hops max, 52 byte packets
1 ns.evawifi.com (172.19.248.1) 1.978 ms 1.080 ms 1.071 ms
2 10.207.1.1 (10.207.1.1) 4.575 ms 1.885 ms 1.847 ms
3 172.18.15.41 (172.18.15.41) 540.670 ms 739.430 ms 787.836 ms
4 172.18.14.34 (172.18.14.34) 646.621 ms 775.771 ms 562.301 ms
5 * 172.30.1.34 (172.30.1.34) 630.660 ms *
6 46.29.100.15 (46.29.100.15) 1014.377 ms 813.739 ms 755.431 ms
7 46.29.100.15 (46.29.100.15) 766.290 ms 805.572 ms 735.697 ms
8 46.29.100.15 (46.29.100.15) 806.918 ms 792.377 ms 945.535 ms
9 46.29.100.15 (46.29.100.15) 783.751 ms 736.085 ms 781.832 ms
10 46.29.100.15 (46.29.100.15) 817.682 ms 738.980 ms 1031.463 ms
11 46.29.100.15 (46.29.100.15) 872.993 ms 767.682 ms 807.777 ms
12 46.29.100.15 (46.29.100.15) 986.659 ms 804.279 ms 806.750 ms
13 46.29.100.15 (46.29.100.15) 846.340 ms 767.556 ms 939.215 ms
14 46.29.100.15 (46.29.100.15) 737.330 ms 759.259 ms 786.724 ms
15 * * *
16 * * *

Not very sure what’s witchery is going on here though.

Arp shows AP isolation and two different servers running for the WiFi:

nazgul ~ $ arp -a
ns.evawifi.com (172.19.248.1) at 0:d:2e:0:40:1 on en0 ifscope [ethernet]
www.evawifi.com (172.19.248.2) at 0:d:2e:0:0:a8 on en0 ifscope [ethernet]
? (172.19.249.255) at (incomplete) on en0 ifscope [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (239.192.0.0) at 1:0:5e:40:0:0 on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]

There seems to be a transparant Squid/3.4.6 caching proxy running:

More random things can be found here.

Theme

I had the same theme for over four years. I’ve made quite a few custom css and PHP edits myself, and it had been outdated for ages… But it served me well.

theme-2011

However, it’s now time for something new.

theme-2015

As always, as minimalistic as possible.

On a side note, this blog has been moved from vm1 (and one before that) a virtual machine running on a dual Xeon 3070 (2.66Ghz) at Databarn to Akama, a VM on an 8 core Xeon E3-1230 (3.2Ghz) at Leaseweb.

I’ve also correctly repaired IPv6 on this blog. Apparently nginx never and/or stopped correctly listening to IPv6 (suddenly my Android devices displayed errors on this page, Chrome & Firefox on OS X seemed to fall back to IPv4 instantly… Not sure how long it was broken, but it’s back).

Note to self:

listen          yeri.be:443;
server_name     yeri.be;

Does not work with IPv6, it has to be

listen          [::]:443;
server_name     yeri.be;

Raspberry Pi + ad blocking + nginx

There’s this howto that explains how to set up the RPi as ad blocker.

I’ve two RPi’s acting a router and was already running dnsmasq. I decided to give it a try. Note that this howto can actually be used on any DNS serving Linux server.

First of all, don’t go with the pixelserv as it crashes after a few minutes.

Apache is an option that worked fine. A general hint: if you’re already running Apache or whatever on port 80, just add a 2nd static IP and make Apache listen to that.

For example (/etc/network/interfaces) — be sure it’s in the same subnet:

auto eth0:0
iface eth0:0 inet static
 address 10.100.200.254
 netmask 255.255.255.0
 broadcast 10.100.200.255

10.100.200.254 is the Apache IP that just serves a HTTP 200 (or 204).

Here’s the relevant config part (note the HTTP 204 code, more info on that later):

<VirtualHost adblock:80>
 ServerAdmin webmaster@domain.net
 DocumentRoot /var/www
 <Directory />
 Options FollowSymLinks
 AllowOverride All
 </Directory>
 <Directory /var/www/>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride None
 Order allow,deny
 allow from all
 RewriteEngine on
 RedirectMatch 204 (.*)$
 ErrorDocument 204 " "
 </Directory>

ErrorLog ${APACHE_LOG_DIR}/error.log
 LogLevel warn
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

And edit /etc/hosts to add “adblock”:

10.100.200.254 adblock.local adblock

If I had used the IP instead of adblock I would have had this error:

# apache2ctl configtest
[Mon Sep 16 20:27:21 2013] [error] (EAI 2)Name or service not known: 
Failed to resolve server name for 10.100.200.254 (check DNS) 
-- or specify an explicit ServerName
Syntax OK

With the HTTP 200 code, some browsers expect some content/file in return. So it’s generally safer to use HTTP 204 “No Content“; which basically means “all good but I have nothing to serve you.”

Now, I call myself an nginx fan. Running Apache on a RPi is a no go (at least for me). I could’ve ran nginx on the RPi, but decided to run it on a remote server with an additional IP. At least for now. To preserve resources on the RPi.

Here’s the relevant config to run it on nginx (and be sure this config is the first file nginx parses; or it might redirect all the domains to some other site):

server {
 listen 80;
 server_name pixel.0x04.com 10.100.200.254 _;
 access_log /var/log/nginx/pixel.access.log;
 error_log /var/log/nginx/pixel.error.log;
 expires max;
 autoindex off; 
 rewrite ^(.*)$ /;
 location / {
  return 204 'pixel';
 }
}

And if we test it, this is what we get:

HTTP/1.1 204 No Content
Server: nginx/1.4.0
Date: Mon, 16 Sep 2013 18:36:52 GMT
Connection: close
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000

And that’s it.

<3 nginx

The only downside is that this won’t work with HTTPS. You can run your webbrowser with a self signed certificate, but this will throw errors…

The result:

adblock

413 Request Entity Too Large

Since I started pushing kernel and modules through Puppet (as raw files, instead of .deb packages) I randomly got these errors:

[...]
/usr/lib/ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/1.8/puppet/agent.rb:44:in `run'
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
/usr/lib/ruby/1.8/puppet/agent.rb:44:in `run'
/usr/lib/ruby/1.8/puppet/agent.rb:108:in `with_client'
/usr/lib/ruby/1.8/puppet/agent.rb:42:in `run'
/usr/lib/ruby/1.8/puppet/application.rb:172:in `call'
/usr/lib/ruby/1.8/puppet/application.rb:172:in `controlled_run'
/usr/lib/ruby/1.8/puppet/agent.rb:40:in `run'
/usr/lib/ruby/1.8/puppet/application/agent.rb:337:in `onetime'
/usr/lib/ruby/1.8/puppet/application/agent.rb:311:in `run_command'
/usr/lib/ruby/1.8/puppet/application.rb:309:in `run'
/usr/lib/ruby/1.8/puppet/application.rb:416:in `hook'
/usr/lib/ruby/1.8/puppet/application.rb:309:in `run'
/usr/lib/ruby/1.8/puppet/application.rb:407:in `exit_on_fail'
/usr/lib/ruby/1.8/puppet/application.rb:309:in `run'
/usr/lib/ruby/1.8/puppet/util/command_line.rb:69:in `execute'
/usr/bin/puppet:4
err: Could not send report: Error 413 on SERVER: <html>
<head><title>413 Request Entity Too Large</title></head>
<body bgcolor="white">
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.1.19</center>
</body>
</html>

The error seems quite easy to solve by modifying nginx’ config to allow bigger body sizes.

Edit nginx.conf and add this line:

client_max_body_size 50M;

(I’ve set it to 50M, although that’s probably way to big, but so far I’ve not been able to reproduce this error).

 

nginx: could not build the server_names_hash

I’ve recently started switching my custom nginx installations to the Debian repository version.

So from 0.9.4 to 0.6.32 (Lenny), which will be upgraded to 0.7.x in Squeeze.

I’ve come across this error on certain servers:

# /etc/init.d/nginx restart
Restarting nginx: 2011/02/11 11:34:58 [emerg] 3624#0: could not build the server_names_hash, 
you should increase server_names_hash_bucket_size: 32
nginx.

This can be solved by adding this to the nginx.conf:

server_names_hash_bucket_size 64;

Be sure to place it between the http-section.

[...]
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    server_names_hash_bucket_size 64;

    access_log	/var/log/nginx/access.log;
	
    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;
    tcp_nopush	       on;

    gzip  on;
    gzip_comp_level   5;
    gzip_http_version 1.0;
    gzip_min_length   0;
    gzip_proxied      any;
    gzip_buffers      16 8k;
    # Some version of IE 6 don't handle compression well on some mime-types, 
    # so just disable for them
    gzip_disable "MSIE [1-6].(?!.*SV1)";
    gzip_types        text/plain text/css image/x-icon application/x-javascript text/xml  application/xml application/xml+rss text/javascript image/gif image/jpeg image/png application/json application/x-tar application/zip application/x-rar-compressed application/msword application/octet-stream application/vnd.ms-excel application/pdf application/vnd.ms-powerpoint;
    gzip_vary         on;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}