I might apply the patch, but I've checked and rechecked the code,
and I don't really see where could be the bug. There's no "39" anywhere,
'0' is 30, not 39, if somewhere the pid is not initialized, this patch won't
solve anything.
I'm still waiting for the UCP dump of the SENDING message, not the
AT PDU he receives... I want to see the 39 going out in UCP......
----- Original Message -----
From: "Steve Rapaport" <[EMAIL PROTECTED]>
To: "gatewayZgalore" <[EMAIL PROTECTED]>
Cc: "Francesco Emmi" <[EMAIL PROTECTED]>
Sent: Tuesday, March 26, 2002 11:17 AM
Subject: Bug in smsc_emi2.c?
>
> This diff is suggested by Francesco, it makes
> sense to me. Could someone please respond and
> say if we're crazy or it should be included?
>
> smsc_emi2.c::
> 373c371
> < if(msg->sms.pid != 0) {
> ---
> > if((msg->sms.pid >=0) && (msg->sms.pid < 256) ) {
>
> Thanks, all. See below for the use case that fails without this diff.
> ____________________________________________
> Steve Rapaport
> CTO, A-Tono
> Via Amedei, 15 - Milano 20123
> Cel.: +39 348 6431573
> Fax : +1 617 687 0415
>
>
>
> -----Original Message-----
> From: francesco emmi [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 25, 2002 12:09 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Explaining PDU trouble
>
>
> Dear Mr. Rodrigues,
>
> As I wrote in the past, we have tried to send 8-bit SMS with EMI2 without
> success. We set PID to 0 and UDH to F5. Although we didn't
> receive the SMS correctly, we could analize the PDU received by mobile:
>
>
> 07919333852802004414D0E5F61CFD6E975DEE321D39F5203012911504408C1180
>
0A06F4343DEC9E0102062A0003050D012E5345512115030000001C0000001C000000841E0081
> 01FF
>
9E0101080300FFFF3B0003BE230E247C439E447C047C162A429AF7051603429EF7051603226A
> F70B
>
42A2F74D16062278F70B16062282F70B16062282F717160C2278F70B1606226A3714160342A2
> F702
> 960142A4F702960142A2F7029601429EF702.
>
>
> As you can see, for some reason unknown, PID was changed to 39.
> We thought the problem was in the kannel code. Look at smsc_emi2.c
> (in the CVS version) line 373:
>
> if(msg->sms.pid != 0) {
> emimsg->fields[E50_RPID] = octstr_format("%04d", msg->sms.pid);
>
>
> As we want to set PID to 0, no octet is created in our PDU.
> Changing the code in a way such this:
>
> if((msg->sms.pid >= 0) && (msg->sms.pid<256)) {
> emimsg->fields[E50_RPID] = octstr_format("%04d", msg->sms.pid);
>
> finally we could receive the 8-bit SMS corectly whose PDU was:
>
> 07919333852802004414D0E5F61CFD6E975DEE321D00F5203012911504408C1180
>
0A06F4343DEC9E0102062A0003050D012E5345512115030000001C0000001C000000841E0081
> 01FF
>
9E0101080300FFFF3B0003BE230E247C439E447C047C162A429AF7051603429EF7051603226A
> F70B
>
42A2F74D16062278F70B16062282F70B16062282F717160C2278F70B1606226A3714160342A2
> F702
> 960142A4F702960142A2F7029601429EF702
>
> As you can see, PID now is 0.
>
> So, do you think the piece of code I underlined, is a bug?
>
> I'll include a diff file for smsc.emi2.c
>
> Thank in advance
>
> Francesco Emmi
>
>
>
