| Message ID | 20231222154645.278128-1-jussi.laakkonen@jolla.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Ensure resolving and setting of proper ISO3166 code | expand |
On Dec 22, 2023, at 7:46 AM, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > This patch set amends the functionality added in commit > bce73f1bdbf1aa6fc28d2f75b7780f4f1d8b0e3a by making sure that the ISO3166 code: > - is resolved in every case using both zone1970.tab and zone.tab > - gets set for the technology when it powers up > - and, is kept in sync between technology and device(s) > > Technology now stores the regulatory domain as an internal value which is > changed whenever a change is detected. Similarly each device ensures that the > value is being kept in sync with technology as it is set always when the device > gets powered. Technology gets the change notifification via Ofono or via the > Localtime setting watched by timezone. > > In order to always resolve, or attempt to resolve, the correct ISO3166 code in > every country sub-region both zone1970.tab and the deprecated zone.tab files > are used. Initially the ISO3166 code is retrieved from zone1970.tab but if not > found then the deprecated timezone map is used to get the correct iso ISO3166 > which is used as a search parameter to again search from the zone1970.tab but > this time searching from the string lists. This is needed in special cases, > such as Ålands and Pacific/Midway regions to name but a few, to have the > ISO3166 code set. Otherwise in these regions WiFi plugin, for instance, is > told to use the default region, resulting in some channels being inaccessible. > > > Jussi Laakkonen (3): > technology: Add global regdom and regdom getter > device: Setup regdom when powering up to maintain consistency > timezone: Fix resolving of proper ISO3166 code from tz data > > src/connman.h | 1 + > src/device.c | 11 +++ > src/technology.c | 27 +++++++ > src/timezone.c | 178 ++++++++++++++++++++++++++++++++++++++++------- > 4 files changed, 191 insertions(+), 26 deletions(-) > > -- > 2.30.2 Jussi, Thank you for this patch. I have a system where the timezone is currently set to "America/Denver" which periodically results in the being incorrectly identified as “Navajo”: 2023-12-22T09:27:46-0700 [19205453]# cat /etc/timezone America/Denver But is identified as “Navajo” here: connmand[<PID>]: src/timezone.c:__connman_timezone_init() connmand[<PID>]: src/timezone.c:__connman_timezone_lookup() sysconfig zone (null) connmand[<PID>]: src/timezone.c:__connman_timezone_lookup() localtime zone Navajo But in another run is identified as “America/Denver”: connmand[<PID>]: src/timezone.c:__connman_timezone_init() connmand[<PID>]: src/timezone.c:__connman_timezone_lookup() sysconfig zone (null) connmand[<PID>]: src/timezone.c:__connman_timezone_lookup() localtime zone America/Denver I will be eager to see if this patch series fixes this issue. Best, Grant
Hi Jussi, > This patch set amends the functionality added in commit > bce73f1bdbf1aa6fc28d2f75b7780f4f1d8b0e3a by making sure that the ISO3166 code: > - is resolved in every case using both zone1970.tab and zone.tab > - gets set for the technology when it powers up > - and, is kept in sync between technology and device(s) > > Technology now stores the regulatory domain as an internal value which is > changed whenever a change is detected. Similarly each device ensures that the > value is being kept in sync with technology as it is set always when the device > gets powered. Technology gets the change notifification via Ofono or via the > Localtime setting watched by timezone. > > In order to always resolve, or attempt to resolve, the correct ISO3166 code in > every country sub-region both zone1970.tab and the deprecated zone.tab files > are used. Initially the ISO3166 code is retrieved from zone1970.tab but if not > found then the deprecated timezone map is used to get the correct iso ISO3166 > which is used as a search parameter to again search from the zone1970.tab but > this time searching from the string lists. This is needed in special cases, > such as Ålands and Pacific/Midway regions to name but a few, to have the > ISO3166 code set. Otherwise in these regions WiFi plugin, for instance, is > told to use the default region, resulting in some channels being inaccessible. > > > Jussi Laakkonen (3): > technology: Add global regdom and regdom getter > device: Setup regdom when powering up to maintain consistency > timezone: Fix resolving of proper ISO3166 code from tz data > > src/connman.h | 1 + > src/device.c | 11 +++ > src/technology.c | 27 +++++++ > src/timezone.c | 178 ++++++++++++++++++++++++++++++++++++++++------- > 4 files changed, 191 insertions(+), 26 deletions(-) all 3 patches have been applied. Regards Marcel
On 12/22/23 18:33, Grant Erickson wrote: > On Dec 22, 2023, at 7:46 AM, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >> This patch set amends the functionality added in commit >> bce73f1bdbf1aa6fc28d2f75b7780f4f1d8b0e3a by making sure that the ISO3166 code: >> - is resolved in every case using both zone1970.tab and zone.tab >> - gets set for the technology when it powers up >> - and, is kept in sync between technology and device(s) >> >> Technology now stores the regulatory domain as an internal value which is >> changed whenever a change is detected. Similarly each device ensures that the >> value is being kept in sync with technology as it is set always when the device >> gets powered. Technology gets the change notifification via Ofono or via the >> Localtime setting watched by timezone. >> >> In order to always resolve, or attempt to resolve, the correct ISO3166 code in >> every country sub-region both zone1970.tab and the deprecated zone.tab files >> are used. Initially the ISO3166 code is retrieved from zone1970.tab but if not >> found then the deprecated timezone map is used to get the correct iso ISO3166 >> which is used as a search parameter to again search from the zone1970.tab but >> this time searching from the string lists. This is needed in special cases, >> such as Ålands and Pacific/Midway regions to name but a few, to have the >> ISO3166 code set. Otherwise in these regions WiFi plugin, for instance, is >> told to use the default region, resulting in some channels being inaccessible. >> >> >> Jussi Laakkonen (3): >> technology: Add global regdom and regdom getter >> device: Setup regdom when powering up to maintain consistency >> timezone: Fix resolving of proper ISO3166 code from tz data >> >> src/connman.h | 1 + >> src/device.c | 11 +++ >> src/technology.c | 27 +++++++ >> src/timezone.c | 178 ++++++++++++++++++++++++++++++++++++++++------- >> 4 files changed, 191 insertions(+), 26 deletions(-) >> >> -- >> 2.30.2 > > Jussi, > > Thank you for this patch. > > I have a system where the timezone is currently set to "America/Denver" which periodically results in the being incorrectly identified as “Navajo”: > > 2023-12-22T09:27:46-0700 [19205453]# cat /etc/timezone > America/Denver > > But is identified as “Navajo” here: > > connmand[<PID>]: src/timezone.c:__connman_timezone_init() > connmand[<PID>]: src/timezone.c:__connman_timezone_lookup() sysconfig zone (null) > connmand[<PID>]: src/timezone.c:__connman_timezone_lookup() localtime zone Navajo > > But in another run is identified as “America/Denver”: > > connmand[<PID>]: src/timezone.c:__connman_timezone_init() > connmand[<PID>]: src/timezone.c:__connman_timezone_lookup() sysconfig zone (null) > connmand[<PID>]: src/timezone.c:__connman_timezone_lookup() localtime zone America/Denver > > I will be eager to see if this patch series fixes this issue. > > Best, > > Grant > Hi Grant, I think it should help with that issue since comparing the tz files by their content was not ideal as many of them are either equal files or they are symlinks. Like that Navajo vs. America/Denver is, and as well as the case that triggered the need for this change; Mariehamn and Helsinki is: $ ls /usr/share/zoneinfo/*/Navajo -l lrwxrwxrwx 1 root root 14 Dec 1 23:51 /usr/share/zoneinfo/posix/Navajo -> America/Denver lrwxrwxrwx 1 root root 14 Dec 1 23:51 /usr/share/zoneinfo/right/Navajo -> America/Denver and $ ls /usr/share/zoneinfo/*Navajo -l lrwxrwxrwx 1 root root 14 Dec 1 23:51 /usr/share/zoneinfo/Navajo -> America/Denver Likewise Mariehamn -> Helsinki: $ ls /usr/share/zoneinfo/*/Mariehamn -l lrwxrwxrwx 1 root root 8 Dec 1 23:51 /usr/share/zoneinfo/Europe/Mariehamn -> Helsinki Did a small test on our devices and they do seem to set the correct one with America/Denver set as timezone, at bootup and when changing it manually. I guess you are also using the option to set the regdom on timezone changes in the configuration and not to rely on ofono plugin to set regdom? The change for the option was included in commits: f035539d46ac23ccb8916ed7ae8d38ab553d32b1 to support path for localtime aaab2161b247588bbee32fefe775ef55acc69c4d to set regdom to follow timezone Let me know how it works on other systems. Cheers! - Jussi