4.3.0 Beta feedback

[KN2TOD]

I found that I had to run "sudo systemctl restart dhcpcd.service" after killing off the RAM disks and rebooting in order to establish a connection. Manageable perhaps, but another pain nevertheless.

There's gotta be a better, less risky. less involved way to do all this. Updates/upgrades used to be seamless.

[G8SEZ]

I found that I had to run "sudo systemctl restart dhcpcd.service" after killing off the RAM disks and rebooting in order to establish a connection. Manageable perhaps, but another pain nevertheless.

There's gotta be a better, less risky. less involved way to do all this. Updates/upgrades used to be seamless.

As far as I know Bookworm has moved to using network manager but I am not sure how to get Pi-Star to function with the latest versions of the various packages that have been updated. I realise that 4.3.0 is a beta still, but it would be nice to get this sort of thing sorted out in a seamless manner.

[KN2TOD]

Bookworm offers NetManager but the old mechanisms are still supported: Pi-Star has not moved to that alternate mechanism. Regardless, they all still involve/invoke DHCPCD services. And they all depend on various directories allocated in TMPFS. So when you temporally reallocate those directories, problems arise during subsequent processing.

[G8SEZ]

Bookworm offers NetManager but the old mechanisms are still supported: Pi-Star has not moved to that alternate mechanism. Regardless, they all still involve/invoke DHCPCD services. And they all depend on various directories allocated in TMPFS. So when you temporally reallocate those directories, problems arise during subsequent processing.

And if I don't reallocate the tmpfs stuff then the upgrade process falls over when rebuilding initramfs.

[KN2TOD]

The messages coming out of the update/upgrade process are misleading as to the exact cause of the problem: not enough memory to build temp files? unpack files? not enough space allocated in TMP directory?

Playing around with this it a bit on the latest upgrade, I found that INCREASING the /tmp directory allocation to 100m (from its original 64m?) seems to have fixed the problem:

Code: Select all

#File System            Mountpoint              Type    Options                                         Dump    Pass
proc                    /proc                   proc    defaults                                        0       0
PARTUUID=2037f4fb-01    /boot/firmware          vfat    defaults,ro                                     0       2
PARTUUID=2037f4fb-02    /                       ext4    defaults,noatime,ro                             0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
tmpfs                   /run                    tmpfs   nodev,noatime,nosuid,mode=1777,size=32m         0       0
tmpfs                   /run/lock               tmpfs   nodev,noatime,nosuid,mode=1777,size=5m          0       0
tmpfs                   /sys/fs/cgroup          tmpfs   nodev,noatime                                   0       0
tmpfs                   /tmp                    tmpfs   nodev,noatime,nosuid,mode=1777,size=100m        0       0   <----
tmpfs                   /var/log                tmpfs   nodev,noatime,nosuid,mode=0755,size=64m         0       0
tmpfs                   /var/lib/sudo           tmpfs   nodev,noatime,nosuid,mode=1777,size=16k         0       0
tmpfs                   /var/lib/dhcpcd         tmpfs   nodev,noatime,nosuid,mode=1777,size=32k         0       0
tmpfs                   /var/lib/vnstat         tmpfs   nodev,noatime,nosuid,mode=1777,size=4m          0       0
tmpfs                   /var/lib/logrotate      tmpfs   nodev,noatime,nosuid,mode=0755,size=16k         0       0
tmpfs                   /var/lib/nginx/body     tmpfs   nodev,noatime,nosuid,mode=1700,size=1m          0       0
tmpfs                   /var/lib/php/sessions   tmpfs   nodev,noatime,nosuid,mode=0777,size=64k         0       0
tmpfs                   /var/lib/samba/private  tmpfs   nodev,noatime,nosuid,mode=0755,size=4m          0       0
tmpfs                   /var/cache/samba        tmpfs   nodev,noatime,nosuid,mode=0755,size=1m          0       0

Will monitor this over that next bunch of system updates as they roll out to see if this tweak holds.

YMMV

----

Subsequent testing with some other systems: 72m seems to be insufficient, but 96m works!

[KN2TOD]

Erroneous Local RF entries may appear from time to time in the dashboard, entries that seemingly are not associated with any particular call sign but are of DMR origin.

---

The problem stems from a change in the way Talker Aliases are logged by the older versions of the MMDVM host program compared to how they are logged now:

The older style log messages are not differentiated (essentially "slotless"):

Code: Select all

