Jekyll2022-02-20T09:22:49+00:00https://toreanderson.github.io/feed.xml~toreTore Anderson's technology blogTore AndersonIPv6 support in the PlayStation 52021-02-23T00:00:00+00:002021-02-23T00:00:00+00:00https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5<p>Almost five years after I <a href="/2016/06/15/ipv6-support-in-the-playstation-4.html">wrote about the PlayStation 4’s lacklustre IPv6
support</a>, I have finally
managed to get my hands on the PlayStation 5 – and I have of course taken a
close look at its IPv6 capabilities.</p>
<h2 id="does-the-playstation-5-support-ipv6-at-all">Does the PlayStation 5 support IPv6 at all?</h2>
<p>It does indeed! In the <em>View Connection Status</em> page of the network settings,
it displays any assigned IPv6 address, gateway and DNS server; right next to
their IPv4 counterparts.</p>
<p><img src="/images//ipv6-support-in-the-playstation-5/connection-status.jpg" alt="Connection Status" /></p>
<p>This is a clear improvement over the PS4, whose IPv6 support was not
acknowledged by the user interface at all.</p>
<h2 id="what-does-the-the-ps5-use-ipv6-for">What does the the PS5 use IPv6 for?</h2>
<p>Not much, really. I have seen it use IPv6 for the following:</p>
<ul>
<li><code class="language-plaintext highlighter-rouge">IN AAAA</code> DNS queries.</li>
<li>A HTTP <code class="language-plaintext highlighter-rouge">GET</code> request towards <code class="language-plaintext highlighter-rouge">http://ena.net.playstation.net/netstart/ps4</code>
<em>[sic]</em> immediately after connecting to the network. The response from the
server is <code class="language-plaintext highlighter-rouge">403 Forbidden</code>. As I observed back in 2016, the PS4 did the exact
same thing.</li>
<li>HTTPS requests towards <code class="language-plaintext highlighter-rouge">https://image.api.playstation.com</code> while browsing the
PlayStation Store app.</li>
<li>The Netflix app uses IPv6 for both API/metadata and video traffic.
Interestingly enough the Netflix app appears to use its own built-in stub
resolver with 8.8.8.8 as its upstream, so its <code class="language-plaintext highlighter-rouge">IN AAAA</code> queries are using
IPv4 transport.</li>
</ul>
<p>I have also seen it perform <code class="language-plaintext highlighter-rouge">IN AAAA</code> DNS queries for several IPv4-only
<code class="language-plaintext highlighter-rouge">*.playstation.com</code> and <code class="language-plaintext highlighter-rouge">*.playstation.net</code> domain names.</p>
<p>Some other things that appear to be IPv4-only include:</p>
<ul>
<li><code class="language-plaintext highlighter-rouge">IN A</code> DNS queries.</li>
<li>Logging in to the PlayStation Network.</li>
<li>Browsing the PlayStation Store (except for images as previously noted).</li>
<li>Downloading games and media apps from the PlayStation Store.</li>
<li>Syncing game trophy lists.</li>
<li>Playing videos with the NRK TV, Twitch and YouTube media apps.</li>
<li>Online multiplayer with Fortnite.</li>
<li>The built-in Internet speed test.</li>
</ul>
<h2 id="technical-implementation-details">Technical implementation details</h2>
<ul>
<li>It does not realy support IPv6-only networks. If there’s no DHCPv4 service on
the network, it will claim that the network connection failed. But Netflix
works regardless, see below.</li>
<li>It supports SLAAC, the RA <em>RDNSS Option</em> and DHCPv6 – both stateful and
stateless.</li>
<li>If no IPv6 DNS server is being provided by the RA <em>RDNSS Option</em> or DHCPv6 it
will not configure IPv6 addressing or routing either. This is probably
because…</li>
<li>…it uses its IPv4 DNS server for all <code class="language-plaintext highlighter-rouge">IN A</code> DNS queries, and its IPv6 DNS
server for all <code class="language-plaintext highlighter-rouge">IN AAAA</code> queries.</li>
<li>When using SLAAC, the Interface ID appears to be randomised and changes on
every reconnect.</li>
<li>If <code class="language-plaintext highlighter-rouge">OnLink=0</code> is present in the RA <em>Prefix Information Option</em>, it will not
configure an address using SLAAC even though <code class="language-plaintext highlighter-rouge">Autonomous=1</code>. This is probably
a bug.</li>
<li>If <code class="language-plaintext highlighter-rouge">Managed=1</code> in the RA, it will use stateful DHCPv6 to obtain an address
using <code class="language-plaintext highlighter-rouge">IA_NA</code>. It will also request DNS servers in the same exchange.</li>
<li>Stateful DHCPv6 address assignment through <code class="language-plaintext highlighter-rouge">IA_NA</code> works fine even though
there is no <em>Prefix Information Option</em> in the RAs.</li>
<li>If addresses are available from both stateful DHCPv6 and SLAAC, it will
prefer the one from DHCPv6. The UI only shows a single globally scoped IPv6
address.</li>
<li>If <code class="language-plaintext highlighter-rouge">Managed=0</code> and <code class="language-plaintext highlighter-rouge">OtherConfig=1</code> in the RA, it will use stateless DHCPv6 to
obtain DNS servers.</li>
<li>If <code class="language-plaintext highlighter-rouge">OtherConfig=1</code>, it will prefer DNS servers learned from DHCPv6 over any
learned from the RA RDNSS Option. If <code class="language-plaintext highlighter-rouge">OtherConfig=0</code>, the opposite is true.</li>
</ul>
<p>The PS5 was running system software version 20.02-2.50.00.08-00.00.00.0.1
during my testing.</p>
<h2 id="ipv6-only-and-dns64nat64">IPv6-only and DNS64/NAT64</h2>
<p>If there is no DHCPv4 service on the LAN, the network settings UI will say
<strong>Failed</strong> for both <em>Wired LAN 1</em> and <em>Internet connection</em>. In spite of that,
the <em>View Connection Status</em> page does show an IPv6 address, DNS server and
gateway. Not much work in this state, I mostly encounter errors saying <em>You’re
offline</em>, <em>No Internet connection available</em>, and so forth. The exception is the
Netflix app, which continues to work just fine! (It is now using the system IPv6
DNS server instead of 8.8.8.8.)</p>
<p>If I keep DHCPv4 disabled but start advertising a DNS64-enabled DNS server, the
PS5 still claims that <em>Wired LAN 1</em> and <em>Internet connection</em> is <strong>Failed</strong>.
However the <em>View PlayStation Network Status</em> page has begun working (this is
just an embed of
<a href="https://status.playstation.com">https://status.playstation.com</a>). Twitch also
starts working (using NAT64 for its Internet traffic). Fortnite, NRK TV,
PlayStation Store and YouTube, on the other hand, still do not work.</p>
<p>Lastly, if I re-enable DHCPv4 while leaving DNS64/NAT64 in place, it does not
seem to be using IPv6 via NAT64 for much. PlayStation Store downloads, Fortnite,
NRK TV and YouTube continue to use IPv4 only.</p>
<h2 id="conclusion">Conclusion</h2>
<p>The PS5 does support IPv6, and the Netflix app proves that IPv6 connectivity is
available for use. Apart from Netflix, though, there is not much use of IPv6.
That goes both for the system software and its bundled apps, as well as for
third-party apps and games.</p>
<p>Some of that might be attributable to a lack of IPv6 support on the server side,
as evidenced by <code class="language-plaintext highlighter-rouge">IN AAAA</code> queries for hostnames that have no IPv6 addresses. On
the other hand, when I use DNS64 to make those <code class="language-plaintext highlighter-rouge">IN AAAA</code> queries be answered, it
doesn’t really make much of a difference – IPv4 is still preferred most of the
time.</p>
<p>Furthermore, most of the PS5 apps and games I tested do not make any <code class="language-plaintext highlighter-rouge">IN AAAA</code>
queries in the first place, so DNS64/NAT64 would not help in any case.</p>
<p>Thus software upgrades would be necessary to make these apps and games fully
IPv6 capable. The YouTube app is a good example of this; it is well known that
the YouTube servers supports IPv6, but their PS5 app never issues any <code class="language-plaintext highlighter-rouge">IN AAAA</code>
queries, so it ends up using IPv4 for its video traffic.</p>Tore AndersonAlmost five years after I wrote about the PlayStation 4’s lacklustre IPv6 support, I have finally managed to get my hands on the PlayStation 5 – and I have of course taken a close look at its IPv6 capabilities.HP Z32 «ghost» USB device causing automatic wake from suspend2020-11-09T00:00:00+00:002020-11-09T00:00:00+00:00https://toreanderson.github.io/2020/11/09/hp-z32-ghost-usb-device<p>I recently upgraded my forced home office with an <a href="https://www8.hp.com/emea_middle_east/en/monitors/product-details/18269284">HP Z32</a> 4K UHD monitor. The display panel itself is everything I hoped it would be, a terrific improvement over my ageing FHD monitor.</p>
<p>That said, I have noticed an apparent bug in the monitor’s built-in USB hub. When the upstream USB-C port is connected to my laptop (a <a href="https://support.hp.com/emea_middle_east-en/product/HP-EliteBook-820-G4-Notebook-PC/11122281/model/11122282">HP EliteBook 820 G4</a>) using the included USB-C↔USB-C cable, the Linux kernel detects a <em>«ghost»</em> device that cannot be properly enabled. After each power-on or resume from suspend, the following is logged:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>[ 1081.785820] kernel: usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[ 1085.857814] kernel: usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[ 1090.121887] kernel: usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[ 1090.121980] kernel: usb usb2-port3: attempt power cycle
[ 1094.505745] kernel: usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[ 1098.578533] kernel: usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[ 1098.578716] kernel: usb usb2-port3: unable to enumerate USB device
</code></pre></div></div>
<p>The message appear even when there are no USB devices connected to the external downstream ports on the monitor, so whatever this <em>«ghost»</em> device is, it is probably something connected to an internal port.</p>
<p>Annoyingly enough, the <em>«ghost»</em> device causes the laptop to wake from suspend by itself immediately after suspending it in the first place. That is, if I suspend the laptop, it will <em>ostensibly</em> go to sleep, but wake up again after a second or two. If I at this point quickly suspend it again, it will stay asleep.</p>
<p>In order for the second suspend attempt to be successful, it must be issued <em>before</em> the <code class="language-plaintext highlighter-rouge">unable to enumerate USB device</code> message appears. That gives me a window of approximately 15 seconds after the automatic wake-up.</p>
<p>A workaround is to use a USB-A↔USB-C cable to connect the laptop to the monitor instead. This makes suspend work reliably, and the error messages from the kernel no longer appear. However, this workaround does of course preclude the use of display output and charging via USB-C, features I certainly hope to be able to use when I upgrade my laptop next year.</p>
<p>Windows 10 is able to reliably suspend the laptop regardless of which USB cable is used, so there is probably a way to work around the problem in software too. I will update this post if I figure something out.</p>
<p>In any case, if you have a HP Z-series monitor and are having the same issue (or even if you are <em>not</em>), I would be very happy to hear from you! Send me an e-mail or a Tweet; my contact details are found at the bottom of the page.</p>
<p>For what it is worth, I also <a href="https://h30434.www3.hp.com/t5/Desktop-Video-Display-and-Touch/Ghost-device-connected-to-Z32-built-in-USB-hub-causing/m-p/7847876">wrote a post about this issue</a> on the HP support forum.</p>Tore AndersonI recently upgraded my forced home office with an HP Z32 4K UHD monitor. The display panel itself is everything I hoped it would be, a terrific improvement over my ageing FHD monitor.IPv6 roaming in Romania2020-04-13T00:00:00+00:002020-04-13T00:00:00+00:00https://toreanderson.github.io/2020/04/13/ipv6-roaming-in-romania<p>I am currently in Romania, Corona-stranded and rather bored. To kill some time, I decided to <a href="https://github.com/toreanderson/3gpptest">hack together a script</a> that performs automated testing of IPv6 capability in all available <a href="https://en.wikipedia.org/wiki/Public_land_mobile_network">PLMNs</a> and use it with SIM cards from three different IPv6-capable PLMNs (<a href="https://www.orange.pl">🇵🇱 Orange</a>, <a href="https://www.tele2.se">🇸🇪 Tele2</a> and <a href="https://www.telenor.no">🇳🇴 Telenor</a>).</p>
<h2 id="tldr">tl;dr</h2>
<p>🤷♂️ <a href="https://www.digiromania.ro">Digi</a><br />
✅ <a href="https://www.orange.ro">Orange</a><br />
✅ <a href="https://www.telekom.ro">Telekom</a><br />
❌ <a href="https://www.vodafone.ro">Vodafone</a></p>
<p>Requesting a dual-stack <code class="language-plaintext highlighter-rouge">IPv4v6</code> bearer always succeeds, but the resulting connectivity is sometimes IPv4-only.</p>
<h2 id="test-results">Test results</h2>
<p>Click the links in the <strong>Tech</strong> column to be taken directly to the corresponding output from my test script, and make sure to check out the footnotes for more information and explanations.</p>
<h3 id="digi-mccmnc-22605">Digi (MCCMNC 22605)</h3>
<table>
<thead>
<tr>
<th>SIM card</th>
<th>Tech</th>
<th>IPv4v6</th>
<th>IPv6</th>
</tr>
</thead>
<tbody>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L35-L37">LTE</a></td>
<td>📵 <sup id="fnref:noreg" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
<td>📵 <sup id="fnref:noreg:1" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
</tr>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L84-L86">UMTS</a></td>
<td>📵 <sup id="fnref:noreg:2" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
<td>📵 <sup id="fnref:noreg:3" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L35-L37">LTE</a></td>
<td>📵 <sup id="fnref:noreg:4" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
<td>📵 <sup id="fnref:noreg:5" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L84-L86">UMTS</a></td>
<td>📵 <sup id="fnref:noreg:6" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup> <sup id="fnref:modembug" role="doc-noteref"><a href="#fn:modembug" class="footnote" rel="footnote">2</a></sup></td>
<td>📵 <sup id="fnref:noreg:7" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup> <sup id="fnref:modembug:1" role="doc-noteref"><a href="#fn:modembug" class="footnote" rel="footnote">2</a></sup></td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L54-L56">LTE</a></td>
<td>📵 <sup id="fnref:noreg:8" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
<td>📵 <sup id="fnref:noreg:9" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L103-L105">UMTS</a></td>
<td>📵 <sup id="fnref:noreg:10" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
<td>📵 <sup id="fnref:noreg:11" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
</tr>
</tbody>
</table>
<h3 id="orange-mccmnc-22610">Orange (MCCMNC 22610)</h3>
<table>
<thead>
<tr>
<th>SIM card</th>
<th>Tech</th>
<th>IPv4v6</th>
<th>IPv6</th>
</tr>
</thead>
<tbody>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L39-L60">LTE</a></td>
<td>✅ <sup id="fnref:2bearers" role="doc-noteref"><a href="#fn:2bearers" class="footnote" rel="footnote">3</a></sup></td>
<td>✅</td>
</tr>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L111-L132">UMTS</a></td>
<td>✅ <sup id="fnref:2bearers:1" role="doc-noteref"><a href="#fn:2bearers" class="footnote" rel="footnote">3</a></sup></td>
<td>✅</td>
</tr>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L179-L200">GSM</a></td>
<td>✅ <sup id="fnref:2bearers:2" role="doc-noteref"><a href="#fn:2bearers" class="footnote" rel="footnote">3</a></sup></td>
<td>✅</td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L39-L60">LTE</a></td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L92-L109">UMTS</a></td>
<td>4️⃣ <sup id="fnref:v4fallback" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause33" role="doc-noteref"><a href="#fn:cause33" class="footnote" rel="footnote">5</a></sup></td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L137-L154">GSM</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:1" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause33:1" role="doc-noteref"><a href="#fn:cause33" class="footnote" rel="footnote">5</a></sup></td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L58-L79">LTE</a></td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L126-L147">UMTS</a></td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L190-L211">GSM</a></td>
<td>✅</td>
<td>✅</td>
</tr>
</tbody>
</table>
<h3 id="telekom-mccmncs-22603-and-22606">Telekom (MCCMNCs 22603 and 22606)</h3>
<table>
<thead>
<tr>
<th>SIM card</th>
<th>Tech</th>
<th>IPv4v6</th>
<th>IPv6</th>
</tr>
</thead>
<tbody>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L31-L33">LTE</a></td>
<td>📵 <sup id="fnref:noreg:12" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
<td>📵 <sup id="fnref:noreg:13" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
</tr>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L88-L109">UMTS</a></td>
<td>✅ <sup id="fnref:2bearers:3" role="doc-noteref"><a href="#fn:2bearers" class="footnote" rel="footnote">3</a></sup></td>
<td>✅</td>
</tr>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L156-L177">GSM</a></td>
<td>✅ <sup id="fnref:2bearers:4" role="doc-noteref"><a href="#fn:2bearers" class="footnote" rel="footnote">3</a></sup></td>
<td>✅</td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L31-L33">LTE</a></td>
<td>📵 <sup id="fnref:noreg:14" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
<td>📵 <sup id="fnref:noreg:15" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L88-L90">UMTS</a></td>
<td>📵 <sup id="fnref:noreg:16" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
<td>📵 <sup id="fnref:noreg:17" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L133-L135">GSM</a></td>
<td>📵 <sup id="fnref:noreg:18" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
<td>📵 <sup id="fnref:noreg:19" role="doc-noteref"><a href="#fn:noreg" class="footnote" rel="footnote">1</a></sup></td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L31-L52">LTE</a></td>
<td>✅ <sup id="fnref:2bearers:5" role="doc-noteref"><a href="#fn:2bearers" class="footnote" rel="footnote">3</a></sup></td>
<td>✅</td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L107-L124">UMTS</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:2" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause33:2" role="doc-noteref"><a href="#fn:cause33" class="footnote" rel="footnote">5</a></sup></td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L171-L188">GSM</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:3" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause33:3" role="doc-noteref"><a href="#fn:cause33" class="footnote" rel="footnote">5</a></sup></td>
</tr>
</tbody>
</table>
<h3 id="vodafone-mccmnc-22601">Vodafone (MCCMNC 22601)</h3>
<table>
<thead>
<tr>
<th>SIM card</th>
<th>Tech</th>
<th>IPv4v6</th>
<th>IPv6</th>
</tr>
</thead>
<tbody>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L12-L29">LTE</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:4" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause32" role="doc-noteref"><a href="#fn:cause32" class="footnote" rel="footnote">6</a></sup></td>
</tr>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L65-L82">UMTS</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:5" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause32:1" role="doc-noteref"><a href="#fn:cause32" class="footnote" rel="footnote">6</a></sup></td>
</tr>
<tr>
<td>🇵🇱 Orange</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_26003-Orange-Poland.txt#L137-L154">GSM</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:6" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause32:2" role="doc-noteref"><a href="#fn:cause32" class="footnote" rel="footnote">6</a></sup></td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L12-L29">LTE</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:7" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause32:3" role="doc-noteref"><a href="#fn:cause32" class="footnote" rel="footnote">6</a></sup></td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L65-L82">UMTS</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:8" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause33:4" role="doc-noteref"><a href="#fn:cause33" class="footnote" rel="footnote">5</a></sup></td>
</tr>
<tr>
<td>🇸🇪 Tele2</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24007-Tele2-Sweden.txt#L114-L131">GSM</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:9" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause33:5" role="doc-noteref"><a href="#fn:cause33" class="footnote" rel="footnote">5</a></sup></td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L12-L29">LTE</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:10" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause32:4" role="doc-noteref"><a href="#fn:cause32" class="footnote" rel="footnote">6</a></sup></td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L84-L101">UMTS</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:11" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause32:5" role="doc-noteref"><a href="#fn:cause32" class="footnote" rel="footnote">6</a></sup></td>
</tr>
<tr>
<td>🇳🇴 Telenor</td>
<td><a href="https://github.com/toreanderson/3gpptest/blob/master/results/romania/2020-04_24201-Telenor-Norway.txt#L152-L169">GSM</a></td>
<td>4️⃣ <sup id="fnref:v4fallback:12" role="doc-noteref"><a href="#fn:v4fallback" class="footnote" rel="footnote">4</a></sup></td>
<td>❌ <sup id="fnref:cause32:6" role="doc-noteref"><a href="#fn:cause32" class="footnote" rel="footnote">6</a></sup></td>
</tr>
</tbody>
</table>
<h2 id="footnotes">Footnotes</h2>
<div class="footnotes" role="doc-endnotes">
<ol>
<li id="fn:noreg" role="doc-endnote">
<p>I was unable to register in this PLMN (probably because there is no roaming agreement with the SIM card operator), so it was impossible to test. <a href="#fnref:noreg" class="reversefootnote" role="doc-backlink">↩</a> <a href="#fnref:noreg:1" class="reversefootnote" role="doc-backlink">↩<sup>2</sup></a> <a href="#fnref:noreg:2" class="reversefootnote" role="doc-backlink">↩<sup>3</sup></a> <a href="#fnref:noreg:3" class="reversefootnote" role="doc-backlink">↩<sup>4</sup></a> <a href="#fnref:noreg:4" class="reversefootnote" role="doc-backlink">↩<sup>5</sup></a> <a href="#fnref:noreg:5" class="reversefootnote" role="doc-backlink">↩<sup>6</sup></a> <a href="#fnref:noreg:6" class="reversefootnote" role="doc-backlink">↩<sup>7</sup></a> <a href="#fnref:noreg:7" class="reversefootnote" role="doc-backlink">↩<sup>8</sup></a> <a href="#fnref:noreg:8" class="reversefootnote" role="doc-backlink">↩<sup>9</sup></a> <a href="#fnref:noreg:9" class="reversefootnote" role="doc-backlink">↩<sup>10</sup></a> <a href="#fnref:noreg:10" class="reversefootnote" role="doc-backlink">↩<sup>11</sup></a> <a href="#fnref:noreg:11" class="reversefootnote" role="doc-backlink">↩<sup>12</sup></a> <a href="#fnref:noreg:12" class="reversefootnote" role="doc-backlink">↩<sup>13</sup></a> <a href="#fnref:noreg:13" class="reversefootnote" role="doc-backlink">↩<sup>14</sup></a> <a href="#fnref:noreg:14" class="reversefootnote" role="doc-backlink">↩<sup>15</sup></a> <a href="#fnref:noreg:15" class="reversefootnote" role="doc-backlink">↩<sup>16</sup></a> <a href="#fnref:noreg:16" class="reversefootnote" role="doc-backlink">↩<sup>17</sup></a> <a href="#fnref:noreg:17" class="reversefootnote" role="doc-backlink">↩<sup>18</sup></a> <a href="#fnref:noreg:18" class="reversefootnote" role="doc-backlink">↩<sup>19</sup></a> <a href="#fnref:noreg:19" class="reversefootnote" role="doc-backlink">↩<sup>20</sup></a></p>
</li>
<li id="fn:modembug" role="doc-endnote">
<p>Trying to register in the UMTS Digi PLMN with my 🇸🇪 Tele2 SIM card apears to trigger a bug in my modem. After such an attempt (which timed out in any case), it would be unable to register in <em>any</em> LTE PLMN and be unable to attach packet service in <em>any</em> UMTS or GSM PLMN (even though registration went fine). The modem had to be rebooted with <code class="language-plaintext highlighter-rouge">AT+MSO=0</code> in order to start working again. I therefore had to manually make my script skip the Digi PLMN while testing with 🇸🇪 Tele2. <a href="#fnref:modembug" class="reversefootnote" role="doc-backlink">↩</a> <a href="#fnref:modembug:1" class="reversefootnote" role="doc-backlink">↩<sup>2</sup></a></p>
</li>
<li id="fn:2bearers" role="doc-endnote">
<p>Automatic fallback from a single dual-stack <code class="language-plaintext highlighter-rouge">IPv4v6</code> bearer to dual single-stack <code class="language-plaintext highlighter-rouge">IP</code>(v4)+<code class="language-plaintext highlighter-rouge">IPv6</code> bearers appears to take place. I can spot this happening because the modem only reports IP config for a single stack even though both actually work. 🇵🇱 Orange is known to not support the dual-stack <code class="language-plaintext highlighter-rouge">IPv4v6</code> bearer, so this is the expected behaviour. As for 🇳🇴 Telenor, I do not know if they perform <a href="https://tools.ietf.org/html/rfc7445#section-3">IPv4v6 subscriber capability filtering</a> or if Telekom do not support/block <code class="language-plaintext highlighter-rouge">IPv4v6</code> bearers. <a href="#fnref:2bearers" class="reversefootnote" role="doc-backlink">↩</a> <a href="#fnref:2bearers:1" class="reversefootnote" role="doc-backlink">↩<sup>2</sup></a> <a href="#fnref:2bearers:2" class="reversefootnote" role="doc-backlink">↩<sup>3</sup></a> <a href="#fnref:2bearers:3" class="reversefootnote" role="doc-backlink">↩<sup>4</sup></a> <a href="#fnref:2bearers:4" class="reversefootnote" role="doc-backlink">↩<sup>5</sup></a> <a href="#fnref:2bearers:5" class="reversefootnote" role="doc-backlink">↩<sup>6</sup></a></p>
</li>
<li id="fn:v4fallback" role="doc-endnote">
<p>Successful automatic fallback from <code class="language-plaintext highlighter-rouge">IPv4v6</code> to <code class="language-plaintext highlighter-rouge">IPv4</code>, likely due to <code class="language-plaintext highlighter-rouge">IPv4v6</code> and <code class="language-plaintext highlighter-rouge">IPv6</code> not working. <a href="#fnref:v4fallback" class="reversefootnote" role="doc-backlink">↩</a> <a href="#fnref:v4fallback:1" class="reversefootnote" role="doc-backlink">↩<sup>2</sup></a> <a href="#fnref:v4fallback:2" class="reversefootnote" role="doc-backlink">↩<sup>3</sup></a> <a href="#fnref:v4fallback:3" class="reversefootnote" role="doc-backlink">↩<sup>4</sup></a> <a href="#fnref:v4fallback:4" class="reversefootnote" role="doc-backlink">↩<sup>5</sup></a> <a href="#fnref:v4fallback:5" class="reversefootnote" role="doc-backlink">↩<sup>6</sup></a> <a href="#fnref:v4fallback:6" class="reversefootnote" role="doc-backlink">↩<sup>7</sup></a> <a href="#fnref:v4fallback:7" class="reversefootnote" role="doc-backlink">↩<sup>8</sup></a> <a href="#fnref:v4fallback:8" class="reversefootnote" role="doc-backlink">↩<sup>9</sup></a> <a href="#fnref:v4fallback:9" class="reversefootnote" role="doc-backlink">↩<sup>10</sup></a> <a href="#fnref:v4fallback:10" class="reversefootnote" role="doc-backlink">↩<sup>11</sup></a> <a href="#fnref:v4fallback:11" class="reversefootnote" role="doc-backlink">↩<sup>12</sup></a> <a href="#fnref:v4fallback:12" class="reversefootnote" role="doc-backlink">↩<sup>13</sup></a></p>
</li>
<li id="fn:cause33" role="doc-endnote">
<p>Failed with 3GPP cause code 33: <em>service not activated</em>. Likely due to <a href="https://tools.ietf.org/html/rfc7445#section-3">IPv6 subscriber capability filtering performed by the SIM card </a>. <a href="#fnref:cause33" class="reversefootnote" role="doc-backlink">↩</a> <a href="#fnref:cause33:1" class="reversefootnote" role="doc-backlink">↩<sup>2</sup></a> <a href="#fnref:cause33:2" class="reversefootnote" role="doc-backlink">↩<sup>3</sup></a> <a href="#fnref:cause33:3" class="reversefootnote" role="doc-backlink">↩<sup>4</sup></a> <a href="#fnref:cause33:4" class="reversefootnote" role="doc-backlink">↩<sup>5</sup></a> <a href="#fnref:cause33:5" class="reversefootnote" role="doc-backlink">↩<sup>6</sup></a></p>
</li>
<li id="fn:cause32" role="doc-endnote">
<p>Failed with 3GPP cause code 32: <em>service option not supported</em>. Likely an intentional block by Vodafone. 😠 <a href="#fnref:cause32" class="reversefootnote" role="doc-backlink">↩</a> <a href="#fnref:cause32:1" class="reversefootnote" role="doc-backlink">↩<sup>2</sup></a> <a href="#fnref:cause32:2" class="reversefootnote" role="doc-backlink">↩<sup>3</sup></a> <a href="#fnref:cause32:3" class="reversefootnote" role="doc-backlink">↩<sup>4</sup></a> <a href="#fnref:cause32:4" class="reversefootnote" role="doc-backlink">↩<sup>5</sup></a> <a href="#fnref:cause32:5" class="reversefootnote" role="doc-backlink">↩<sup>6</sup></a> <a href="#fnref:cause32:6" class="reversefootnote" role="doc-backlink">↩<sup>7</sup></a></p>
</li>
</ol>
</div>Tore AndersonI am currently in Romania, Corona-stranded and rather bored. To kill some time, I decided to hack together a script that performs automated testing of IPv6 capability in all available PLMNs and use it with SIM cards from three different IPv6-capable PLMNs (🇵🇱 Orange, 🇸🇪 Tele2 and 🇳🇴 Telenor).Evaluating ice2020-02-03T00:00:00+00:002020-02-03T00:00:00+00:00https://toreanderson.github.io/2020/02/03/evaluating-ice<p>The newest <a href="https://en.wikipedia.org/wiki/Public_land_mobile_network">PLMN</a> in
Norway is <a href="https://ice.no">ice</a>. I had heard rumours that they supported IPv6,
so I decided to order a subscription to try them out for myself.</p>
<h1 id="ipv6-support">IPv6 support</h1>
<p>IPv6 did unfortunately not work out of the box on my Android 10 phone. The
reason was that the <em>APN protocol</em> and <em>APN roaming protocol</em> settings were set
to <strong>IPv4</strong> by default. That is very unfortunate, as it ascertains that
essentially none of their customers will actually use IPv6.</p>
<p>That said, IPv6 started working fine after I changed those settings to
<strong>IPv4/IPv6</strong>, as demonstrated by a quick visit to
<a href="http://test-ipv6.com">test-ipv6.com</a>:</p>
<p><img src="/images//evaluating-ice/figure1.png" alt="Figure 1: test-ipv6.com screenshot" /></p>
<p>IPv6 also worked just fine in my Linux laptop:</p>
<div class="language-console highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="gp">[:~] $</span><span class="w"> </span>mmcli <span class="nt">-b</span> 10
<span class="go"> --------------------------------
General | dbus path: /org/freedesktop/ModemManager1/Bearer/10
| type: default
--------------------------------
Status | connected: yes
| suspended: no
| interface: wwp0s20f0u3c3
| ip timeout: 20
--------------------------------
Properties | apn: ice.net
| roaming: allowed
| ip type: ipv4v6
--------------------------------
IPv4 configuration | method: static
| address: 100.83.189.109
| prefix: 30
| gateway: 100.83.189.110
| dns: 185.83.167.68, 185.83.167.4
| mtu: 1500
--------------------------------
IPv6 configuration | method: static
| address: 2a05:9cc4:7e:85fb:5a2c:80ff:fe13:9208
| prefix: 64
| gateway: ::
| dns: 2a05:9cc4:f000:1::4, 2a05:9cc3:f000:1::4
| mtu: 1500
--------------------------------
Statistics | duration: 30
</span></code></pre></div></div>
<p>As shown above, ice are using Carrier-grade NAT with IPv4 addresses assigned
from <a href="https://tools.ietf.org/html/rfc6598">RFC 6598</a> space. I can not fault
them for that, given that there are <a href="https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-run-out">no new public IPv4 addresses to be had
from the RIPE NCC</a>.</p>
<p>The IPv6 address is public, as expected. I can ping it from external sources
using ICMPv6, but it appears that all other externally initiated IPv6 traffic
is blocked somewhere inside ice’s core network. This is true for their mobile
broadband APN <code class="language-plaintext highlighter-rouge">internet</code> as well, unfortunately. This overzealous firewalling
means that the usefulness of IPv6 in mobile broadband and IoT use cases is
unnecessarily limited.</p>
<h1 id="mobile-broadband-wifi-router-mandatory">Mobile broadband: wifi router mandatory</h1>
<p>One of the reasons I wanted to evaluate ice was to see if their offerings were
suitable for a mobile broadband IoT project I manage at work. (They were not,
due to their IPv6 firewalling.)</p>
<p>However, while investigating this I noticed something I found rather odd,
namely that ice do not allow their customers to <a href="https://www.ice.no/mobilt-bredband/">order mobile broadband
subscriptions</a> without also purchasing a
wireless router from them.</p>
<p>I have zero use for a wireless router; the IoT devices I was considering them
for all have built-in LTE modems. So does my laptop, for that matter. Why ice
do not offer a SIM card-only mobile broadband subscription is beyond my
comprehension. Hopefully they will do so in the future.</p>
<h1 id="gdpr-violations">GDPR violations</h1>
<p>After I logged in to the online customer portal for the first time, I noticed
this interesting section on my profile page:</p>
<p><img src="/images//evaluating-ice/figure2.png" alt="Figure 2: Consents section in portal" /></p>
<p>This basically states that I have given consents (Norwegian: <em>samtykker</em>) to
two different categories of marketing as well as to customer surveys. I am
certain, however, that I was never asked to consent to any of these while
signing up as a subscriber - thus making this a clear violation of <a href="https://eur-lex.europa.eu/eli/reg/2016/679/oj#d1e2001-1-1">Article 7
GDPR</a>.</p>
<p>I certainly do not appreciate companies not treating my personal data
responsibly according to the GDPR, so I promptly sent a request to ice’s data
protection officer, requesting that they document when and how I gave these
alleged consents. It shall be interesting to see what they answer.</p>toreThe newest PLMN in Norway is ice. I had heard rumours that they supported IPv6, so I decided to order a subscription to try them out for myself.IPv6 on Get FTTH2020-01-11T00:00:00+00:002020-01-11T00:00:00+00:00https://toreanderson.github.io/2020/01/11/get-ipv6-ftth<p><a href="https://www.get.no">Get</a> (<a href="https://www.telia.no">Telia</a>’s fixed broadbrand
brand in Norway) has recently launched an opt-in IPv6 pilot available to their
their fibre customers. I am happy to report that it works great and scores 10/10
on <a href="https://test-ipv6.com">test-ipv6.com</a>.</p>
<p>I first learned about this in <a href="https://www.digi.no/artikler/innsikt-har-du-bare-gammeldags-internett-her-er-ipv6-planene-til-flere-norske-internettleverandorer/480306?key=Phnt5PTg">this
article</a>
(Norwegian), where Get states that they provide IPv6 to a handful of test
customers on fibre.</p>
<p>To join the pilot I simply had to ask their customer service. Shortly after I
received an e-mail with the new configuration settings: static IPv4 /30 and IPv6
/64 WAN link networks plus a static IPv6 /56 prefix for use on the LAN side.
(They do not use Neighbour Discovery or DHCPv6 for automatic configuration.)</p>
<p>My understanding is that Get can currently not configure their own CPE to act as
an IPv6 router, so it is necessary to bring your own HGW and leave the Get CPE
in bridge mode.</p>
<p>I am very happy to have native IPv6 at home again, and really hope that Get will
roll this out to all of their other FTTH customers in the near future.</p>toreGet (Telia’s fixed broadbrand brand in Norway) has recently launched an opt-in IPv6 pilot available to their their fibre customers. I am happy to report that it works great and scores 10/10 on test-ipv6.com.A rack switch removal ordeal2019-08-06T00:00:00+00:002019-08-06T00:00:00+00:00https://toreanderson.github.io/2019/08/06/rack-switch-removal<p>I recently needed to remove a couple of decommissioned switches from one of our
data centres. This turned out to be quite an ordeal. The reason? The
ill-conceived way the rack mount brackets used by most data centre switches are
designed. In this post, I will use plenty of pictures to explain why that is,
and propose a simple solution on how the switch manufacturers can improve this
in future.</p>
<h1 id="rack-switch-mounting-101">Rack switch mounting 101</h1>
<p><img src="/images//rack-switch-removal/switch.jpg" alt="Standard rack-mount
switch" /></p>
<p>The picture above displays a <a href="https://www.juniper.net/us/en/products-services/switching/ex-series/ex4600/">Juniper EX
4600</a>,
a pretty standard data centre switch for mounting in 19” server racks.</p>
<p>Pay attention to the little «ears» protruding from the sides at the front of the
switch chassis. Those are the rack mount brackets.</p>
<p><img src="/images//rack-switch-removal/lab-rack.jpg" alt="Lab rack - rear view" /></p>
<p>This picture shows the rack in our lab. There are seven servers and five
switches in the picture. The switches have all the exact same kind of rack mount
brackets as the switch in the first picture.</p>
<p>The switches are all mounted with their ports facing towards the rear of the
rack. This is typical of data centre installations, due to the fact that the
servers they connect to also have their network ports facing towards the rear of
the rack. Keeping all the network ports facing the same way minimises the amount
of cabling clutter in a rack.</p>
<p>Now you know how data centre switches are mounted. If you have sharp eyes, you
might already have realised what the problem is. If not, read on!</p>
<h1 id="a-failed-removal-attempt">A failed removal attempt</h1>
<p><img src="/images//rack-switch-removal/dc-rack-rear.jpg" alt="Data centre rack - rear
view" /></p>
<p>This picture shows the rear of a rack cabinet in one of our data centres. I
needed to remove the pair of <a href="https://www.juniper.net/documentation/en_US/release-independent/junos/topics/topic-map/ex4500-system-overview.html">Juniper EX
4500</a>s
in the centre. The EX 4500 is an old and end of life model, so they had to go in
order to make room for a set of new <a href="https://www.edge-core.com/productsInfo.php?cls=1&cls2=154&cls3=155&id=544">Edge-Core
AS7326-56X</a>
we have arriving soon.</p>
<p><img src="/images//rack-switch-removal/obstruction.jpg" alt="Extraction blocked by
PDU" /></p>
<p>In case it was not obvious from the previous picture, this ought to illustrate
why I was having difficulties removing these switches from the rack. When I
tried to pull them out, they were blocked by the vertical power distribution
units occupying the space behind them.</p>
<p>Even if the PDUs were not in the way, network cables could also have posed a bit
of a problem. I think that I would have been able to overcome that in this
particular case, though.</p>
<p>Removing the power distribution units is not an option, as that would mean
powering down all the other production equipment located in the rack.</p>
<p><img src="/images//rack-switch-removal/dc-rack-front.jpg" alt="Data centre rack - front
view" /></p>
<p>This is the view from the front of the rack. (I had removed all the
<a href="https://en.wikipedia.org/wiki/Field-replaceable_unit">FRUs</a> from the switches
in order to make them lighter and easier to handle.)</p>
<p>On this side, there are no power distribution units and there are very few
cables in the way. If I could have simply pulled out the switches through the
front of the rack, I would have had no difficulties whatsoever.</p>
<p>The problem is that those damn rack mount brackets prevents me from extracting
the switches that way. As long as the rack mount brackets remain in place, the
switches can only come out one way: through the rear of the rack.</p>
<p><img src="/images//rack-switch-removal/screwdriver.jpg" alt="Attempt to unscrew rack mount
brackets" /></p>
<p>The rack mount brackets are not usually part of the switch chassis itself, they
are screwed on. As there was a lot of room at the front of the rack, I was able
to attempt removing them using an angled screwdriver.</p>
<p>Unfortunately, the only thing I accomplished was to destroy the
<a href="https://en.wikipedia.org/wiki/List_of_screw_drives#Phillips">Phillips</a> screw
head. The screws had most likely been treated with <a href="https://en.wikipedia.org/wiki/Thread-locking_fluid">thread-locking
fluid</a> at the factory, and
because I had to use an angled screwdriver I was unable to get enough pressure
onto the screw to prevent the screwdriver from slipping - not to mention that I
could not really see what I was doing from where I was standing. (I suspect I
might have succeeded if the screws had been of a more slip-resistant type, e.g.,
<a href="https://en.wikipedia.org/wiki/Torx">Torx</a>.)</p>
<p>At this point, I decided to call it a day.</p>
<h1 id="brute-force-to-the-rescue">Brute force to the rescue!</h1>
<p>The next day I brought a few tools one would normally not expect to see in a
data centre.</p>
<p><img src="/images//rack-switch-removal/pliers.jpg" alt="Pliers" /></p>
<p>Pliers…</p>
<p><img src="/images//rack-switch-removal/hammer.jpg" alt="Hammer" /></p>
<p>…and a hammer. Using these, I was able to bend the rack mount bracket out of
the way.</p>
<p><img src="/images//rack-switch-removal/success-left.jpg" alt="Success - left
side" /></p>
<p>With the rack mount bracket on the left side flattened, I could sneak the switch
past the 19” mounting profile.</p>
<p><img src="/images//rack-switch-removal/success-right.jpg" alt="Success - right
side" /></p>
<p>Once the left corner of the switch was past the 19” mounting profile, it could
easily be shifted sideways to the left, allowing the right corner of the switch
to sneak past as well (without needing to damage the rack mount bracket on that
side).</p>
<p><img src="/images//rack-switch-removal/extraction.jpg" alt="Successful extraction through front of
rack" /></p>
<p>At this point, removing the switch through the front of the rack posed no
challenge at all.</p>
<p>I then repeated the process for the other switch. Success!</p>
<h1 id="resulting-damage">Resulting damage</h1>
<p><img src="/images//rack-switch-removal/damage.jpg" alt="Damaged rack mount
brackets" /></p>
<p>The process clearly took its toll on the rack mount brackets. They could
probably be bent back to working order, though. I also dented the chassis of one
of the switches a bit.</p>
<p><img src="/images//rack-switch-removal/screws.jpg" alt="Damaged screws" /></p>
<p>The screws I tried to unscrew using the angled screwdriver do not look too good
either. However, I believe I could get them out using a <a href="https://en.wikipedia.org/wiki/Screw_extractor">screw
extractor</a>.</p>
<p>Fortunately, these were old switches that we are not putting back in service, so
I do not really care about the damage.</p>
<h1 id="a-plea-to-the-switch-manufacturers">A plea to the switch manufacturers</h1>
<p>To me it seems blindingly obvious that the rack mount brackets that come with
data centre switches should be designed so that they allow for extraction
through the <em>front</em> of the rack - sliding <em>away</em> from all cables, PDUs and other
obstructions in the crowded rear.</p>
<p>If you are a data centre switch manufacturer reading this, you do not have to
look further than to the server manufacturers for inspiration.</p>
<p>For as long as I have worked in the industry, I have never ever seen a
rack-mountable server that does not get installed through the front of the rack.
This makes removing it a breeze. You just disconnect all the cables, and pull it
straight out. Done!</p>
<p><img src="/images//rack-switch-removal/server-rear.jpg" alt="Server removal -
rear" /></p>
<p>Returning to our lab for a demonstration, it would have been impossible to
remove the server in the middle through the rear of the rack, due to all the
cables that occupy the space it would have had to pass through. But since it is
sliding <em>away</em> from the cables, there is no problem at all.</p>
<p><img src="/images//rack-switch-removal/server-front.jpg" alt="Server removal -
front" /></p>
<p>Out through the front of the rack it slides. Easy!</p>
<p>While you are at it, dear switch manufacturer, you should also note that the
servers in the pictures, like most servers on the market, have rack mount rails
that do not require any tools to be mounted. Everything just clicks into place.
There are no screws that can be dropped and lost below the raised data centre
floor. This is definitively something I would like to see network equipment
manufacturers start doing as well. (If you absolutely must include screws, at
least use Torx instead of Phillips.)</p>
<h1 id="final-words">Final words</h1>
<p>From now on I will start discarding any standard rack mount brackets that do not
allow for installation and removal of the equipment through the front of the
rack. It is just not worth the trouble when the time comes to remove it again.</p>
<p>If you are in the process of acquiring new switches for your data centre, do
make sure to ask your vendors if their switches come with sensible rack mount
brackets. Perhaps if enough customers ask, they will actually improve.</p>
<p>In the mean time, though - if you know of any generic replacement rack mount
system that is suitable for switches, <a href="https://twitter.com/toreanderson">I would love to hear from
you</a>!</p>
<p><em>(Note: this is a <a href="https://www.redpill-linpro.com/techblog/2019/08/06/rack-switch-removal.html">repost of an
article</a>
from the <a href="https://www.redpill-linpro.com/techblog/">Redpill Linpro techblog</a>.)</em></p>toreI recently needed to remove a couple of decommissioned switches from one of our data centres. This turned out to be quite an ordeal. The reason? The ill-conceived way the rack mount brackets used by most data centre switches are designed. In this post, I will use plenty of pictures to explain why that is, and propose a simple solution on how the switch manufacturers can improve this in future.Validating SSH host keys with DNSSEC2019-05-06T00:00:00+00:002019-05-06T00:00:00+00:00https://toreanderson.github.io/2019/05/06/sshfp-and-dnssec<p>We have all done it. When SSH asks us this familiar question:</p>
<div class="language-console highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="gp">$</span><span class="w"> </span>ssh redpilllinpro01.ring.nlnog.net
<span class="go">The authenticity of host 'redpilllinpro01.ring.nlnog.net (2a02:c0:200:104::1)' can't be established.
ECDSA key fingerprint is SHA256:IM/o2Qakw4q7vo9dBMLKuKAMioA7UeJSoVhfc5CYsCs.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
</span></code></pre></div></div>
<p>…we just answer <code class="language-plaintext highlighter-rouge">yes</code> - without bothering to verify the fingerprint shown.</p>
<p>Many of us will even automate answering <code class="language-plaintext highlighter-rouge">yes</code> to this question by adding <code class="language-plaintext highlighter-rouge">StrictHostKeyChecking accept-new</code> to our <code class="language-plaintext highlighter-rouge">~/.ssh/config</code> file.</p>
<p>Sometimes, SSH will be more ominous:</p>
<div class="language-console highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="gp">$</span><span class="w"> </span>ssh redpilllinpro01.ring.nlnog.net
<span class="go">@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:IM/o2Qakw4q7vo9dBMLKuKAMioA7UeJSoVhfc5CYsCs.
Please contact your system administrator.
Add correct host key in /home/tore/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/tore/.ssh/known_hosts:448
ECDSA host key for redpilllinpro01.ring.nlnog.net has changed and you have requested strict checking.
Host key verification failed.
</span></code></pre></div></div>
<p>This might make us stop a bit and ask ourselves: <em>«Has a colleague re-provisioned this node since the last time I logged in to it?»</em></p>
<p>Most of the time, the answer will be: <em>«Yeah, probably»</em>, followed by something like <code class="language-plaintext highlighter-rouge">sed -i 448d ~/.ssh/known_hosts</code> to get rid of the old offending key. Problem solved!</p>
<p>These are all very understandable and human ways of dealing with these kinds of repeated questions and warnings. SSH certainly does <em>«cry wolf»</em> a lot! Let us not think too much about what happens that one time someone actually <em>is «DOING SOMETHING NASTY»</em>, though…</p>
<p>Another challenge occurs when maintaining a large number of servers using automation software like <a href="https://www.ansible.com">Ansible</a>. Manually answering questions about host keys might be impossible, as the automation software likely needs to run entirely without human interaction. The <em>cop out</em> way of ensuring it can do so is to disable host key checking altogether, e.g., by adding <code class="language-plaintext highlighter-rouge">StrictHostKeyChecking no</code> to the <code class="language-plaintext highlighter-rouge">~/.ssh/config</code> file.</p>
<h2 id="dnssec-validated-ssh-host-key-fingerprints-in-dns">DNSSEC-validated SSH host key fingerprints in DNS</h2>
<p>Fortunately a better way of securely verifying SSH host keys exists - one which does not require lazy and error-prone humans to do all the work.</p>
<p>This is accomplished by combining <a href="https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions">DNS Security Extensions</a> (DNSSEC) with <a href="https://tools.ietf.org/html/rfc4255"><code class="language-plaintext highlighter-rouge">SSHFP</code> resource records</a>.</p>
<p>To make use of this approach, you will need the following:</p>
<ol>
<li>The SSH host keys published in DNS using <code class="language-plaintext highlighter-rouge">SSHFP</code> resource records</li>
<li>Valid DNSSEC signatures on the <code class="language-plaintext highlighter-rouge">SSHFP</code> resource records</li>
<li>A DNS recursive resolver which supports DNSSEC</li>
<li>A stub resolver that is configured to request DNSSEC validation</li>
<li>A SSH client that is configured to look for SSH host keys in DNS</li>
</ol>
<p>I will elaborate on how to implement each of these requirements in the sections below.</p>
<h3 id="1-publishing-sshfp-host-keys-in-dns">1. Publishing SSHFP host keys in DNS</h3>
<p>The <code class="language-plaintext highlighter-rouge">ssh-keygen</code> utility provides an easy way to generate the correct <code class="language-plaintext highlighter-rouge">SSHFP</code> resource records based on contents of the <code class="language-plaintext highlighter-rouge">/etc/ssh/ssh_host_*_key.pub</code> files. Run it on the server like so:</p>
<div class="language-console highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="gp">$</span><span class="w"> </span>ssh-keygen <span class="nt">-r</span> <span class="si">$(</span><span class="nb">hostname</span> <span class="nt">--fqdn</span><span class="si">)</span><span class="nb">.</span>
<span class="go">redpilllinpro01.ring.nlnog.net. IN SSHFP 1 1 5fca087a7c3ebebbc89b229a05afd450d08cf9b3
redpilllinpro01.ring.nlnog.net. IN SSHFP 1 2 cdb4cdaf7734df343fd567e0cab92fd6ac5f2754bfef797826dfd4bcf90f0baf
redpilllinpro01.ring.nlnog.net. IN SSHFP 2 1 613f389a36cf33b67d9bd69e381785b275e101cd
redpilllinpro01.ring.nlnog.net. IN SSHFP 2 2 8a07b97b96d826a7d4d403424b97a8ccdb77105b527be7d7be835d02fdb9cd58
redpilllinpro01.ring.nlnog.net. IN SSHFP 3 1 3e46cecd986042e50626575231a4a155cb0ee5ca
redpilllinpro01.ring.nlnog.net. IN SSHFP 3 2 20cfe8d906a4c38abbbe8f5d04c2cab8a00c8a803b51e252a1585f739098b02b
</span></code></pre></div></div>
<p>These entries can be copied and pasted directly into the zone file in question so that they are visible in DNS:</p>
<div class="language-console highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="gp">$</span><span class="w"> </span>dig +short redpilllinpro01.ring.nlnog.net. IN SSHFP | <span class="nb">sort</span>
<span class="go">1 1 5FCA087A7C3EBEBBC89B229A05AFD450D08CF9B3
1 2 CDB4CDAF7734DF343FD567E0CAB92FD6AC5F2754BFEF797826DFD4BC F90F0BAF
2 1 613F389A36CF33B67D9BD69E381785B275E101CD
2 2 8A07B97B96D826A7D4D403424B97A8CCDB77105B527BE7D7BE835D02 FDB9CD58
3 1 3E46CECD986042E50626575231A4A155CB0EE5CA
3 2 20CFE8D906A4C38ABBBE8F5D04C2CAB8A00C8A803B51E252A1585F73 9098B02B
</span></code></pre></div></div>
<p>How to automatically update the <code class="language-plaintext highlighter-rouge">SSHFP</code> records in DNS when a node is being provisioned is left as an exercise for the reader, but one nifty little trick is to run something like <code class="language-plaintext highlighter-rouge">ssh-keygen -r "update add $(hostname --fqdn). 3600"</code>. This produces output that can be piped directly into <code class="language-plaintext highlighter-rouge">nsupdate(1)</code>.</p>
<p>If you for some reason can not run <code class="language-plaintext highlighter-rouge">ssh-keygen</code> on the server, you can also use a tool called <code class="language-plaintext highlighter-rouge">sshfp</code>. This tool will take the entries from <code class="language-plaintext highlighter-rouge">~/.ssh/known_hosts</code> (i.e., those you have manually accepted earlier) and convert them to <code class="language-plaintext highlighter-rouge">SSHFP</code> syntax.</p>
<h3 id="2-ensuring-the-dns-records-are-signed-with-dnssec">2. Ensuring the DNS records are signed with DNSSEC</h3>
<p>DNSSEC signing of the data in a DNS zone is a task that is usually performed by the DNS hosting provider, so normally you would not need to do this yourself.</p>
<p>There are several web sites that will verify that DNSSEC signatures exist and validate for any given host name. The two best known are:</p>
<ul>
<li><a href="http://dnsviz.net/">DNSViz</a></li>
<li><a href="https://dnssec-debugger.verisignlabs.com/">Verisign Labs’s DNSSEC Debugger</a></li>
</ul>
<p>If DNSViz shows that everything is <em>«secure»</em> in the left column (<a href="http://dnsviz.net/d/redpilllinpro01.ring.nlnog.net/dnssec/">example</a>) and the DNSSEC Debugger only shows green ticks (<a href="https://dnssec-debugger.verisignlabs.com/redpilllinpro01.ring.nlnog.net">example</a>), your DNS records are correctly signed and the SSH client should consider them secure for the purposes of <code class="language-plaintext highlighter-rouge">SSHFP</code> validation.</p>
<p>If DNSViz and the DNSSEC Debugger give you a different result, you will most likely have to contact your DNS hosting provider and ask them to sign your zones with DNSSEC.</p>
<h3 id="3-a-recursive-resolver-that-supports-dnssec">3. A recursive resolver that supports DNSSEC</h3>
<p>The recursive resolver used by your system must be capable of validating DNSSEC signatures. This can be verified like so:</p>
<div class="language-console highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="gp">$</span><span class="w"> </span>dig redpilllinpro01.ring.nlnog.net. IN SSHFP +dnssec
<span class="go">[...]
</span><span class="gp">;</span><span class="p">;</span> flags: qr rd ra ad<span class="p">;</span> QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1
<span class="go">[...]
</span></code></pre></div></div>
<p>Look for the <code class="language-plaintext highlighter-rouge">ad</code> flag (<em>«Authenticated Data»</em>) in the answer, If present, it means that the DNS server confirms that the supplied answer has a valid DNSSEC signature and is secure.</p>
<p>If the <code class="language-plaintext highlighter-rouge">ad</code> flag is missing when querying a hostname known to have valid DNSSEC signatures (e.g., <code class="language-plaintext highlighter-rouge">redpilllinpro01.ring.nlnog.net</code>), your DNS server is probably not DNSSEC capable. You can either ask your ISP or IT department to fix that, or change your system use a public DNS server known to be DNSSEC capable.</p>
<p><a href="https://1.1.1.1/dns/">Cloudflare’s 1.1.1.1</a> is one well-known example of a public recursive resolver that supports DNSSEC. To change to it, replace any pre-existing <code class="language-plaintext highlighter-rouge">nameserver</code> lines in <code class="language-plaintext highlighter-rouge">/etc/resolv.conf</code> with the following:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>nameserver 1.1.1.1
nameserver 2606:4700:4700::1111
nameserver 1.0.0.1
nameserver 2606:4700:4700::1001
</code></pre></div></div>
<h3 id="4-configuring-the-system-stub-resolver-to-request-dnssec-validation">4. Configuring the system stub resolver to request DNSSEC validation</h3>
<p>By default, the system stub resolver (part of the C library) does not set the <code class="language-plaintext highlighter-rouge">DO</code> (<em>«DNSSEC OK»</em>) bit in outgoing queries. This prevents DNSSEC validation.</p>
<p>DNSSEC is enabled in the stub resolver by enabling <a href="https://tools.ietf.org/html/rfc2671">EDNS0</a>. This is done by adding the following line to <code class="language-plaintext highlighter-rouge">/etc/resolv.conf</code>:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>options edns0
</code></pre></div></div>
<h3 id="5-configuring-the-ssh-client-to-look-for-host-keys-in-dns">5. Configuring the SSH client to look for host keys in DNS</h3>
<p>Easy peasy: either you can add the line <code class="language-plaintext highlighter-rouge">VerifyHostKeyDNS yes</code> to your <code class="language-plaintext highlighter-rouge">~/.ssh/config</code> file, or you can supply it on the command line using <code class="language-plaintext highlighter-rouge">ssh -o VerifyHostKeyDNS=yes</code>.</p>
<h2 id="verifying-that-it-works">Verifying that it works</h2>
<p>If you have successfully implemented steps 1-5 above, we are ready for a test!</p>
<p>If you have only done step 3-5, you can still test using <code class="language-plaintext highlighter-rouge">redpilllinpro01.ring.nlnog.net</code> (or any other node in the <a href="https://ring.nlnog.net">NLNOG RING</a> for that matter). The NLNOG RING nodes will respond to SSH connection attempts from everywhere, and they have all DNSSEC-signed <code class="language-plaintext highlighter-rouge">SSHFP</code> records registered.</p>
<div class="language-console highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="gp">$</span><span class="w"> </span>ssh <span class="nt">-o</span> <span class="nv">UserKnownHostsFile</span><span class="o">=</span>/dev/null <span class="nt">-o</span> <span class="nv">VerifyHostKeyDNS</span><span class="o">=</span><span class="nb">yes </span>no-such-user@redpilllinpro01.ring.nlnog.net
<span class="go">no-such-user@redpilllinpro01.ring.nlnog.net: Permission denied (publickey).
</span></code></pre></div></div>
<p>Ignore the fact that the login attempt failed with <em>«permission denied»</em> - this test was a complete success, as the SSH client did not ask to manually verify the SSH host key.</p>
<p><code class="language-plaintext highlighter-rouge">UserKnownHostsFile=/dev/null</code> was used to ensure that any host keys manually added to <code class="language-plaintext highlighter-rouge">~/.ssh/known_hosts</code> at an earlier point in time would be ignored and not skew the test.</p>
<p>It is worth noting that SSH does <em>not</em> add host keys verified using <code class="language-plaintext highlighter-rouge">SSHFP</code> records to the <code class="language-plaintext highlighter-rouge">~/.ssh/known_hosts</code> file - it will validate the <code class="language-plaintext highlighter-rouge">SSHFP</code> records every time you connect. This ensures that even if the host keys change, e.g., due to the server being re-provisioned, the ominous <em>«IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY»</em> warning will not appear - provided the <code class="language-plaintext highlighter-rouge">SSHFP</code> records in DNS have been updated, of course.</p>
<h2 id="trusting-the-recursive-resolver">Trusting the recursive resolver</h2>
<p>The setup discussed in this post places implicit trust in the recursive resolver used by the system. That is, you will be trusting it to diligently validate any DNSSEC signatures on the responses it gives you, and to only set the <em>«Authenticated Data»</em> flag if those signatures are truly valid.</p>
<p>You are also placing trust in the network path between the host and the recursive resolver. If the network is under control by a malicious party, the DNS queries sent from your host to the recursive resolver could potentially be hijacked and redirected to a rogue recursive resolver.</p>
<p>This means that an attacker with the capability to hijack or otherwise interfere with both your SSH and DNS traffic could potentially set up a fraudulent SSH server for you to connect to, and make your recursive resolver lie about the SSH host keys being correct and valid according to DNSSEC. The SSH client will not be able to detect this situation on its own.</p>
<p>In order to detect such attacks, it is necessary for your host to double-check the validity of answers received from the recursive resolver by performing local DNSSEC validation. How to set up this will be the subject of a future post here on the <a href="https://www.redpill-linpro.com/techblog/">Redpill Lipro techblog</a>. Stay tuned!</p>
<p><em>(Note: this is a <a href="https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and-dnssec.html">repost of an article</a> from the <a href="https://www.redpill-linpro.com/techblog/">Redpill Linpro techblog</a>.)</em></p>Tore AndersonWe have all done it. When SSH asks us this familiar question:Enabling IPv6 on the Huawei ME906s-158 / HP lt41322018-12-01T00:00:00+00:002018-12-01T00:00:00+00:00https://toreanderson.github.io/2018/12/01/huawei-me906s-hp-lt4132-enabling-ipv6<p>Last year I wrote a <a href="/2017/07/31/huawei-me906s-hp-lt4132-linux-ipv6.html">post</a>
about my difficulties getting IPv6 to work with the <a href="http://consumer.huawei.com/solutions/m2m-solutions/en/products/tech-specs/me906s-158-en.htm">Huawei ME906s-158 WWAN
module</a>.
I eventually gave up and had it replaced with a module from another
manufacturer.</p>
<p>Not long ago, though, I received an e-mail from another ME906s-158 owner who
told me that for him, IPv6 worked just fine. That motivated me to brush the
dust off my module and try again. This time, I figured it out! Read on for the
details.</p>
<h2 id="the-carrier-plmn-list">The Carrier PLMN List</h2>
<p>The ME906s-158 comes with a built-in list of nine different
<a href="https://en.wikipedia.org/wiki/Public_land_mobile_network">PLMN</a> profiles. This
list can be managed with proprietary AT command <code class="language-plaintext highlighter-rouge">AT^PLMNLIST</code>, which is
documented on page 209 of the module’s <a href="http://download-c.huawei.com/download/downloadCenter?downloadId=51047&version=120450&siteCode="><em>AT Command Interface
Specification</em></a>.</p>
<p>To interact with the AT command interface, use the <code class="language-plaintext highlighter-rouge">option</code> driver. More
details on that
<a href="/2017/07/31/huawei-me906s-hp-lt4132-linux-ipv6.html#lack-of-ipv6-support">here</a>.</p>
<p>This is the complete factory default list:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>AT^PLMNLIST?
^PLMNLIST: "00000",00000,23106,26207,23802,23806
^PLMNLIST: "20205",26801,20205,26202,26209,27201,27402,50503,54201,53001,40401,40405,40411,40413,40415,40420,40427,40430,40443,40446,40460,40484,40486,40488,40566,40567,405750,405751,405752,405753,405754,405755,405756,20404,20601,20810,21401,21670,22210,22601,23003,23415,24405,24802,27602,27801,28001,28602,28802,29340,42702,60202,62002,63001,63902,64004,64304,65101,65501,90128,23201,28401,64710,46601,42602,22005,41302,29403,50213,50219,21910,25001,27077,52505,23801,40004,42403,46692,52503,73001,24602,24705
^PLMNLIST: "26201",26201,23001,20416,23203,23207,21901,21630,23102,29702,29401,26002,20201,23431,23432
^PLMNLIST: "21403",20610,20801,20802,21403,22610,23101,23430,23433,26803,26003
^PLMNLIST: "50501",50501,50571,50572
^PLMNLIST: "22801",22801,29501
^PLMNLIST: "21407",21405,21407,23402
^PLMNLIST: "99999",24491,24001,23820
^PLMNLIST: "50502",50502
OK
</code></pre></div></div>
<p>Each <code class="language-plaintext highlighter-rouge">^PLMNLIST:</code> line represents a single pre-defined PLMN profile, identified
by the first MCCMNC number (in double quotes). The <code class="language-plaintext highlighter-rouge">"26201"</code> profile is for
Deutsche Telekom, the <code class="language-plaintext highlighter-rouge">"50501"</code> profile is for Telstra Mobile, and so on.</p>
<p>The rest of the numbers on each line is a list of MCCMNCs that will use that
particular profile. For example, if you have a SIM card issued by T-Mobile
Netherlands (MCCMNC 20416), then the ME906s-158 will apply the Deutsche Telekom
profile (<code class="language-plaintext highlighter-rouge">"26201"</code>).</p>
<p>Unfortunately, the documentation offers no information on how the PLMN profiles
differ and how they change the way the module work.</p>
<p>My provider (Telenor Norway, MCCMNC 24201) is not present in the factory
default list. In that case, the module appears to use the <code class="language-plaintext highlighter-rouge">"00000"</code> PLMN
profile (<em>«Generic»</em>) as the default, and that one disables IPv6! Clearly,
Huawei haven’t read <a href="https://tools.ietf.org/html/rfc6540">RFC 6540</a>…</p>
<p>In any case, this explains why I failed to make IPv6 work last year, and why it
worked fine for the guy who mailed me - his provider was among those that used
the Deutsche Telekom PLMN profile by default.</p>
<h2 id="modifying-the-carrier-plmn-list">Modifying the Carrier PLMN List</h2>
<p>The solution seems clear: I need to add my provider’s MCCMNC to an IPv6-capable
PLMN profile. The Deutsche Telekom one would probably work, but <code class="language-plaintext highlighter-rouge">"99999"</code>
(<em>«Generic(IPV4V6)»</em>) seems like an even more appropriate choice.</p>
<p>Adding MCCMNCs is done with <code class="language-plaintext highlighter-rouge">AT^PLMNLIST=1,"$PLMNProfile","$MCCMNC"</code>, like so:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>AT^PLMNLIST=1,"99999","24201"
OK
</code></pre></div></div>
<p>(To remove an MCCMNC, use <code class="language-plaintext highlighter-rouge">AT^PLMNLIST=0,"$PLMNProfile","$MCCMNC"</code> instead.)</p>
<p>I can now double check that the <code class="language-plaintext highlighter-rouge">"99999"</code> PLMN profile includes <code class="language-plaintext highlighter-rouge">24201</code> for
Telenor Norway:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>AT^PLMNLIST="99999"
^PLMNLIST: "99999",24491,24001,23820,24201
OK
</code></pre></div></div>
<p>To make the new configuration take effect, it appears to be necessary to reset
the module. This can be done with the <code class="language-plaintext highlighter-rouge">AT^RESET</code> command.</p>
<h2 id="confirming-that-ipv6-works">Confirming that IPv6 works</h2>
<p>It is possible to query the module directly about IPv6 support in at least two
different ways:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>AT^IPV6CAP?
^IPV6CAP: 7
OK
AT+CGDCONT=?
+CGDCONT: (0-11),"IP",,,(0-2),(0-3),(0,1),(0,1),(0-2),(0,1)
+CGDCONT: (0-11),"IPV6",,,(0-2),(0-3),(0,1),(0,1),(0-2),(0,1)
+CGDCONT: (0-11),"IPV4V6",,,(0-2),(0-3),(0,1),(0,1),(0-2),(0,1)
OK
</code></pre></div></div>
<p>The <code class="language-plaintext highlighter-rouge">^IPV6CAP: 7</code> response means <em>«IPv4 only, IPv6 only and IPv4v6»</em> (cf. page
336 of the <a href="http://download-c.huawei.com/download/downloadCenter?downloadId=51047&version=120450&siteCode="><em>AT Command Interface
Specification</em></a>),
and the <code class="language-plaintext highlighter-rouge">+CDGCONT:</code> responses reveal that the modem is ready to configure PDP
contexts using the IPv6-capable IP types. Looking good!</p>
<p>Of course, the only test that really matters is to connect it:</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$ mmcli --modem 0 --simple-connect=apn=telenor.smart,ip-type=ipv4v6
successfully connected the modem
$ mmcli --bearer 0
Bearer '/org/freedesktop/ModemManager1/Bearer/0'
-------------------------
Status | connected: 'yes'
| suspended: 'no'
| interface: 'wwp0s20f0u3c3'
| IP timeout: '20'
-------------------------
Properties | apn: 'telenor.smart'
| roaming: 'allowed'
| IP type: 'ipv4v6'
| user: 'none'
| password: 'none'
| number: 'none'
| Rm protocol: 'unknown'
-------------------------
IPv4 configuration | method: 'static'
| address: '10.169.198.77'
| prefix: '30'
| gateway: '10.169.198.78'
| DNS: '193.213.112.4', '130.67.15.198'
| MTU: '1500'
-------------------------
IPv6 configuration | method: 'static'
| address: '2a02:2121:2c4:7105:5a2c:80ff:fe13:9208'
| prefix: '64'
| gateway: '::'
| DNS: '2001:4600:4:fff::52', '2001:4600:4:1fff::52'
| MTU: '1500'
-------------------------
Stats | Duration: '59'
| Bytes received: 'N/A'
| Bytes transmitted: 'N/A'
</code></pre></div></div>
<p>Success!</p>Tore AndersonLast year I wrote a post about my difficulties getting IPv6 to work with the Huawei ME906s-158 WWAN module. I eventually gave up and had it replaced with a module from another manufacturer.IPv6 roaming in the United States2018-02-16T00:00:00+00:002018-02-16T00:00:00+00:00https://toreanderson.github.io/2018/02/16/ipv6-roaming-in-the-us<p>I spent some time in the United States last month. Equipped with SIM cards from
both Tele2 Sweden (MCCMNC 24007) and Telenor Norway (MCCMNC 24201), I set out
to test IPv6 while roaming, as I usually do while abroad.</p>
<p>The previous posts in this series are:</p>
<ul>
<li><a href="/2017/01/09/ipv6-roaming-in-belgium-and-romania.html">IPv6 roaming in Belgium and
Romania</a></li>
<li><a href="/2017/01/21/ipv6-roaming-in-the-uk.html">IPv6 roaming in the United Kingdom</a></li>
<li><a href="/2017/10/12/ipv6-roaming-in-czechia.html">IPv6 roaming in Czechia</a></li>
<li><a href="/2017/10/15/ipv6-roaming-in-sweden.html">IPv6 roaming in Sweden</a></li>
</ul>
<p>There were two mobile networks that I was able to register in and test:
<a href="https://www.att.com/">AT&T</a> (3G/4G, no 2G) and
<a href="https://www.t-mobile.com/">T-Mobile</a> (2G/3G/4G). The test results are found
below.</p>
<p>I could also see three other 4G networks show up in a network scan (Caprock
Cellular, <a href="https://www.sprint.com/">Sprint</a> and
<a href="https://www.verizonwireless.com/">Verizon</a>), but none of those were available
to me. Presumably neither Tele2 nor Telenor have roaming arrangements with any
of those operators.</p>
<h2 id="att---mccmnc-310410">AT&T - MCCMNC 310410</h2>
<table>
<thead>
<tr>
<th>Home PLMN</th>
<th>Tech</th>
<th>IPV6 PDP context</th>
<th>IPV4V6 PDP context</th>
</tr>
</thead>
<tbody>
<tr>
<td>Tele2 SE</td>
<td>3G</td>
<td>Fails (cause code 33)</td>
<td>IPv4-only (cause code 50)</td>
</tr>
<tr>
<td>Tele2 SE</td>
<td>4G</td>
<td>Works perfectly</td>
<td>Works perfectly</td>
</tr>
<tr>
<td>Telenor NO</td>
<td>3G</td>
<td>Fails (cause code 33)</td>
<td>IPv4-only (cause code 50)</td>
</tr>
<tr>
<td>Telenor NO</td>
<td>4G</td>
<td>Works perfectly</td>
<td>Works perfectly</td>
</tr>
</tbody>
</table>
<h2 id="t-mobile---mccmnc-310260">T-Mobile - MCCMNC 310260</h2>
<table>
<thead>
<tr>
<th>Home PLMN</th>
<th>Tech</th>
<th>IPV6 PDP context</th>
<th>IPV4V6 PDP context</th>
</tr>
</thead>
<tbody>
<tr>
<td>Tele2 SE</td>
<td>2G</td>
<td>Fails (cause code 33)</td>
<td>IPv4-only (cause code 50)</td>
</tr>
<tr>
<td>Tele2 SE</td>
<td>3G</td>
<td>Fails (cause code 33)</td>
<td>IPv4-only (cause code 50)</td>
</tr>
<tr>
<td>Tele2 SE</td>
<td>4G</td>
<td>Works perfectly</td>
<td>Works perfectly</td>
</tr>
<tr>
<td>Telenor NO</td>
<td>2G</td>
<td>Fails (cause code 33)</td>
<td>IPv4-only (cause code 50)</td>
</tr>
<tr>
<td>Telenor NO</td>
<td>3G</td>
<td>Fails (cause code 33)</td>
<td>IPv4-only (cause code 50)</td>
</tr>
<tr>
<td>Telenor NO</td>
<td>4G</td>
<td>Works perfectly</td>
<td>Works perfectly</td>
</tr>
</tbody>
</table>
<p>3GPP cause code #33 means <em>«requested service option not subscribed»</em>, while
cause code #50 means <em>«PDP type IPv4 only allowed»</em>. The latter doesn’t
indicate a fatal error, as I do automatically get a working IPv4-only
connection to the Internet.</p>
<p>The fact that IPv6 consistently fails on 2G/3G is in all likelihood due to
Tele2/Telenor’s
<a href="https://en.wikipedia.org/wiki/Network_switching_subsystem#Home_location_register_.28HLR.29">HLR</a>
removing the IPv6 capabilities from my subscriber profile before transmitting
it to AT&T/T-Mobile’s
<a href="https://en.wikipedia.org/wiki/GPRS_core_network#Serving_GPRS_support_node_.28SGSN.29">vSGSN</a>.</p>
<p>Tele2 and Telenor do this to forestall the possible IPv6-related failures
described in <a href="https://tools.ietf.org/html/rfc7445">RFC 7445</a> sections
<a href="https://tools.ietf.org/html/rfc7445#section-3">3</a> and
<a href="https://tools.ietf.org/html/rfc7445#section-6">6</a>. In this case, it is in all
likelihood an unnecessary precaution, considering that both AT&T and T-Mobile
are known to have deployed IPv6 to their own customers.</p>Tore AndersonI spent some time in the United States last month. Equipped with SIM cards from both Tele2 Sweden (MCCMNC 24007) and Telenor Norway (MCCMNC 24201), I set out to test IPv6 while roaming, as I usually do while abroad.IPv6 roaming in Sweden2017-10-15T00:00:00+00:002017-10-15T00:00:00+00:00https://toreanderson.github.io/2017/10/15/ipv6-roaming-in-sweden<p>I attended the <a href="https://www.netnod.se/netnod-events/netnod-tech-meeting-2017">Netnod Tech Meeting
2017</a> in
Stockholm earlier this week. As I usually do when when going abroad, I spent
some time testing to what extent IPv6 works while roaming in the various
<a href="https://en.wikipedia.org/wiki/Public_land_mobile_network">PLMNs</a> I have access
to.</p>
<p>The previous posts in this series are:</p>
<ul>
<li><a href="/2017/01/09/ipv6-roaming-in-belgium-and-romania.html">IPv6 roaming in Belgium and
Romania</a></li>
<li><a href="/2017/01/21/ipv6-roaming-in-the-uk.html">IPv6 roaming in the United Kingdom</a></li>
<li><a href="/2017/10/12/ipv6-roaming-in-czechia.html">IPv6 roaming in Czechia</a></li>
</ul>
<h1 id="test-results">Test results</h1>
<h2 id="telia---mccmnc-24001"><a href="https://www.telia.se">Telia</a> - MCCMNC 24001</h2>
<table>
<thead>
<tr>
<th>Home PLMN</th>
<th>Tech</th>
<th>IPV6 PDP context</th>
<th>IPV4V6 PDP context</th>
</tr>
</thead>
<tbody>
<tr>
<td>Telenor Norway</td>
<td>2G</td>
<td>Fails</td>
<td>IPv4-only connection</td>
</tr>
<tr>
<td>Telenor Norway</td>
<td>3G</td>
<td>Fails</td>
<td>IPv4-only connection</td>
</tr>
<tr>
<td>Telenor Norway</td>
<td>4G</td>
<td>N/A (no service)</td>
<td>N/A (no service)</td>
</tr>
</tbody>
</table>
<p>It would appear that Telenor Norway does not have a 4G roaming agreement with
Telia. My phone was unable to register in Telia’s 4G network, at least.</p>
<p>In 3G and 2G coverage, I could register, but IPv6 did not work. Requesting dual
stack connectivity would only yield IPv4. This is of course a quite acceptable
outcome for the vast majority of users, as the Internet will ostensibly work
just fine..</p>
<p>In all likelihood the IPv6 failures observed on 2G and 3G is due to Telenor
Norway’s
<a href="https://en.wikipedia.org/wiki/Network_switching_subsystem#Home_location_register_.28HLR.29">HLR</a>
removing the IPv6 capabilities from my subscriber profile before transmitting
it to Telia’s
<a href="https://en.wikipedia.org/wiki/GPRS_core_network#Serving_GPRS_support_node_.28SGSN.29">vSGSN</a>.
This is done to forestall the possible IPv6-related failures described in <a href="https://tools.ietf.org/html/rfc7445">RFC
7445</a> sections
<a href="https://tools.ietf.org/html/rfc7445#section-3">3</a> and
<a href="https://tools.ietf.org/html/rfc7445#section-6">6</a>.</p>
<p>Presumably Telenor Norway will, at some point in the future, remove this IPv6
capability blacklisting for Telia, after having ascertained that Telia’s 2G/3G
network does not have any issues with supporting the IPv6 PDP types.</p>
<h2 id="3---mccmnc-24002"><a href="https://www.tre.se">3</a> - MCCMNC 24002</h2>
<table>
<thead>
<tr>
<th>Home PLMN</th>
<th>Tech</th>
<th>IPV6 PDP context</th>
<th>IPV4V6 PDP context</th>
</tr>
</thead>
<tbody>
<tr>
<td>Telenor Norway</td>
<td>3G</td>
<td>Fails</td>
<td>IPv4-only connection</td>
</tr>
<tr>
<td>Telenor Norway</td>
<td>4G</td>
<td>Works perfectly</td>
<td>Works perfectly</td>
</tr>
</tbody>
</table>
<p>In 4G coverage, IPv6 works perfectly. In 3G coverage, it fails - presumably due
to the same IPv6 capability blacklisting as described above for Telia.</p>
<p>I did however notice at one point that if I connected a dual stack IPV4V6 PDP
context while in 3’s 4G network, and then moved into an area that had only 3G
coverage, IPv6 kept working perfectly. Thus it would appear that 3’s 3G network
has no issues supporting visiting subscribers using IPv6.</p>
<p>Note that 3 does not operate a 2G network.</p>
<h2 id="tele2---mccmnc-24007"><a href="https://www.tele2.se">Tele2</a> - MCCMNC 24007</h2>
<table>
<thead>
<tr>
<th>Home PLMN</th>
<th>Tech</th>
<th>IPV6 PDP context</th>
<th>IPV4V6 PDP context</th>
</tr>
</thead>
<tbody>
<tr>
<td>Telenor Norway</td>
<td>3G</td>
<td>Fails</td>
<td>IPv4-only connection</td>
</tr>
<tr>
<td>Telenor Norway</td>
<td>4G</td>
<td>Works perfectly</td>
<td>Works perfectly</td>
</tr>
</tbody>
</table>
<p>Same results as for 3.</p>
<p>I did not get to test physically moving from 4G to 3G coverage. That said, I
know for a fact that Tele2 provides IPv6 to their own mobile subscribes, so it
seems like a safe bet to assume that their 3G network would support IPv6 just
fine, if it hadn’t been for Telenor’s IPv6 capability blacklisting.</p>
<h2 id="telenor-sweden---mccmnc-24008"><a href="https://www.telenor.se">Telenor Sweden</a> - MCCMNC 24008</h2>
<table>
<thead>
<tr>
<th>Home PLMN</th>
<th>Tech</th>
<th>IPV6 PDP context</th>
<th>IPV4V6 PDP context</th>
</tr>
</thead>
<tbody>
<tr>
<td>Telenor Norway</td>
<td>3G</td>
<td>Works perfectly</td>
<td>Works perfectly</td>
</tr>
<tr>
<td>Telenor Norway</td>
<td>4G</td>
<td>Works perfectly</td>
<td>Works perfectly</td>
</tr>
</tbody>
</table>
<p>Perfect score. It is perhaps not surprising that if a single Swedish operator
would be fully «IPv6-approved», and therefore exempt from Telenor Norway’s IPv6
capability blacklisting, it would be their Swedish sister company Telenor
Sweden.</p>
<p>It might also be worth noting that Telenor Sweden is the vPLMN my phone prefers
to register in if I leave it in the default automatic mode. Therefore, for
Telenor Norway subscribers, IPv6 <em>Just Works</em> while visiting Sweden - unless
one manually fiddles around with the network settings.</p>
<h2 id="net4mobility---mccmnc-24024"><a href="http://net4mobility.com">Net4Mobility</a> - MCCMNC 24024</h2>
<table>
<thead>
<tr>
<th>Home PLMN</th>
<th>Tech</th>
<th>IPV6 PDP context</th>
<th>IPV4V6 PDP context</th>
</tr>
</thead>
<tbody>
<tr>
<td>Telenor Norway</td>
<td>2G</td>
<td>Works perfectly</td>
<td>Works perfectly</td>
</tr>
</tbody>
</table>
<p>Perfect score.</p>
<p>The Net4Mobility PLMN is, as far as I can understand, a joint venture between
Tele2 and Telenor Sweden that provides shared 2G coverage for both of those
providers. That is, if I lock my phone on to MCCMNC 24007 (Tele2) or 24008
(Telenor Sweden), it will nevertheless change to 24024 (Net4Mobility) if I also
limit it to 2G only.</p>
<p>This means Net4Mobility is logically part of Telenor Sweden’s network, and thus
it makes sense that it, like MCCMNC 24008, is exempt from Telenor Norway’s IPv6
capability blacklisting.</p>Tore AndersonI attended the Netnod Tech Meeting 2017 in Stockholm earlier this week. As I usually do when when going abroad, I spent some time testing to what extent IPv6 works while roaming in the various PLMNs I have access to.