Am 19.02.19 17:46, schrieb Stuart Kendrick:
I’m seeing a lot of this in my logs:
2019-02-18T19:28:26.526495-08:00 vishnu smsbox[21580]: 2019-02-18
19:28:26 [21580] [5] INFO: Starting to service
<#001#006'application/vnd.wap.mms-message> from <1111301000> to <1234>
2019-02-18T19:28:44.167763-08:00 vishnu smsbox[21580]: 2019-02-18
19:28:44 [21580] [5] INFO: Starting to service <11111301000 Error
Invalid Number. Please re-send using a valid 10 digit mobile number or
valid short code. No service specified> from <+1121611611> to <1234>
[…]
2019-02-19T08:38:24.918834-08:00 vishnu smsbox[21580]: 2019-02-19
08:38:24 [21580] [5] INFO: Starting to service <11121611611 Error
Invalid Number. Please re-send using a valid 10 digit mobile number or
valid short code. No service specified> from <+1121611611> to <1234>
2019-02-19T08:38:37.474384-08:00 vishnu smsbox[21580]: 2019-02-19
08:38:37 [21580] [5] INFO: Starting to service <11121611611 Error
Invalid Number. Please re-send using a valid 10 digit mobile number or
valid short code. No service specified> from <+1121611611> to <1234>
I speculate: someone has found my cellular modem number and is sending
me spam.
For this application, I transmit SMS over the cellular modem; I don’t
want to receive anything.
* My carrier (AT&T) tells me that they cannot block in-bound SMS –
they can enable bi-directional SMS or disable it: all or nothing.
* I disabled auto-answer on the modem … but this setting appears to
govern POTS, not SMS
* Is there a Kannel way (bearerbox or smsbox) to disable incoming
reception of SMS?
* Alternatively, is there a way to instruct Kannel to send requests
for Invalid Numbers (e.g. ‘1234’) to /dev/null?
* Other ideas for dumping these messages? I’m mostly annoyed by the
repetitive logging
At the moment, I have a cronjob job which stops bearerox & smsbox,
sleeps for several minutes (not clear to me why this is necessary), and
then restarts them. This of course creates a dead zone, in terms of
service, which is suboptimal.
Hi Stuart,
what you can do is to ensure that the "visible" impact is minimal. The
SMSC AT module has no way to "refuse" MOs directly. It will send any MO
to your connected smsbox instance.
If you have no application driven MOs that you want to receive, then you
can drop the MOs to nirvana and ensure that there is no response bounced
back to the originator, i.e. via config context
group = sms-service
keyword = default
text = "No action specified"
max-messages = 0
You WILL still see the MOs in the bearerbox access-log and the smsbox
access-log though.
It MAY BE an option to think about a config directive for the SMSC AT
module to "turn off" MO interpretation and simply drop anything we get
on the modem.
@devel: Anyone from the SMSC AT developer folks that wants to pick this up?
--
Best Regards,
Stipe Tolj
-------------------------------------------------------------------
Düsseldorf, NRW, Germany
Kannel Foundation tolj.org system architecture
http://www.kannel.org/ http://www.tolj.org/
st...@kannel.org s...@tolj.org
-------------------------------------------------------------------
