From: Steffen Neubauer stefreak@stefreak.de
- Added function "gsm340_scts" to decode the service center time stamp into a UTC/GMT timestamp - in function gsm340_validity_period: can now decode validity period format absolute.
I hope it's good ;)
Greetings, Steffen
Dear Steffen,
thanks for your patch, it is most welcome. Sorry for not providing feedback earlier. Please see my comments below:
- case GSM340_TP_VPF_ABSOLUTE:
- case GSM340_TP_VPF_ABSOLUTE: ; /* Chapter 9.2.3.12.2 */
/* FIXME: like service center time stamp */
DEBUGP(DSMS, "VPI absolute not implemented yet\n");
time_t expires = gsm340_scts(sms_vp);
time_t now = mktime(gmtime(NULL));
if (expires <= now)
minutes = 0;
else
minutes = (expires-now)/60;
please declare the variables (expires/now) at the beginning of the section, e.g. the case statement or even the top of the function.
+/* Turn semi-octet representation into int: 0x89 => 98 */ +static u_int8_t unbcdify(u_int8_t value) +{
- u_int8_t ret;
- ret = (value&0x0F)*10;
- ret += value>>4;
- return ret;
+}
we might want to have some kind of treatment (or at least an error message) if the input BCD nibbles exceed the 0...9 range.
static void gsm340_gen_scts(u_int8_t *scts, time_t time) {
- struct tm *tm = localtime(&time);
struct tm *tm = gmtime(&time);
*scts++ = bcdify(tm->tm_year % 100); *scts++ = bcdify(tm->tm_mon + 1);
@@ -338,7 +356,30 @@ static void gsm340_gen_scts(u_int8_t *scts, time_t time) *scts++ = bcdify(tm->tm_hour); *scts++ = bcdify(tm->tm_min); *scts++ = bcdify(tm->tm_sec);
- *scts++ = 0; /* FIXME: timezone */
- *scts++ = 0; /* FIXME: local timezone */
+}
mh. We are no wending GMT but no timezone information, which I'm not quite sure if it is better than we did before. A proper solution would be to use the signed value of tm->tm_gmtoff/(60*15);
+/* Decode 03.40 TP-SCTS (into utc/gmt timestamp) */ +static time_t gsm340_scts(u_int8_t *scts) +{
- struct tm tm;
- u_int8_t yr = unbcdify(*scts++);
- printf("%i",yr);
- if (yr <= 60)
tm.tm_year = 100 + yr;
- else
tm.tm_year = yr;
is this year '60' specified anywhere in the GSM spec, or did you just introduce it yourself? In the latter case, I would rather use something like 80, since GSM was not specified before the eighties.
Thanks again, Harald
Hello Harald,
On Sun, 8 Nov 2009 14:39:02 +0900 Harald Welte laforge@gnumonks.org wrote:
thanks for your patch, it is most welcome. Sorry for not providing feedback earlier. Please see my comments below:
no problem, thank you for your comment! :)
please declare the variables (expires/now) at the beginning of the section, e.g. the case statement or even the top of the function.
They were declared at the beginning of the case statement, aren't they? But now they are declared on top of the function.
we might want to have some kind of treatment (or at least an error message) if the input BCD nibbles exceed the 0...9 range.
Okay, now it sends a debug message.
mh. We are no wending GMT but no timezone information, which I'm not quite sure if it is better than we did before. A proper solution would be to use the signed value of tm->tm_gmtoff/(60*15);
Before it sent the local time but with the timezone information "GMT/UTC" (offset=0). But now it sends the local timezone and the local timezone information.
is this year '60' specified anywhere in the GSM spec, or did you just introduce it yourself? In the latter case, I would rather use something like 80, since GSM was not specified before the eighties.
No, the spec didn't specify this anywhere, even not in the newest version of the document. You're right, 80 is a better value. Fixed it ;)
Thanks again, Harald
I have to thank you!
The new patch is attached :)
Greetings, Steffen
On Sun, 8 Nov 2009 14:08:56 +0100 Steffen 'stefreak' Neubauer stefreak@stefreak.de wrote:
The new patch is attached :)
Oh i have to say that i have not really tested it - but it compiles fine :) I'm sorry; testing is not easy without a BTS :) I hope that's ok!
Greetings, Steffen
Thanks,
I've now merged it, despite it is untested.
I don't think it can seriously break any existing functionality... and if we add some code for a feature that was missing before, having a (possibly) still buggy implementation doesn't hurt either.
It would be great if somebody could test the correct timezone setting and the VPF functionality in general.
One way to test this (and continue to test it in the future) is to write a test that uses hard-coded TPDU's or CP-DATA blocks (preferrably captured from real-world SMS) and feeds them through our code and checks if the result is as expected.