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
-------------------------------------------------------------------
