The dnsmasq and connman may conflict (patch available)

Bug Reports
#1

REPRODUCIBILITY: sometimes
OS VERSION: 4.5.0.19
HARDWARE: Xperia 10 II
UI LANGUAGE: English
REGRESSION: no, AFAIK

DESCRIPTION:

the degraded system state in SFOS 4.5.0.19, it was clear that dnsmasq conflicts with connman (cfr. degraded system state report below)

PRECONDITIONS:

Having installed the dnsmasq by Simon Kelley available from the Chum market:

or with pkcon install -y dnsmasq from a root console.

Thanks to @nephros for having remembered to me that dnsmasq is not a Jolla pre-installed applicatiom.

STEPS TO REPRODUCE:

Regularly check the systemctl --failed in particular when the smartphone reboots with WiFi tethering activated before the reboot.

EXPECTED RESULT:

The dnsmasq and connman services never should conflict competing for port 53 assignation

ACTUAL RESULT:

Sometimes - due to random order/timing systemd boot sequence - connman takes the port 53 and dnsmasq fails to raise up.

MODIFICATIONS:

I suggest to integrate this patch into the dnsmasq package, please read the description:

Moreover, considering that the aim of this patch is to let the DNS subsystem performs as quick as possible and in the most reliable way, it worth a consideration to integrate dnsmasq as a default package for SFOS installation.

ADDITIONAL INFORMATION:

This failure condition does not happen regularly but just sometimes and expecially in particular cases whe the WiFi tethering is active at boot time. However, the condition is not totally reproducible cause the random timing about the starting services order (a beaty of systemd). This patch shall prevent that a conflict between these two services can arise because the port 53 (DNS) competion.

# systemctl status dnsmasq
● dnsmasq.service - DNS caching server.
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2023-06-21 06:42:01 CEST; 4s ago
Process: 27279 ExecStart=/usr/sbin/dnsmasq -k (code=exited, status=2)
Main PID: 27279 (code=exited, status=2)

Jun 21 06:42:01 Sueza11 systemd[1]: Started DNS caching server..
Jun 21 06:42:01 Sueza11 dnsmasq[27279]: dnsmasq: failed to create listening socket for port 53: Address already in use
Jun 21 06:42:01 Sueza11 dnsmasq[27279]: failed to create listening socket for port 53: Address already in use
Jun 21 06:42:01 Sueza11 dnsmasq[27279]: FAILED to start up
Jun 21 06:42:01 Sueza11 systemd[1]: dnsmasq.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jun 21 06:42:01 Sueza11 systemd[1]: dnsmasq.service: Failed with result 'exit-code'.

# netstat -ltnp | grep ':53'
tcp 0 0 172.28.172.1:53 0.0.0.0:* LISTEN 5798/connmand
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 5798/connmand
tcp 0 0 ::1:53 :::* LISTEN 5798/connmand

# strings /proc/5798/cmdline
/usr/sbin/connmand
nl80211
--nobacktrace
--noplugin=wifi</small>
1 Like
Bring back DNS and /etc/resolv.conf user control
#2

dnsmasq is a third-party package not distributed by Jolla.

If there are issues with co-existence with system packages and third-party packages, they should be tackled by the packagers of the latter, and bug reports should be filed against their packaging repos.

One solution could be to configure dnsmasq to listen on a port other than :53.

BTW, the “fix” is pretty dangerous.
Depending on dnsmasq from connman.service will make systems not having dnsmasq installed not work (possibly even not boot up correctly).

See also these topics on custom DNS servers and connman:

3 Likes
#3

Although it’s in the first thread @nephros mentions, I’ll shortcut here: DNS alternative | OpenRepos.net — Community Repository System

#4

I did not installed dnsmasq or I did not do it by my hands. Possibly, it did an application? Or, it is delivered with the default 4.5.0.19 installation?

WRONG: I did with Chum:

This should be reported in the patch. Thanks.

Which means make it useless unless specifically queried on the alternative port (e.g. 5353) and this is not the standard way for which a dns cache as been designed but to avoid dns queries duplications and thus speed up the name resolution.

Thanks, this is a good observation

If we do not have dnsmasq installed, we do not need the patch at all but we can install it just for a mistake. However, we might manually uninstall dnsmasq and forgot to have activated that patch. Let me see what is going to happen… :slightly_smiling_face:

#5

Careful, if the systemd dependency chain is broken so it can’t reach graphical.target or user-session.target, you will end up with a phone that can’t be manipulated via screen, and with broken networking won’t be connectable.
If that happens you need to correct things using the recovery image (or reflash).

2 Likes
#6

Wow!

Are you suggesting me that SFOS is so fragile to Patch Manager patch attack? :face_with_hand_over_mouth:

#7

It is vulnerable to “sloppy developer” and “careless “power user”” attack.

