About specifications

Recently we had reported several problems regarding PDU SMS decoding in gnokii. Apparently gnokii was unable to decode several messages that included TP-Parameter-Indicator field. Together with Daniele we’ve come across a specification, namely ETSI TS 123 040. There in chapter 9.2.3.27 it describes this field. And I think it is not clear what it claims. At least we and Nokia have different interpretations.

The most significant bit in octet 1 and any other TP-PI octets which may be added later is reserved as an extension bit which when set to a 1 shall indicate that another TP-PI octet follows immediately afterwards.

So, does it mean that there could be several TP-PI octets in row? If so, which one is the valid one? And how does it relate to SMS-SUBMIT-LAYOUT (9.2.2.4) which says that it is just 1 octet?

SMS-STATUS-REPORT layout

Further reading brings more information:

If a Reserved bit is set to „1” then the receiving entity shall ignore the setting. The setting of this bit shall mean that additional information will follow the TP-User-Data, so a receiving entity shall discard any octets following the TP-User-Data.

I completely don’t understand what is the reason for that. We say that there is additional information but it should be ignored? It’s beyond my perception.

Getting back to the problem. The general layout of TP-PI looks as follows:

TP-PI layout

And we had the following octets in the problem report:

  1. 0x9F (1001 1111): extension bit set, 2 reserved bit set, TP-UDL set, TP-DCS set, TP-PID set

Now, depending on interpretation of the specification, we can interpret differently the sequent octets. There are three:

  1. 0xD6 (1101 0110)
  2. 0xE4 (1110 0100)
  3. 0x94 (1001 0100)

First interpretation, is that TP-PI can be followed by next TP-PI octet, based on value of bit 7. All these records have it set, so we go till the last octet which would be TP-PI as well, but then there’s no room for at least TP-UDL which should be set. Doesn’t look right.

So, second interpretation (along with SMS-STATUS-REPORT layout): TP-PID, TP-DCS and TP-UDL will follow TP-PI octet. So we have:

  1. TP-PID: 0xD6, indicating that it is message for SC (Service Centre) specific use
  2. TP-DCS: 0xE4, indicating Message Waiting type (however it uses bit 2 which is reserved)
  3. TP-UDL: 0x94, which does not make sense as there are no more octets

So this interpretation looks even worse than the previous one. I’m used to bugs in software but this one really confuses me: I have no idea what would be a good way to interpret the message from the report. I’m committing the change that incorporated the first interpretation and doesn’t bother with missing TP-PID, TP-DCS, TP-UDL octets.

To summarize: specifications are good, but not all of them. Really try to be precise and unambiguous when writing a specification.

Reklamy

Programatore amatore

Uwielbiam fantastycznie udokumentowane i rozsądnie działające biblioteki. Jest taka fajna, libusb, która w zasadzie eliminuje konieczność modyfikowania jądra przy dodawaniu obsługi nowych urządzeń. Poza różnymi innymi funkcjami są odpowiedniki read() i write(): usb_bulk_read(), usb_bulk_write().

Sporo czasu w ciągu ostatnich dni spędziłem śledząc błąd w gnokii, który w uproszczeniu polegał na tym, że gubiły się dane w transmisji. Miałem bufor wielkości 255 bajtów i gdy odpowiedź od telefonu przekraczała te 255 bajtów, zawsze 64 bajty ze środka znikały.

Co się okazało? Telefon przesyła dane w paczkach po 64 bajty (to nawet widać w wynikach lsusb). Telefon zwraca dane w paczkach o wielkości będącej wielokrotnością 64 bajtów (a więc …, 192, 256, …) oprócz ostatniej oczywiście. Jeśli bufor jest mniejszy niż zwrócona paczka, to dane są obcinane do największej wielokrotności 64 mniejszej niż wielkość bufora (dokładniej: nie dane tylko wynik funkcji mówiący ile bajtów przeczytano). Co się dzieje z pozostałymi danymi? Nic. Nie trafia nawet informacja do loga o tym że coś się gubi.

I love this game…

gadżet

From: noreply@maemo.org
Subject: N810 maemo submission accepted

N810 maemo submission accepted

Congratulations! You have been accepted to the N810 maemo device
program. We will send your discount and instructions as soon as the
device is available in your selected shop (soon).

maemo team – http://maemo.org

Nokia N810

Będzie nowy gadżet 🙂

Synchronizacja

Działa. I to pod Linuksem. Udało mi się zsynchronizować książkę adresową z Nokii 6021 do Nokii e50 bez specjalnego kombinowania. Oto recepta:

  pkot@bua:~$ msynctool --addgroup 6021toE50
  pkot@bua:~$ msynctool --addmember 6021toE50 gnokii-sync
  pkot@bua:~$ msynctool --addmember 6021toE50 syncml-obex-client
  pkot@bua:~$ msynctool --configure 6021toE50 1
  <config>
    <connection>irda</connection>
    <port>/dev/ircomm0</port>
    <model>6021</model>
  </config>
  pkot@bua:~$ msynctool --configure 6021toE50 2
  <?xml version="1.0"?>
  <config>
    <bluetooth_address>00:18:8D:68:91:3A</bluetooth_address>
    <bluetooth_channel>10</bluetooth_channel>
    <interface>0</interface>
    <identifier>PC Suite</identifier>
    <version>1</version>
    <wbxml>1</wbxml>
    <username></username>
    <password></password>
    <type>2</type>
    <usestringtable>1</usestringtable>
    <onlyreplace>0</onlyreplace>
    <onlyLocaltime>0</onlyLocaltime>
    <recvLimit>0</recvLimit>
    <maxObjSize>0</maxObjSize>
    <contact_db>Contacts</contact_db>
    <calendar_db></calendar_db>
    <note_db></note_db>
  </config>
  pkot@bua:~$ msynctool --sync 6021toE50
  [...]
  pkot@bua:~$

Chwila czekania… i voila! Zrobione!

gnokii 0.6.15

Po 8 miesiącach udało mi się w końcu wydać nową wersję gnokii. I to nie dlatego że zmian było mało, tylko dlatego że cały czas chciałem jeszcze coś poprawić. Zupełnie jakbym nic nie nauczył się na temat zarządzania projektem Open Source. Ale w końcu wyszło mi, że będę musiał zrobić małą rewolucję w kodzie, aby doprowadzić do końca to, co chciałem. Zatem już jest i ma nawet pełne polskie tłumaczenie! Taki byłem!

Teraz mam zamiar zmienić nieco sposób rozwijania gnokii. Chcę się bardziej skupić na nowych fajnych rzeczach i olać niby podstawowe rzeczy jak zgodność biblioteki wstecz. Trudno — lepiej żeby się coś działo niż żeby się nic nie działo. Będą dwa drzewa — bieżąca 0.6.x, do której będą trafiały jakieś poprawki, jeśli komuś się zechce je robić oraz nowa 0.7.x, gdzie będzie z grubsza wolna amerykanka. A planów trochę jest (wyniesienie konfiguracji telefonów do zewnętrznego pliku, dynamiczne ładowanie sterowników, obsługa Symbiana S60 v3, obsługa wszystkich nowych wynalazków, lepsza integracja z istniejącymi frontendami typu gnome phone manager). Oczywiście plany szumne, a wyjdzie jak zwykle, chyba że się znajdzie ktoś młody i ambitny, kto weźmie na siebie ciężar programowania.
Ale żeby nie było tak różowo, to oczywiście okazało się, że nie kompiluje się pod Solarisem (tfu!). Poprawki już są w CVS, ale pewnie jeszcze coś wylezie więc pewnie 0.6.16 pod koniec tygodnia.