M: 2024-12-10 13:07:25.553 0000:  05 00 48 65 6C 64 69 73 00                         *..Heldis.*
M: 2024-12-10 13:07:29.612 DMR Slot 2, received network end of voice transmission from ES3EA to TG 310999, 5.2 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-10 13:24:59.265 DMR Slot 2, received network voice header from WX4WCS to TG 3113
M: 2024-12-10 13:24:59.503 DMR Slot 2, received network end of voice transmission from WX4WCS to TG 3113, 0.5 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-10 13:33:52.197 DMR Slot 2, received network voice header from N4OKN to TG 31131
M: 2024-12-10 13:33:52.837 DMR Talker Alias (Data Format 3, Received 3/13 char): 'N4O'
M: 2024-12-10 13:33:52.837 DMR Slot 2, Embedded Talker Alias Header
M: 2024-12-10 13:33:52.837 0000:  04 00 DA 00 4E 00 34 00 4F                         *....N.4.O*
M: 2024-12-10 13:33:53.559 DMR Talker Alias (Data Format 3, Received 6/13 char): 'N4OKN '
M: 2024-12-10 13:33:53.589 DMR Slot 2, Embedded Talker Alias Block 1
M: 2024-12-10 13:33:53.589 0000:  05 00 00 4B 00 4E 00 20 00                         *...K.N. .*
M: 2024-12-10 13:33:54.136 DMR Slot 2, received network end of voice transmission from N4OKN to TG 31131, 2.0 seconds, 0% packet loss, BER: 0.9%
M: 2024-12-10 13:34:35.991 DMR Slot 2, received network voice header from N4OKN to TG 31131
M: 2024-12-10 13:34:36.481 DMR Talker Alias (Data Format 3, Received 3/13 char): 'N4O'
M: 2024-12-10 13:34:36.481 DMR Slot 2, Embedded Talker Alias Header
M: 2024-12-10 13:34:36.481 0000:  04 00 DA 00 4E 00 34 00 4F                         *....N.4.O*
M: 2024-12-10 13:34:37.182 DMR Talker Alias (Data Format 3, Received 6/13 char): 'N4OKN '
M: 2024-12-10 13:34:37.213 DMR Slot 2, Embedded Talker Alias Block 1
M: 2024-12-10 13:34:37.213 0000:  05 00 00 4B 00 4E 00 20 00                         *...K.N. .*
M: 2024-12-10 13:34:37.672 DMR Slot 2, received network end of voice transmission from N4OKN to TG 31131, 1.9 seconds, 0% packet loss, BER: 0.0%

While the revised programs log TA's differently:

Code: Select all

M: 2024-12-10 05:40:23.731 DMR Slot 1, Talker Alias "XE3JCL 73 from Mérida "
M: 2024-12-10 05:40:59.482 DMR Slot 1, received network end of voice transmission from XE3JCL to TG 91, 38.3 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-10 05:41:02.224 DMR Slot 1, received network voice header from KQ4UXJ to TG 91
M: 2024-12-10 05:41:04.679 DMR Slot 1, Talker Alias "KQ4UXJ DMR ID"
M: 2024-12-10 05:41:42.907 DMR Slot 1, received network end of voice transmission from KQ4UXJ to TG 91, 40.9 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-10 05:41:47.548 DMR Slot 1, received network voice header from XE3JCL to TG 91
M: 2024-12-10 05:41:49.654 DMR Slot 1, Talker Alias "XE3JCL 73 from Mérida "
M: 2024-12-10 05:41:52.663 DMR Slot 1, received network end of voice transmission from XE3JCL to TG 91, 5.5 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-10 05:42:06.684 DMR Slot 1, received network voice header from IZ8OFK to TG 91
M: 2024-12-10 05:42:06.710 DMR Slot 1, received network end of voice transmission from IZ8OFK to TG 91, 0.5 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-10 05:42:09.780 DMR Slot 1, received network voice header from XE3JCL to TG 91
M: 2024-12-10 05:42:11.880 DMR Slot 1, Talker Alias "XE3JCL 73 from Mérida "
M: 2024-12-10 05:42:34.678 DMR Slot 1, received network end of voice transmission from XE3JCL to TG 91, 25.3 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-10 05:42:45.323 DMR Slot 1, received network voice header from KQ4IBD to TG 91
M: 2024-12-10 05:42:47.928 DMR Slot 1, Talker Alias "KQ4IBD Christ"
M: 2024-12-10 05:42:56.324 DMR Slot 1, received network end of voice transmission from KQ4IBD to TG 91, 11.3 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-10 05:43:02.503 DMR Slot 1, received network voice header from AA6IO to TG 91
M: 2024-12-10 05:43:02.581 DMR Slot 1, received network end of voice transmission from AA6IO to TG 91, 0.5 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-10 05:43:16.569 DMR Slot 1, received network voice header from AA6IO to TG 91

The problem is that the older style TA's get filtered out but the newer forms get passed through to the Last Heard list and eventually result in the bogus entries in the Local RF display.

