Config Override: Difference between revisions

From Sharpfin
Jump to navigation Jump to search
(New page: == Config Override == This feature has been used in ernest on IR100 following the official release of FW v.257-a-421-a-057. Before the release, the file read: Option: dst-policy ec9 ...)
 
No edit summary
 
(3 intermediate revisions by 2 users not shown)
Line 11: Line 11:
The IR100 seem to have sprouted several related files as well, the purpose of which is at this time fairly mysterious save to say that they all collude to restrict the config options which many of us have written into our configs. The /mnt/config/DSCO_ConfigOverride.txt file reads:
The IR100 seem to have sprouted several related files as well, the purpose of which is at this time fairly mysterious save to say that they all collude to restrict the config options which many of us have written into our configs. The /mnt/config/DSCO_ConfigOverride.txt file reads:


Content-Length
Content-Disposition attachment; filename=/root/config/DSCO_ConfigOverride.txt; size=214


  Option:
  Option:
Line 53: Line 51:


The only way to avoid this as things stand would seem to require a spoofing of the hardware ID of the radio, at least until the Sharpfin application is ready - any ideas?
The only way to avoid this as things stand would seem to require a spoofing of the hardware ID of the radio, at least until the Sharpfin application is ready - any ideas?
'''expectingtofly''' - For info, I've "spoofed" the hardware id on my AE by replacing the /usr/bin/readconfig executable with a shell script that just returned a different hardware ID(I wanted to try and use the MP3Tunes facility that is manufacturer dependent) and it made no difference.  I believe that Reciva are identifying the radio type from the serial number rather than the hardware id


'''trumpton''' - I don't believe this is anything sinister.  I suspect that Reciva have been asked to enable 2 alarms in the IR100 instead of the one that is in the default config1012.txt file.  The most cost-effective way of doing this is to do the config override (as the firmware release was actually produced months ago).
'''trumpton''' - I don't believe this is anything sinister.  I suspect that Reciva have been asked to enable 2 alarms in the IR100 instead of the one that is in the default config1012.txt file.  The most cost-effective way of doing this is to do the config override (as the firmware release was actually produced months ago).


On the subject of the 'Sharpfin Application' - this will be ready when someone volunteers to write it!  Everybody seems to be hanging around waiting for someone else to write it!
On the subject of the 'Sharpfin Application' - this will be ready when someone volunteers to write it!  Everybody seems to be hanging around waiting for someone else to write it!

Latest revision as of 11:35, 5 October 2014

Config Override

This feature has been used in ernest on IR100 following the official release of FW v.257-a-421-a-057. Before the release, the file read:

Option:
dst-policy
ec9

The recent official release of Firmware v257-a-421-a-057 for the IR100 has been recently well recieved, however, Reciva or DSG or both have taken the opportunity to make more use of the config file on the machine, located at /mnt/config/DSCO_ConfigOverride.txt.

The IR100 seem to have sprouted several related files as well, the purpose of which is at this time fairly mysterious save to say that they all collude to restrict the config options which many of us have written into our configs. The /mnt/config/DSCO_ConfigOverride.txt file reads:


Option:
dst-policy
ec9
Option:
acpoweron-state
standby
Option:
number-of-alarms
2
Option:
alarm-clock
config1
Option:
hierarchical-locations
on
Option:
buzzer-long-repeat
250
Option:
buzzer-short-repeat
250

These strings override any changes made by the user using the same values in any other config file.

The most obvious and irritating result of this file is to restrict the number of available alarms to 2,though it also restores the god awful 'continent' menu to the stations browser.

This file is pushed onto radios which do not have it, whether they have had a firmware update or not and appears to be unrelated to firmware version, a quick install of the 257-a-421-a-041 FW used on the Tangent proved that! It seems to be reliant on the hardware ID to install.

It is a modification to the config structure for the 1012 model, as to whether this indignity will be foisted on other models remains to be seen.

The /mnt folder appears to be purposely configured to be innaccessible to users, the radio files relating to presets, alarms and other such functions are located here, so the folder cannot be write protected and there appear to be no access rights through Sharpfin.

The only way to avoid this as things stand would seem to require a spoofing of the hardware ID of the radio, at least until the Sharpfin application is ready - any ideas?

expectingtofly - For info, I've "spoofed" the hardware id on my AE by replacing the /usr/bin/readconfig executable with a shell script that just returned a different hardware ID(I wanted to try and use the MP3Tunes facility that is manufacturer dependent) and it made no difference. I believe that Reciva are identifying the radio type from the serial number rather than the hardware id

trumpton - I don't believe this is anything sinister. I suspect that Reciva have been asked to enable 2 alarms in the IR100 instead of the one that is in the default config1012.txt file. The most cost-effective way of doing this is to do the config override (as the firmware release was actually produced months ago).

On the subject of the 'Sharpfin Application' - this will be ready when someone volunteers to write it! Everybody seems to be hanging around waiting for someone else to write it!