Re: Malformed addr for Incoming short code

Arne K. Haaje wrote:

> Did not this (no strict checking) use to be the default up until the 
> data_sm patch? A lot of administrators will get a real surprise when 
> they upgrade (like I did).

yep, indead. The problem is can we really consider this a "compatibility 
breaker" in that sense? Since it "implements" a feature of SMPP that at that 
time was not implemented, and hence allowed to pass "faulty" PDUs?

> Myself, I have a few small patches in Kannel and follow the development, 
> but I would guess most administrators do not. A lot of people are 
> probably running (very ?) old versions, "if it's not broken don't fix 
> it", and may get real surprised when things don't work as "they used to 
> do" ;)

yes, that's an issue.

> I can't answer the above question, but just suggest that it may be 
> acceptable to allow different strictness when Kannel is origination or 
> destination.
> 
> Now, I do have some suggestions on how one might better handle the new 
> situation with strict checking. When I upgraded my first connection we 
> noticed after a while we were not getting any messages from that 
> particular operator.
> 
> I probably should have seen this earlier, but I did not have any debug 
> logs on. When turning  this on I discovered that we got the "expected at 
> least 7 digits" message.

ok, there is no debug output, but there is error() output on these. So if you 
scan your logs, you should have noticed ;)

> However, nothing ended up in the access-log. Now, if you send an 
> outgoing message and it get's rejected you get (at least when using DLR) 
> a 16 NACK in the log. Why not use a line in the access-log when 
> *receiving* invalid messages as well?

a good suggeston IMO. Should be feasable, as long as the PDU syntax is ok, but 
semantics of the values break.

Can you have a patch submited on this as suggestion? ;)

> Now, there may be one even more serious issue. I believe the incoming 
> messages (that get the  "expected at least 7 digits") are not getting 
> rejected (NACK) to the sending SMSC. That means the SMSC will treat them 
> as delivered. Will not that get end-users to get billed on a MO-billed 
> shortnumber?

Have to agree with Alex here. Yes, we do NACK the messages, see 
gw/smsc/smsc_smpp.c:351 as example, where we assign reason = SMPP_ESME_RINVSRCADR.

Stipe

-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany

tolj.org system architecture      Kannel Software Foundation (KSF)
http://www.tolj.org/              http://www.kannel.org/

mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------