Closed jancss closed 7 years ago
Hi, what release version ? and can you provide tcp capture of smpp traffic ?
Hi, this is Jasmin 0.9.b9.
The only smpp traffic to that specific connector is related to keeping the connection alive. Seems logical since the submitsmpdu gets rejected.
.....;...M....E. .^."@.?.......S. ea.....$?....j.. ..z@.......1.... .....*.......... ..[user].[password] C7..4..None.
This is the incoming request made from my phone.
...M.......;..E. .../@.+.V....... ..|y.y.y.=.".... ...:......./.z.1 ..GET./send?user name=foo&passwo rd=bar&content= testing&to=[mynumber] .HTTP/1.1. .Host:.[myip ]:1401..Conne ction:.keep-aliv e..Upgrade-Insec ure-Requests:.1. .Accept:.text/ht ml,application/x html+xml,applica tion/xml;q=0.9, /;q=0.8..User-A gent:.Mozilla/5. 0.(iPhone;.CPU.i Phone.OS.10_0_1. like.Mac.OS.X).A ppleWebKit/602.1 .50.(KHTML,.like .Gecko).Version/ 10.0.Mobile/14A4 03.Safari/602.1. .Accept-Language :.en-us..Cache-C ontrol:.max-age= 0..Accept-Encodi ng:.gzip,.deflat
Seems weird issue, are you sending really to _[mynumber]_ or you're just censozing your number ? if the latter then is your number a normal msisdn ? can you send a part of it or just change one or 2 chars in it and share it ?
Sure, its my real number, Im just censoring it. As I said, through a different smpp connector everything works fine.
My number looks like this: 5698422222 (56 country code for Chile, then the rest, last 5 digits changed)
And the http API validates input, since putting down a string instead of a number would yield a 400 error. My input gets 200 and the following in the http-api.log:
2016-10-06 13:07:49 INFO 1 SMS-MT [uid:test_user] [cid:connector1] [msgid:a2109ace-303b-4309-b365-f38681b997cb] [prio:0] [dlr:No] [from:None] [to:5698422222] [content:testing]
ok, ca you take a tcp capture using tcpdump ? i need to see what's happening on the wire between jasmin and your provider.
Nothing specific happens when I try to send the message...as far as I can tell its just keeping the connection alive.
tcpdump -vvv -nn -XX dst 83.149.101.97
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 17:38:28.016153 IP (tos 0x0, ttl 63, id 58504, offset 0, flags [DF], proto TCP (6), length 60) 172.31.20.218.46090 > 83.149.101.97.2780: Flags [S], cksum 0x7a1e (incorrect -> 0x1ca8), seq 2018463893, win 29200, options [mss 1460,sackOK,TS val 57652253 ecr 0,nop,wscale 7], length 0 0x0000: 02e5 aa18 0d3b 02db 974d a70b 0800 4500 .....;...M....E. 0x0010: 003c e488 4000 3f06 dd43 ac1f 14da 5395 .<..@.?..C....S. 0x0020: 6561 b40a 0adc 784f 5095 0000 0000 a002 ea....xOP....... 0x0030: 7210 7a1e 0000 0204 05b4 0402 080a 036f r.z............o 0x0040: b41d 0000 0000 0103 0307 .......... 17:38:28.194029 IP (tos 0x0, ttl 63, id 58505, offset 0, flags [DF], proto TCP (6), length 52) 172.31.20.218.46090 > 83.149.101.97.2780: Flags [.], cksum 0x7a16 (incorrect -> 0x125b), seq 2018463894, ack 145242925, win 229, options [nop,nop,TS val 57652298 ecr 3371081027], length 0 0x0000: 02e5 aa18 0d3b 02db 974d a70b 0800 4500 .....;...M....E. 0x0010: 0034 e489 4000 3f06 dd4a ac1f 14da 5395 .4..@.?..J....S. 0x0020: 6561 b40a 0adc 784f 5096 08a8 3b2d 8010 ea....xOP...;-.. 0x0030: 00e5 7a16 0000 0101 080a 036f b44a c8ee ..z........o.J.. 0x0040: 9d43 .C 17:38:28.195156 IP (tos 0x0, ttl 63, id 58506, offset 0, flags [DF], proto TCP (6), length 94) 172.31.20.218.46090 > 83.149.101.97.2780: Flags [P.], cksum 0x7a40 (incorrect -> 0xaafa), seq 0:42, ack 1, win 229, options [nop,nop,TS val 57652298 ecr 3371081027], length 42 0x0000: 02e5 aa18 0d3b 02db 974d a70b 0800 4500 .....;...M....E. 0x0010: 005e e48a 4000 3f06 dd1f ac1f 14da 5395 .^..@.?.......S. 0x0020: 6561 b40a 0adc 784f 5096 08a8 3b2d 8018 ea....xOP...;-.. 0x0030: 00e5 7a40 0000 0101 080a 036f b44a c8ee ..z@.......o.J.. 0x0040: 9d43 0000 002a 0000 0009 0000 0000 0000 .C...*.......... 0x0050: 0001 636f 6e6e 6563 3100 4546 3746 3638 ..[user].[password] 0x0060: 4337 0000 3400 004e 6f6e 6500 C7..4..None.
Btw, this is the connector configuration:
smppccm -s connector1 ripf 0 con_fail_delay 10 dlr_expiry 86400 coding 0 logrotate midnight submit_throughput 1 elink_interval 150 bind_to 30 port 2780 con_fail_retry yes password [password] src_addr None bind_npi 0 addr_range None dst_ton 1 res_to 120 def_msg_id 0 priority 0 con_loss_retry yes username [user] dst_npi 1 validity None requeue_delay 120 host 83.149.101.97 src_npi 1 trx_to 300 logfile //var/log/jasmin/default-connector1.log systype ssl no cid connector1 loglevel 20 bind transceiver proto_id None dlr_msgid 0 con_loss_delay 10 bind_ton 0 pdu_red_to 10 src_ton 0
please give me the file from this command:
tcpdump -s0 -w dump.pcap dst 83.149.101.97
There you go.
I can only see bind and unbinds ... Can you provide access to your system ? share to support@jasminsms.com
mailed you! thanks!
Hello! Any possible progress on this or way I could help? Thanks!
Hi, have the same problem, @jancss did you solve this ? @farirat ?
Sadly I've found no solution to this. Had to change my provider.
For what its worth, it has now started happening on a fresh install with a smpp client that previously worked (same config as before).
I'm experiencing this error also, on 0.9b15, here is a stacktrace I've collected so far:
[Failure instance: Traceback: <type 'exceptions.TypeError'>: %d format: a number is required, not str
/data/jasmin/lib/python2.7/site-packages/jasmin/managers/listeners.py:233:submit_sm_callback
/data/jasmin/lib/python2.7/site-packages/jasmin/protocols/smpp/protocol.py:345:sendDataRequest
/data/jasmin/lib/python2.7/site-packages/jasmin/vendor/smpp/twisted/protocol.py:588:sendDataRequest
/data/jasmin/lib/python2.7/site-packages/jasmin/vendor/smpp/twisted/protocol.py:368:sendRequest
--- <exception caught here> ---
/data/jasmin/lib/python2.7/site-packages/twisted/internet/defer.py:150:maybeDeferred
/data/jasmin/lib/python2.7/site-packages/jasmin/protocols/smpp/protocol.py:332:doSendRequest
/data/jasmin/lib/python2.7/site-packages/jasmin/vendor/smpp/twisted/protocol.py:377:doSendRequest
/data/jasmin/lib/python2.7/site-packages/jasmin/protocols/smpp/protocol.py:90:sendPDU
/data/jasmin/lib/python2.7/site-packages/jasmin/vendor/smpp/twisted/protocol.py:356:sendPDU
/data/jasmin/lib/python2.7/site-packages/jasmin/vendor/smpp/pdu/pdu_encoding.py:959:encode
/data/jasmin/lib/python2.7/site-packages/jasmin/vendor/smpp/pdu/pdu_encoding.py:1025:encodeBody
/data/jasmin/lib/python2.7/site-packages/jasmin/vendor/smpp/pdu/pdu_encoding.py:1067:encodeRequiredParams
/data/jasmin/lib/python2.7/site-packages/jasmin/vendor/smpp/pdu/pdu_encoding.py:85:encode
/data/jasmin/lib/python2.7/site-packages/jasmin/vendor/smpp/pdu/pdu_encoding.py:148:_encode
]
It ends up in jasmin/vendor/smpp/pdu/pdu_encoding.py:148:_encode
where it says raise ValueError("Value %d exceeds max %d" % (value, self.max))
I'm still investigating, I'm not sure where self.max
comes from, probably a setting on smppc.
I've isolated the problem as the _encode is indirectly called via PDUEncode.encodeBody()
:
body += self.encodeRequiredParams(pdu.mandatoryParams, self.getRequiredParamEncoders(pdu), pdu.params)
With me it dies on _encode(value)
with value = None, when I check the pdu.params, the only value being 'None' is 'address_range':
PDU [command: bind_transceiver, sequence_number: 1, command_status: ESME_ROK
system_id: '<hidden>'
password: '<hidden>'
system_type: ''
interface_version: 52
addr_ton: 'ABBREVIATED'
addr_npi: 'PRIVATE'
address_range: 'None'
]
So it looks like the 'address_range' is a problem here... I'm looking further which setting is responsible for this.
Awesome job! Would love to know more.
It went a bit further and I found the malicious parameter, it looks like it is parameter_id
.
{'priority_flag': EnumValue(<jasmin.vendor.enum.Enum object at 0x3d33550>, 0, 'LEVEL_0'), 'source_addr': '1111', 'protocol_id': 'None', 'registered_delivery': RegisteredDelivery[receipt: NO_SMSC_DELIVERY_RECEIPT_REQUESTED, smeOriginatedAcks: set([]), intermediateNotification: False], 'replace_if_present_flag': 'DO_NOT_REPLACE', 'dest_addr_ton': 'INTERNATIONAL', 'source_addr_npi': 'ISDN', 'schedule_delivery_time': None, 'dest_addr_npi': 'ISDN', 'esm_class': EsmClass[mode: STORE_AND_FORWARD, type: DEFAULT, gsmFeatures: set([])], 'data_coding': DataCoding[scheme: DEFAULT,schemeData: SMSC_DEFAULT_ALPHABET], 'service_type': None, 'source_addr_ton': 'UNKNOWN', 'sm_default_msg_id': 0, 'validity_period': None, 'destination_addr': '+123456789', 'short_message': 'fajlf'}
service_type
source_addr_ton
0
source_addr_npi
1
source_addr
dest_addr_ton
1
dest_addr_npi
1
destination_addr
esm_class
3
protocol_id
None
[Failure instance: Traceback: <type 'exceptions.TypeError'>: %d format: a number is required, not str
...
The pdu_encodings.py is not written for readability which made it hard to crack the code. Let me see if I can set the protocol_id somewhere.
Setting proto_id
on the smppc to 1 made it work again.
I think it became 'None' or '0' because I ran smppccm -s NAME
, copy paste the config and later used it as an input for smppccm -a NAME
.
Maybe Jasmin can fix the output of smppccm -s
to show the values that can be used as input again? addr_range
, validity
and proto_id
had 'None' or '0' as default value in my config, a quick look in some of the spec's makes it look like it should be '1'.
@Duologic :+1: Yep I reckon copying a config from a slightly older version of jasmin to a newer one is what caused this for me as now I've set proto_id its all good.
Ok guys, this time i've catched the issue and reproduced it, it's still running on 0.9rc22.
Please follow #578 as i'll update on that stream, closing this one as "duplicate to #578"
Hi guys, just getting into Jasmin, seems great so far...
While trying to send a message through the http api:
http://[my_ip]:1401/send?username=foo&password=bar&to=[my_number]&content=testing
I get this in the messages.log:
2016-10-04 20:05:52 CRITICAL 1 Rejecting SubmitSmPDU[93edd324-bce3-42d0-8c52-bce2443f99c9] through [cid:connector1] for an unknown error (<type 'exceptions.TypeError'>): %d format: a number is required, not str
Any ideas or maybe way to get the full traceback? (I'm running Jasmin on Docker, Ubuntu 16.04) It all works perfectly when sending through a different connector.
Thanks!