(Those more astute may notice that the sample TA's shown above contain a special character in the alias and, yes, that is the root cause of problem, as the selection processing for the Local RF display goes awry because of those characters - without the special characters, the errant entries went undetected/are not displayed.)

The solution is to add another filter to the appropriate routine (functions.php):

Code: Select all

                         :
                } else if(strpos($logLine,"non repeater RF header received")) {
                        continue;
                } else if(strpos($logLine,"Embedded Talker Alias")) {
                        continue;
                } else if(strpos($logLine,"DMR Talker Alias")) {
                        continue;
                } else if(strpos($logLine,", Talker Alias ")) {   // add
                        continue;                                 // add
                } else if(strpos($logLine,"CSBK Preamble")) {
                        continue;
                         :

[KN2TOD]

The "Network 6" section of the mmdvm configuration file can be corrupted by the dashboard's configuration panel, forcing users to only manipulate the config via the expert edits. Specifically, the password= and options= entries were being dropped if you made changes via the dashboard's config panel.

The following patch fixes this situation:

Code: Select all

sudo sed -i 's/isset(\$configdmrgateway\[\x27DMR Network 5\x27\]\[\x27Password\x27.*/&\
        if ( isset($configdmrgateway[\x27DMR Network 6\x27][\x27Password\x27]) \&\& substr($configdmrgateway[\x27DMR Network 6\x27][\x27Password\x27], 0, 1) !== \x27"\x27 )    { $configdmrgateway[\x27DMR Network 6\x27][\x27Password\x27] = \x27"\x27.$configdmrgateway[\x27DMR Network 6\x27][\x27Password\x27].\x27"\x27; }\
        if ( isset($configdmrgateway[\x27DMR Network 6\x27][\x27Options\x27]) \&\&  substr($configdmrgateway[\x27DMR Network 6\x27][\x27Options\x27], 0, 1) !== \x27"\x27 )     { $configdmrgateway[\x27DMR Network 6\x27][\x27Options\x27] = \x27"\x27.$configdmrgateway[\x27DMR Network 6\x27][\x27Options\x27].\x27"\x27; }/g' /var/www/dashboard/admin/configure.php

In addition, the "Network 6" settings are not being examined properly by the TGIF links and linkage manager routines:

Code: Select all

sudo sed -i 's/.*} else if ( \$dmrMasterHost == \x27tgif.network\x27 ) {.*/\
            if (isset($configdmrgateway[\x27DMR Network 6\x27][\x27Address\x27])) {\
              if (($configdmrgateway[\x27DMR Network 6\x27][\x27Address\x27] == "tgif.network") \&\& ($configdmrgateway[\x27DMR Network 6\x27][\x27Enabled\x27])) {\
                $dmrID = $configdmrgateway[\x27DMR Network 6\x27][\x27Id\x27];\
              }\
            }\n&/g' /var/www/dashboard/mmdvmhost/tgif_manager.php

----

sudo sed -i 's/.*} else if ( \$dmrMasterHost == \x27tgif.network\x27 ) {.*/\
    if (isset($configdmrgateway[\x27DMR Network 6\x27][\x27Address\x27])) {\
      if (($configdmrgateway[\x27DMR Network 6\x27][\x27Address\x27] == "tgif.network") \&\& ($configdmrgateway[\x27DMR Network 6\x27][\x27Enabled\x27])) {\
        $dmrID = $configdmrgateway[\x27DMR Network 6\x27][\x27Id\x27];\
      }\
    }\n&/g' /var/www/dashboard/mmdvmhost/tgif_links.php

[KA1PIT]

I have a pi zero V2, it was running fine with Pi-Star_RPi_V4.3.0_10-Feb-2024, plus updated two weeks back.

Last week I did a sudo pistar-update and -upgrade, the network was not found. the nextion screen said "address unknown".

Today I re-flashed the 32g sd card with Pi-Star_RPi_V4.3.0_10-Feb-2024. I configured the pi-star for DMR.
Soft reboot, login in to pi-star with its IP address. Went to SSH access and did a sudo pistar-update and -upgrade, and
all went well. Everything is running, Nextion screen(my screen) looks good. Now I did a power down, pull the
power plug, plug it back in, it boots up and my nextion screen comes up. It says "address unknown".
Now I can't get to the pi-star. I'm stuck here. But my router see the IP address.

Has anyone seen this and can you help me?

thanks
scott

[PA5WIL]

I have since february 2024 version 4.3.0. I have never notice a update when i use in pi-star configuration/ update

[G8SEZ]

I have since february 2024 version 4.3.0. I have never notice a update when i use in pi-star configuration/ update

If you ssh in and use pistar-update it will download the OS updates, not just Pi-Star updates. That's when recent changes break things and Andy has not yet fixed those.