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
