That name already sounds creepy enough, but searching for that string (with the quotes) currently returns only 4 results, of people asking what it is. My guess is some sort of hidden backdoor, disguised as an ostensibly useful feature.
That name already sounds creepy enough, but searching for that string (with the quotes) currently returns only 4 results, of people asking what it is. My guess is some sort of hidden backdoor, disguised as an ostensibly useful feature.
That seems to be the way to keep consumer grade routers from requiring the user walk over and reboot them once a week...
Domestic routers, in particular, are infamous for their web interface and management daemons often calling command line programs through system() to configure the network (and other system management tasks), instead of directly using the APIs these command line programs use. Not only is this inefficient and fragile, it also not rarely leads to being vulnerable to shell injection attacks (if you're lucky, only exploitable by authenticated users of the web interface).
In this particular case, the set of states that the device is in when it boots is relatively small compared to the set of states that device may be in a week later. More generally, all individual complex systems need to be "restarted" periodically, it's just a question of how often.
This is very common when I look to find source for embedded devices like this. What I expect is the next step is that you will find (or be given) a borderline useless blob of source that doesn't explain any of it's build process, which is absurd because the GPL clearly defines the build "glue" as part of the source.
Is ASUS another company that is doing a poor job of GPL compliance in this space?
Is it intentional?
So DSP magic?