Re: Re: OTA Truncation?
The bookmark works because the message is smaller and doesn't need segmentation. I have never coded kannel but am willing to try to fix it. Can you spare a moment to tell me which source files/functions I should be concentrating on? From: Aarno Syvänen [EMAIL PROTECTED] Date: Mon 22/Jul/2002 05:10 GMT To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: OTA Truncation? Eric Carlson kirjoittaa perjantaina, 19. heinäkuuta 2002, kello 23:10:Perhaps you can correct the segmentation ? This should not be too much work, the code is already available, you must just call it. I hav this problem too.Anyone planning this fix? Is 1.2.1 rearing its head here ? This is quite bad bug; it is certainly reasonable to send bookmark with settings. I will do the bug correction, if anybody else does not (I certainly hope that somebody does), but not very soon. Aarno ___ Freeserve AnyTime, only £13.99 per month with one month's FREE trial! For more information visit http://www.freeserve.com/time/ or call free on 0800 970 8890
Re: Re: OTA Truncation?
Hmm...
Looks like in sms_at2.c there is a at2_pdu_encode(Msg *msg, unsigned
char *pdu, PrivAT2data *privdata) function with a very supicious
looking comment. I guess this is the right area(?) but what to do next
is beyond this newbie ;-) :
/*
* user data
* if the data is too long, it is cut
*/
if (msg-sms.coding == DC_8BIT || msg-sms.coding == DC_UCS2) {
pos += at2_encode8bituncompressed(msg-sms.msgdata, pdu[pos]);
} else {
int offset = 0;
if (octstr_len(msg-sms.udhdata)) { /* Have UDH */
int nbits = octstr_len(msg-sms.udhdata) * 8; /* Includes UDH
length byte */
offset = (((nbits / 7) + 1) * 7 - nbits) % 7; /* Fill bits */
}
pos += at2_encode7bituncompressed(msg-sms.msgdata, pdu[pos],
offset);
}
pdu[pos] = 0;
___
Freeserve AnyTime, only £13.99 per month with one month's FREE trial!
For more information visit http://www.freeserve.com/time/ or call free on 0800 970 8890
Re: OTA Truncation?
Is 1.2.1 rearing its head here ? This is quite bad bug; it is certainly reasonable to send bookmark with settings. I will do the bug correction, if anybody else does not (I certainly hope that somebody does), but not very soon. yep, go on Aarno, this should be definetly be fixed. We should shoot for 1.2.1 at end of week IMO. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: OTA Truncation?
Eric Carlson kirjoittaa perjantaina, 19. heinäkuuta 2002, kello 23:10:Perhaps you can correct the segmentation ? This should not be too much work, the code is already available, you must just call it. I hav this problem too.Anyone planning this fix? Is 1.2.1 rearing its head here ? This is quite bad bug; it is certainly reasonable to send bookmark with settings. I will do the bug correction, if anybody else does not (I certainly hope that somebody does), but not very soon. Aarno
OTA Truncation?
Hi - I posted a message here last week regarding bad OTA. I now have more info. Using the CVS from yesterday it looks like the PDU is getting truncated. Can anyone confirm this please or see what I'm doing wrong? Here is the XML I'm sending: ?xml version=1.0? !DOCTYPE CHARACTERISTIC-LIST SYSTEM file://gw/settings.dtd CHARACTERISTIC-LIST CHARACTERISTIC TYPE=ADDRESS PARM NAME=BEARER VALUE=GSM/CSD/ PARM NAME=PROXY VALUE=123.34.6.7/ PARM NAME=CSD_DIALSTRING VALUE=+45/ PARM NAME=PPP_AUTHTYPE VALUE=PAP/ /CHARACTERISTIC CHARACTERISTIC TYPE=URL VALUE= http://wap.dk / CHARACTERISTIC TYPE=NAME PARM NAME=NAME VALUE=ABC/ /CHARACTERISTIC CHARACTERISTIC TYPE=BOOKMARK PARM NAME=NAME VALUE=Wap/ PARM NAME=URL VALUE= http://wap.dk / /CHARACTERISTIC /CHARACTERISTIC-LIST Here is the bearerbox log (which looks ok): 2002-07-18 14:48:29 [3] INFO: smsbox: Got HTTP request /cgi-bin/sendota from 127.0.0.1 2002-07-18 14:48:29 [3] INFO: sendsms used by foo 2002-07-18 14:48:29 [3] DEBUG: OTA service with XML document 2002-07-18 14:48:29 [3] DEBUG: Octet string at 0x100cea98: 2002-07-18 14:48:29 [3] DEBUG: len: 158 2002-07-18 14:48:29 [3] DEBUG: size: 159 2002-07-18 14:48:29 [3] DEBUG: immutable: 0 2002-07-18 14:48:29 [3] DEBUG: data: 01 06 2c 1f 2a 61 70 70 ..,.*app 2002-07-18 14:48:29 [3] DEBUG: data: 6c 69 63 61 74 69 6f 6e lication 2002-07-18 14:48:29 [3] DEBUG: data: 2f 78 2d 77 61 70 2d 70 /x-wap-p 2002-07-18 14:48:29 [3] DEBUG: data: 72 6f 76 2e 62 72 6f 77 rov.brow 2002-07-18 14:48:29 [3] DEBUG: data: 73 65 72 2d 73 65 74 74 ser-sett 2002-07-18 14:48:29 [3] DEBUG: data: 69 6e 67 73 00 81 ea 01 ings 2002-07-18 14:48:29 [3] DEBUG: data: 01 6a 00 45 c6 06 01 87 .j.E 2002-07-18 14:48:29 [3] DEBUG: data: 12 45 01 87 13 11 03 31 .E.1 2002-07-18 14:48:29 [3] DEBUG: data: 32 33 2e 33 34 2e 36 2e 23.34.6. 2002-07-18 14:48:29 [3] DEBUG: data: 37 00 01 87 21 11 03 2b 7...!..+ 2002-07-18 14:48:29 [3] DEBUG: data: 34 35 00 01 87 22 70 01 45...p. 2002-07-18 14:48:29 [3] DEBUG: data: 01 86 07 11 03 20 68 74 . ht 2002-07-18 14:48:29 [3] DEBUG: data: 74 70 3a 2f 2f 77 61 70 tp://wap 2002-07-18 14:48:29 [3] DEBUG: data: 2e 64 6b 20 00 01 c6 08 .dk 2002-07-18 14:48:29 [3] DEBUG: data: 01 87 15 11 03 41 42 43 .ABC 2002-07-18 14:48:29 [3] DEBUG: data: 00 01 01 c6 7f 01 87 15 2002-07-18 14:48:29 [3] DEBUG: data: 11 03 57 61 70 00 01 87 ..Wap... 2002-07-18 14:48:29 [3] DEBUG: data: 17 11 03 20 68 74 74 70 ... http 2002-07-18 14:48:29 [3] DEBUG: data: 3a 2f 2f 77 61 70 2e 64 ://wap.d 2002-07-18 14:48:29 [3] DEBUG: data: 6b 20 00 01 01 01 k 2002-07-18 14:48:29 [3] DEBUG: Octet string dump ends. 2002-07-18 14:48:29 [3] INFO: /cgi-bin/sendota: XML request for target +44777xx x 2002-07-18 14:48:29 [3] DEBUG: Octet string at 0x100cea98: 2002-07-18 14:48:29 [3] DEBUG: len: 158 2002-07-18 14:48:29 [3] DEBUG: size: 159 2002-07-18 14:48:29 [3] DEBUG: immutable: 0 2002-07-18 14:48:29 [3] DEBUG: data: 01 06 2c 1f 2a 61 70 70 ..,.*app 2002-07-18 14:48:29 [3] DEBUG: data: 6c 69 63 61 74 69 6f 6e lication 2002-07-18 14:48:29 [3] DEBUG: data: 2f 78 2d 77 61 70 2d 70 /x-wap-p 2002-07-18 14:48:29 [3] DEBUG: data: 72 6f 76 2e 62 72 6f 77 rov.brow 2002-07-18 14:48:29 [3] DEBUG: data: 73 65 72 2d 73 65 74 74 ser-sett 2002-07-18 14:48:29 [3] DEBUG: data: 69 6e 67 73 00 81 ea 01 ings 2002-07-18 14:48:29 [3] DEBUG: data: 01 6a 00 45 c6 06 01 87 .j.E 2002-07-18 14:48:29 [3] DEBUG: data: 12 45 01 87 13 11 03 31 .E.1 2002-07-18 14:48:29 [3] DEBUG: data: 32 33 2e 33 34 2e 36 2e 23.34.6. 2002-07-18 14:48:29 [3] DEBUG: data: 37 00 01 87 21 11 03 2b 7...!..+ 2002-07-18 14:48:29 [3] DEBUG: data: 34 35 00 01 87 22 70 01 45...p. 2002-07-18 14:48:29 [3] DEBUG: data: 01 86 07 11 03 20 68 74 . ht 2002-07-18 14:48:29 [3] DEBUG: data: 74 70 3a 2f 2f 77 61 70 tp://wap 2002-07-18 14:48:29 [3] DEBUG: data: 2e 64 6b 20 00 01 c6 08 .dk 2002-07-18 14:48:29 [3] DEBUG: data: 01 87 15 11 03 41 42 43 .ABC 2002-07-18 14:48:29 [3] DEBUG: data: 00 01 01 c6 7f 01 87 15 2002-07-18 14:48:29 [3] DEBUG: data: 11 03 57 61 70 00 01 87 ..Wap... 2002-07-18 14:48:29 [3] DEBUG: data: 17 11 03 20 68 74 74 70 ... http 2002-07-18 14:48:29 [3] DEBUG: data: 3a 2f 2f 77 61 70 2e 64 ://wap.d 2002-07-18 14:48:29 [3] DEBUG: data: 6b 20 00 01 01 01 k 2002-07-18 14:48:29 [3] DEBUG: Octet string dump ends. 2002-07-18 14:48:29 [3] INFO: /cgi-bin/sendota default +447779xx 2002-07-18 14:48:29 [3] DEBUG: message length 158, sending 1 messages 2002-07-18 14:48:29 [3] DEBUG: Status: 202 Answer: Sent. Here is the smsbox log: 2002-07-18 14:48:29 [7] DEBUG: boxc_receiver: sms received 2002-07-18 14:48:30 [5] DEBUG: AT2[COM4]: international starting with + (+447779 x) 2002-07-18 14:48:30 [5] DEBUG: AT2[COM4]:
Re: OTA Truncation?
Aarno Syvänen kirjoittaa perjantaina, 19. heinäkuuta 2002, kello 08:06:[EMAIL PROTECTED] kirjoittaa torstaina, 18. heinäkuuta 2002, kello 17:20:Hi - I posted a message here last week regarding bad OTA. I now have more info. Using the CVS from yesterday it looks like the PDU is getting truncated. Can anyone confirm this please or see what I'm doing wrong? 2002-07-18 14:48:29 [3] DEBUG: message length 158, sending 1 messages 2002-07-18 14:48:29 [3] DEBUG: Status: 202 Answer: Sent. Sending 158 binary octets in one message is certainly wrong, the message should be segmented. This looks to me like the message is just cut off after the Wap string!!! If all octets does not fit in one message, and there are no segmentation, leftover octets are cut. System is Cygwin, sending with Ericsson R320 as SMSC using AT2, reciever is T68i. Anyone please!!! (I'm quite new to this so please don't assume I can see the obvious ;-)) Perhaps you can correct the segmentation ? This should not be too much work, the code is already available, you must just call it. A
