Hi Victor, you are welcome :)
Thanks, Alexander Malysh Am 04.08.2010 um 23:30 schrieb Victor Luchitz: > 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 >
