Hi Alexander, you're actually right here.
It's not that I was reading the _spec_ wrong, but the code itself. It appeared to me that the code esd assuming this TLV to be a printable C-octet string instead of an octet string. The actual bug was really in my smppbox code which I shall now fix. My bad, sorry for stealing your time on this. :) 2010/8/5 Alexander Malysh <[email protected]>: > Hi Victor, > > I don't know how I should make clearer for you (Type=OctetString Length=3). > This is from the latest SMPP spec v5.0: > > > > > Am 04.08.2010 um 21:36 schrieb Victor Luchitz: > >> Please be so kind point me to a place in the SPEC that says that says >> that this TLV should be encoded and decoded in the way bearerbox does. >> >> Seriously, intead of properly parsing a legitimate value of 0x0300ff >> for this tag, bearerbox simply drops it with message >> "SMPP: Optional field network_error_code with invalid length dropped." >> upon encountering the second octet, which is treated as a >> null-termination char. It's also impossible to write a value such as >> 0x0300ff from smppbox for the same reason, the tag is simply dropped. >> >> I strongly encourage you to drop the "holier than thou" attitude >> regarding your reading of the SMPP spec. >> >> 2010/8/4 Alexander Malysh <[email protected]>: >>> Hi, >>> >>> you can pack every integer in one octet as long as integer not greater 256. >>> And I saw very much SMSCs that make use of this TLV and they use it as >>> described in SMPP spec and me. >>> >>> Thanks, >>> Alexander Malysh >>> >>> Am 04.08.2010 um 19:28 schrieb Rene Kluwen: >>> >>>> Sorry, forgot to copy the list. >>>> >>>> -----Original Message----- >>>> From: Rene Kluwen [mailto:[email protected]] >>>> Sent: Wednesday, 04 August, 2010 19:25 >>>> To: '[email protected]' >>>> Subject: RE: SMPP's network_error_code TLV >>>> >>>> I am looking at the foopics link now. >>>> >>>> They have error type as 1 octet and Error code as 2 octets. >>>> >>>> Doesn't that prove Alex is right? >>>> >>>> I mean if it was the other way around, you would get: >>>> >>>> Error type: 0x0300 >>>> Error code: 0xff >>>> >>>> == Rene >>>> >>>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] >>>> Sent: Wednesday, 04 August, 2010 19:13 >>>> To: Rene Kluwen >>>> Subject: Re: SMPP's network_error_code TLV >>>> >>>> I'm not going to give up on this easily :) >>>> >>>> http://www.foopics.com/showfull/e58a2be383ae3c219822d4f3f9b97763 >>>> >>>> Considering how Wireshark parses this TLV, SMPP spec's definition of >>>> "Integer" - "An unsigned value with the defined number of octets. The >>>> octets will always be transmitted MSB first (Big Endian)" and >>>> considering the fact that passing integer values as printable characters >>>> is such a waste of precious bits that no one would need such a TLV, I >>>> still hold my opinion as valid :) >>>> >>>> On 04.08.2010 19:10, Rene Kluwen wrote: >>>>> That's clear. So what does Integer mean here? Network byte order? Or the >>>>> other way around. >>>>> In case the field is defined as C-string, then I presume printable ascii >>>>> character. But maybe I am wrong here. >>>>> This because, reading the specs they mean the first "Integer" is one >>>>> octet and the second "Integer" two octets. >>>>> >>>>> But still (also according to your own reasoning) I think Alex is right. >>>>> >>>>> == Rene >>>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] On >>>>> Behalf Of Victor Luchitz >>>>> Sent: Wednesday, 04 August, 2010 17:00 >>>>> To: Kannel Devel >>>>> Subject: Re: Re: SMPP's network_error_code TLV >>>>> >>>>> The term "octet" is used to avoid usage of the vague term "byte", >>>>> which is architecture/machine dependent. One can define "byte" as 5 >>>>> oits and that'd be perfectly valid. >>>>> >>>>> What I'm trying to say is that "octet" != "printable ascii character" >>>>> >>>>> 2010/8/4 Rene Kluwen<[email protected]>: >>>>>> Victor, >>>>>> >>>>>> I think the "Integer" types that you write below are an error in de SMPP >>>>>> specification. >>>>>> Even you wrote yourself (see below): " single-octet network code and >>>>>> two-octets error code". >>>>>> >>>>>> So it should contain (copied from specs): >>>>>> >>>>>> The _first octet_ indicates the network type. >>>>>> The following values are defined: >>>>>> 1 = ANSI-136 >>>>>> 2 = IS-95 >>>>>> 3 = GSM >>>>>> 4 = Reserved >>>>>> All other values reserved. >>>>>> The remaining _two octets_ specify the actual >>>>>> network error code appropriate to the >>>>>> network type. >>>>>> >>>>>> So I tend to agree with Alex more. >>>>>> >>>>>> Now what strikes me is that the value is defines as a C-string. Which >>>>>> leaves no space anymore for the terminating '\0'! >>>>>> >>>>>> =-= Rene >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: [email protected] [mailto:[email protected]] On >>>>>> Behalf Of Victor Luchitz >>>>>> Sent: Wednesday, 04 August, 2010 15:33 >>>>>> To: Kannel Devel >>>>>> Subject: Re: Re: SMPP's network_error_code TLV >>>>>> >>>>>> Nope, I think do understand the SMPP spec correctly. >>>>>> >>>>>> Description for this field (page 152 of SMPP v3.4 Issue 2 spec) says >>>>>> the following: >>>>>> >>>>>> Sub-field Size Type >>>>>> Network Type 1 Integer >>>>>> Error Code 2 Integer >>>>>> >>>>>> Note that the spec explicitly defines those subfields as integers, not >>>>>> octet strings. Besides the "3ff" representation is vague since the >>>>>> spec doesn't mention the integer values are allowed to be passed in >>>>>> hex format. And how would you transmit an error code> 0xff if you >>>>>> still reserved to using octet strings? >>>>>> >>>>>> All of the above wouldn't matter if we didn't have at least one client >>>>>> expecting the network_error_code to contain proper integer values. >>>>>> >>>>>> 2010/8/4 Alexander Malysh<[email protected]>: >>>>>>> Hi Victor, >>>>>>> >>>>>>> seems you misunderstand SMPP spec. >>>>>>> >>>>>>> network_error_code is Octetstring with a size of 3. >>>>>>> The first Octet is network type and the rest is error code. >>>>>>> >>>>>>> So for you example (GSM and error code 0xff)m it would be: 3ff >>>>>>> >>>>>>> Thanks, >>>>>>> Alexander Malysh >>>>>>> >>>>>>> Am 02.08.2010 um 09:37 schrieb Victor Luchitz: >>>>>>> >>>>>>>> Hello. >>>>>>>> >>>>>>>> SMPP smsc handles the network_error_code TLV as 3-octets C-string, >>>>>>>> which seems to be in accordance with the spec, at least at the first >>>>>>>> glance. However, the spec also further refines this tag is a set of >>>>>>>> two independent integer values: single-octet network code and >>>>>>>> two-octets error code. >>>>>>>> For example, a value of 0x0300ff (in hex) is a perfectly valid value >>>>>>>> for this tag, representing an error with code 0xff in a GSM network. >>>>>>>> I'm not 100% sure bearerbox wouldn't choke on reading such a value >>>>>>>> (since the supposed string is prematurely terminated), but what I am >>>>>>>> sure is that one can't write a value such as 0x0300ff into this tag if >>>>>>>> it's represented as a C-string. So, to able to fully use this TLV in >>>>>>>> say, smppbox, this TLV has to be represented as a 3-octets integer >>>>>>>> value. That renders this tag unusable for the err: field in SMPP >>>>>>>> delivery receipts but it was never intended to be used as such despite >>>>>>>> bearing a similar name. >>>>>>>> >>>>>>>> So I'm attaching a patch that changes representation of the >>>>>>>> network_error_code TLV to a 3-octets integer and removes its usage for >>>>>>>> in handle_dlr. >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Victor Luchitz >>>>>>>> <network_error_code.patch> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Victor Luchitz >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Victor Luchitz >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Best regards, >>>> Victor Luchitz >>>> >>>> >>>> >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Victor Luchitz >> > > > -- Best regards, Victor Luchitz
