Return to index.
2022-05: Traceroute reports suspiciously short paths to various destinations.
Tracing route to sfc.wide.ad.jp [203.178.142.131] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 10.147.2.1 2 * * * Request timed out. 3 30 ms 19 ms 19 ms 10.69.42.177 4 21 ms 17 ms 20 ms 82-135-179-170.static.zebra.lt [82.135.179.170] 5 300 ms 282 ms 295 ms sfc.wide.ad.jp [203.178.142.131] Trace complete.
Apparently some equipment at Telia is rewriting all outbound packet TTLs to 255, as my servers (in various locations) receive packets with ttl=249 or similar, even if those packets were initially sent with much lower TTL values.
This causes traceroute probes to become ineffective, as they no longer trigger ICMP TTL Exceeded due to their low TTLs having been forced back to a high value – the probe with ttl=5 travels all the way to the destination host.
2026-01: This is still happening today. Not all destinations are affected; it seems to be a bit hit-and-miss, most likely due to one router of an ECMP pair being misconfigured and the other still operating correctly.
2024-02: Telia now has IPv6.
The prefix is dynamic, so whenever the CPE reconnects (the network forces a disconnection every 24 hours) it gets both a new CGNAT IPv4 address and a different IPv6 prefix.
It is also heavily firewalled. Except for stateful filtering holes, the only packets delivered to the CPE are those which have a TTL (Hop Limit) that is just exactly enough to reach the CPE itself (but not anything beyond).
It seems that the IPv6 implementation is "just enough" to satisfy RRT's recent mandate (IPv6 being a requirement for the 5G spectrum auction).
On top of all that, the default Telia-provided CPE (a Huawei 4G modem) has a built-in DHCPv6 server which issues the same address lease to multiple devices (which naturally leads to them having no IPv6 access as they fight over a neighbor cache slot) and offers no way to disable it. So now my laptop keeps trying to use IPv6 and only getting timeouts because the same xxxx::4 address also got leased to the dryer.
(Fortunately we're not required to use the Telia CPE and can move the SIM card into any other 4G modem, which I did two months later.)
2024-07: Ordered a static IPv4 address.
Configured to use gprs.fix-ip.omnitel1.net as the APN. This has a static IPv4, but no IPv6 at all. It also no longer forces a reconnection every 24h. (The default APN still works as before, providing CGNAT IPv4 and heavily firewalled IPv6.)
2026-01: There is a bit of packet loss from my workplace (via Litnet), but only affecting tunneled packets.
It seems that outbound packets with DSCP=0x00 (CS0) are rewritten to DSCP=0x48 (AF21), so direct ICMP Echo Replies with DSCP=0x48 arrive without loss, but tunneled ones with outer DSCP=0x00 have up to 10% loss at times, and the same goes for SSH sessions through the tunnel.
Enabling tos inherit for GRE tunnels ([Tunnel] TOS=1 in networkd) or mangling DSCP via nftables reduces the packet loss to 0%.
chain mangle_output {
type filter hook output priority mangle;
ip daddr $home4 ip dscp cs0 ip dscp set af21
}
Outbound DSCP mapping pattern (as of 2026-01):
| Original DSCP | New DSCP |
|---|---|
| 0-63 (0x00-0xFF) | 18 (0x48, AF21) |
Inbound DSCP mapping pattern from Ember (as of 2026-01):
| Original DSCP | New DSCP |
|---|---|
| 0-7 (0x00-0x1F) | 0 (0x00, CS0) |
| 8-15 (0x20-0x3F) | 10 (0x28, AF11) |
| 16-23 (0x40-0x5F) | 18 (0x48, AF21) |
| 24-31 (0x60-0x7F) | 26 (0x68, AF31) |
| 32-39 (0x80-0x9F) | 34 (0x88, AF41) |
| 40-47 (0xA0-0xBF) | 46 (0xB8, EF) |
| 48-55 (0xC0-0xDF) | 48 (0xC0, CS6) |
| 56-63 (0xE0-0xFF) | 56 (0xE0, CS7) |
The above DSCP rewriting only occurs on traffic from Ember, whereas packets from Wind (which is adjacent to Ember) undergo no DSCP rewriting at all. It seems to be related to there being an ECMP hop within Telia just past the peering gateway, where packets from Wind go directly through .179.169 while packets from Ember instead take the path via .178.67 and 10.41.226.18.