CLAT interface not coming up on enabling mobile data

REPRODUCIBILITY: 75% (often)
OSVERSION: 5.0.0.67
HARDWARE: Xperia 10 III - xqbt52 - xqbt52 - 1.0.1.44 - aarch64
UI LANGUAGE: Deutsch (user: de_DE, os: de_DE.utf8)
REGRESSION: not specified

DESCRIPTION:

When enabling mobile data most of the time tge CLAT interface doesn’t come up, which results in a loss of network. Disabling and reenabling mobile data countless timed until the clat interface is present can fix this. This also happens when switching from wifi to mobile data or on a cell tower change. I had to reenable mobile data about 20 times to bring clat up and send this bug report.

PRECONDITIONS:

STEPS TO REPRODUCE:

1.Enable mobile data
2.Check if clat is up
3. If yes, everything is fine. If not repeat reenabling mobile data until the interface is up.

EXPECTED RESULTS:

Clat interface working as expected.

ACTUAL RESULTS:

If the clat interface does not come up, sudden loss of connections can happen making android and native apps complaining about missing connection. Some Android apps like fennec need to be restarted when clat finally is available.

MODIFICATIONS:

  • Patchmanager: yes
  • OpenRepos: yes
  • Chum: yes
  • Other: none specified

ADDITIONAL INFORMATION:

Mobile Network is T-Mobile germany

Device Owner User: nemo
Home Encryption: not supported


the initial version of this bug report was created using Bugger 0.9.16+git1
3 Likes

Maybe this is also the bane of my SFOS existence. Gotta dig through Testing CLAT for IPv6-only mobile networks and find if there’s any CLI way to try nudge a CLAT interface restart?

Can you please take out logs by enabling the clat logging at /etc/sysconfig/connman:

echo "SYSCONF_ARGS=-d plugins/clat.c -d src/tethering.c -d src/technology.c -d src/network.c -d src/nat.c" > /etc/sysconfig/connman

and then restarting connman

systemctl restart connman

Before starting to test You could also increase the journalctl limits by:
/etc/systemd/journald.conf.d/debug.conf with content:

[Journal]
Storage=persistent
RateLimitIntervalSec=0s
RateLimitBurst=0
SystemMaxUse=150M
RuntimeMaxUse=4M

and then systemctl restart systemd-journald.

Then save this following as a clat-logs.sh and chmod +x clat-logs.sh:

#!/bin/bash

TMPDIR="/tmp/clat/$(date +%Y%m%d_%H%M%S)"
ARCHIVE="$TMPDIR.tar.bz"
CLATCONF="/etc/connman/clat.conf"

echo "Gathering CLAT logs to $TMPDIR"

mkdir -p "$TMPDIR"

# journal
journalctl -b -u connman > "$TMPDIR/clat.connman.log"

# route info:
route -n > "$TMPDIR/clat.route"
route --inet6 -n > "$TMPDIR/clat.route6"

# device info:
ip addr show clat &> "$TMPDIR/clat.device"

# iptables:
iptables -L -v -n > "$TMPDIR/clat.iptables.filter"
iptables -t nat -L -v -n > "$TMPDIR/clat.iptables.nat"
ip6tables -L -v -n > "$TMPDIR/clat.ip6tables.filter"

# clat conf
if [ -f "$CLATCONF" ] ; then cp /etc/connman/clat.conf "$TMPDIR/" ; fi

tar cjf "$ARCHIVE" "$TMPDIR" 2>/dev/null

echo "Done"
echo "Send archive $ARCHIVE"

Run the script ./clat-log.sh when the interface does not get up AND after you manage to get clat interface up.

And email both archives (they have a timestamp so no need to rename) to connman-debug@jolla.com so we might be able to pinpoint the issue there on your device and network.

It could be also worthy to get logs with “Ofono logger” available via store, or from openrepos too.

But CLAT interface does not get created if the ipv4only.arpa address cannot be resolved via IPv6 or there is an IPv4 address present on the mobile data interface.

You can also try fiddle with the /etc/connman/clat.conf (by default this does not exist) settings file (changing needs ConnMan/device restart), it has same format as, for example, main.conf of ConnMan:

# CLAT configuration, remember to put all within the following group:
[CLAT] 

# Use DAD (Duplicate Address Detection) for protecting the address
# default: on (true).
EnableDAD = true|false

# Ignore resolv failure with the ipv4only.arpa.
# Resolv result always sets global prefix if fails
# default: off (false)
ResolvAlwaysSucceeds = true|false

# Add netmask to the CLAT device IPv4 address
# default: on (true)
ClatDeviceUseNetmask = true|false

# Setup default route with a metric by CLAT plugin
# default: off (false)
ClatDeviceSetDefaultRoute = true|false

# Write IPv6 address of the interface to tayga config
# default: off (false)
TaygaRequiresIPv6Address = true|false

# Value for strict-frag-hdr
# default: on (true)
TaygaStrictFragHdr = true|false

Setting the ResolvAlwaysSucceeds = true would mean that the interface should always get up.

1 Like

You can try the config option I described in CLAT interface not coming up on enabling mobile data - #3 by jlaakkonen

[CLAT] 

ResolvAlwaysSucceeds = true

as the CLAT config /etc/connman/clat.conf and restart ConnMan/device.

1 Like

Thanks, but curious: is SFOS shipping a vendor /etc/connman/clat.conf, or is it normal for me to have to create it on 5.0.0.67?

You’re welcome. No this file is not normally shipped as the default values defined by the CLAT plugin are used. Those values in the configuration are not documented because it is more of a development tool.

1 Like