PM is not really involved - you can create a patch which removes critical system files and PM will happily apply it. It is still your fault if you end up with a broken system, not PM.

3 Likes
#8

Thanks for both the compliments! :blush:

I have been beaten twice by @olf for having suggested using APToide in the quick start guide

and now, we discover that Patch Manager can do much more damage… :rofl:

However, I promply put in ALPHA state the patch that I have uploaded. :innocent:

Name: dnsmasq-connman-integration

Display name: dnsmasq connman integration (ALPHA)

Author: robang74

Updated at: June 21, 2023, 12:43 a.m.

Sources

Description: *** DO NOT INSTALL - DANGEROUS BETA TESTING ***

UPDATE #1

Published on Tue, 25 Jan 2022, it refers to CVE-2021-33833 first noticed on 06/09/2021 and last update on 02/09/2022.

Querying the pakages database, I have found installed

  • connman-1.32+git194-1.19.1.jolla.aarch64

The release 1.32 is dated 2016-04-18. I am not acknoledged what +git194 means possibly 194 commits after the initial fork on 1.19.1. The 1.19 has been released on 2013-10-14 which is the same year that Jolla took over the Nokia business.

UPDATE #2

Thus, I managed to release the second version: 0.0.2 - dnsmask is not required anymore but wanted by connman. Which I have classified as BETA and still ask to not install (before I will have completed the tests).

#9

Almost, but not quite.

1.32+git194 is the name of the source tag the build was based on.
You usually find that tag in the corresponding repo on Sailfish OS · GitHub. The number 194 does not really correspond to anything meaningful, it’s just a counter used in the packaging repository (but often roughly corresponds to the number of PRs that have been merged).

1.19.1 is the revision generated by the build system. That is similar to Community OBS, but not available publicly.
Of that revision X.Y.Z, X is always 1, Y is the number of builds that has happened in the build system repository. Z is the number of automatic rebuilds that has happened for revision X.Y. Automatic rebuilds happen e.g. if a dependency of that package has been rebuilt.

That revision is not related to any source code versions.

2 Likes
#10

Nice to know. However, how I compare the Jolla versioning system with the original project? Becuase 1.32 definetely confuses me and moreover leads people to think that the package has been built from a 7 years old source code version! Nice to know, not nice to sell… :wink:

UPDATE

It would be useful to have two labels ALPHA in red and BETA in yelow to clearly aware the users that a Patch Manager is not ready for universal deployment.

Patch Manager warning label to add?
#11

Hm.

You can start by familiarizing yourself with the three kinds of “packaging repo” that rare in use for SFOS sources: Usage of packaging formats | Sailfish OS Documentation

Depending on which one in use, trying to compare will be different.

Plus, the rpm/ directory often contains a lot of patches in addition.

You will find that there are many core packages which are built from rather ancient software versions. Reasons for that are various, but one non-obvious one is that Jolla has adopted a policy of “No GPLv3 packages in the installation image”.
As many Linux core packages have switched from GPLv2 to GPLv3 at some point, that locks SailfishOS to sources from that point, plus backports.

2 Likes
#12

Please submit enhancement requests for PM at Issues · sailfishos-patches/patchmanager · GitHub

1 Like
Patch Manager (de)activation tap to undo
#13

This seem promising in such a case, did you ever tried it?

  • usb-moded-connection-sharing-android-connman-config

I did not understood what this packages does,

  • usb-moded-settings-sailfish

This instead seems not viable because it brings me on the outside netwrok (WLAN ipaddress reange) but I wish to go trough the smartphone VPN, usually. In my case the laptop has it own cloudflare setting and can be fine passing though but not in a general case.

  • usb-moded-connection-sharing-android-connman-config

UPDATE #1

This package instead share the connection as I expect to see - passing trough the local address 192.168.2.15 as default route/gw.

  • usb-moded-connection-sharing-android-config

However, it does not work - out of the box - if a VPN is activated. By the way, neither the one before. Probably, it is just a matter to insert a routing rule which in future might conflict with a firewall but this is another story.

UPDATE #2

Why I need a USB tethering when I can have a SSH tunnel? :heart_eyes:

#14

Aptoide should not be used because of the risk of malicious apps. These could do much severer harm to you than a non-functional phone.

1 Like
#15

UPDATE #3

I suggest to integrate this patch into the dnsmasq package, please read the description:

Moreover, considering that the aim of this patch is to let the DNS subsystem performs as quick as possible and in the most reliable way, it worth a consideration to integrate dnsmasq as a default package for SFOS installation.

#16

UPDATE #4

The patch v0.0.3 has been tested successfully.

Feedbacks are welcome… :slight_smile:

#17

v0.0.4 is broken instead but v0.0.5 fixed the regression and keep the advantage added into v0.0.4