From: Riley Williams (ktfdobmv@ncalions.org)
Date: Fri Mar 01 2002 - 22:27:48 EET
Hi Tomi.
>>>> Beware that this can cause problems with other programs that use
>>>> Predict as a server. For example gsat segfaults, apparently because
>>>> it doesn't check the size of the satellite list received from the
>>>> server and this results in a buffer overflow (gsat is hardcoded for
>>>> 26 satellites IIRC).
>> As part of my patch, I will be dealing with problems encountered in
>> ALL of the clients included with predict, so the above shouldn't be
>> a problem when I've finished.
> Riley, as long as you are playing with the predict source, let me
> tell you what I would like it to be. :-)
Thanks.
> I would like to see a predictd daemon completely without any UI
> whatsoever.
Eventually, I'd like to see that, but for testing purposes, I'll be
retaining the UI for the time being.
> It would handle unlimited amount of satellites and the TLE data
> could be updated without taking the daemon down (standard way would
> be to make the daemon re-read its config files upon receiving
> SIGHUP, I guess).
Whilst that's certainly possible, I could see problems with that.
> Needless to say the clients (that would also include a ncurses
> client similar to the current predict UI) should not make any
> assumptions on any data the server might give.
> Including the number of satellites.
To be reasonable, the clients should be able to ask the server for any
limits it may reasonably need. The number of satellites the server can
supply it with is a perfect example of such information, and is an early
planned addition. Expect a patch shortly...
> Just my 0.02 ¤ ... :)
Many thanks.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to wvpnt@kht.ru
More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2b30 : Fri Mar 01 2002 - 22:30:50 EET