28 Oct
2009
28 Oct
'09
4:02 p.m.
From: Steffen Neubauer <stefreak(a)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
8 Nov
8 Nov
6:39 a.m.
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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
2:08 p.m.
Hello Harald,
On Sun, 8 Nov 2009 14:39:02 +0900
Harald Welte <laforge(a)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
2:14 p.m.
On Sun, 8 Nov 2009 14:08:56 +0100
Steffen 'stefreak' Neubauer <stefreak(a)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
11 Nov
11 Nov
3:04 p.m.
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.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5815
days inactive
5829
days old
4 comments
2 participants
participants (2)
-
Harald Welte -
Steffen 'stefreak' Neubauer