Develop/fix small fragment of Go/Golang code - SMPP 3.4 protocol connector
$30-250 USD
クローズ
投稿日: 6年近く前
$30-250 USD
完了時にお支払い
Hi
I need some help with fixing golang code responsible for generating SMPP (Short Message Peer To Peer) v 3.4 protocol message
I use following library: [login to view URL]
My app need to accept submit_sm messages, reply them with submit_sm_resp, try to deliver using external http provider, send delivery_sm report back to sender
I have all that almost working, but my code is generating malformed/invalid deliver_sm messages.
So your only task is to fix this code or suggest changes, so it will produce valid deliver_sm PDU (validated by Wireshark and accepted by remote SMSC). Nothing more, just that one thing.
Code responsible for generating deliver_sm is as follows:
// based on example from: [login to view URL]
func MyHandler(cli Conn, m [login to view URL]) {
[login to view URL]("smppserver: echo PDU from %s: %#v", [login to view URL](), m)
switch [login to view URL]().ID {
case [login to view URL]:
[login to view URL]("That was SubmitSM")
resp := [login to view URL]()
[login to view URL]().Seq = [login to view URL]().Seq
[login to view URL]().Set([login to view URL], "12345678901234567890")
[login to view URL](resp)
p := [login to view URL]()
[login to view URL]().Status = 0
[login to view URL]().Seq = [login to view URL]().Seq + 1 // m is original message, [login to view URL] type
f := [login to view URL]()
// @note swap source/dest from original message
[login to view URL]([login to view URL], [login to view URL]()[[login to view URL]])
[login to view URL]([login to view URL], [login to view URL]()[[login to view URL]])
[login to view URL]([login to view URL], [login to view URL]()[[login to view URL]])
[login to view URL]([login to view URL], [login to view URL]()[[login to view URL]])
[login to view URL]([login to view URL], [login to view URL]()[[login to view URL]])
[login to view URL]([login to view URL], [login to view URL]()[[login to view URL]])
[login to view URL]([login to view URL], []byte{0x04})
[login to view URL]([login to view URL], []byte{0x00})
[login to view URL]([login to view URL], []byte{0x00})
[login to view URL]([login to view URL], []byte{0x00})
[login to view URL]([login to view URL], []byte{0x00})
[login to view URL]([login to view URL], []byte{0x00})
[login to view URL]([login to view URL], []byte{0x00})
[login to view URL]([login to view URL], [login to view URL]()[[login to view URL]])
[login to view URL]([login to view URL], []byte{0x00})
[login to view URL]([login to view URL], [login to view URL]()[[login to view URL]])
// message id's static for a test purpose
[login to view URL]([login to view URL], [login to view URL]("id:12345678901234567890 submit date:201806251516 done date:201806251517 stat:DELIVRD err:002"))
[login to view URL]().Set([login to view URL], []byte{2})
[login to view URL]().Set([login to view URL], [login to view URL]("12345678901234567890"))
}
You can check generated message as seen by Wireshark (in the attachment).
I'm not a good binary protocol hacker, but for my eye there is one unnecessary zero byte (0x00) just before "ShortMessage" field with text "id:12345678901234567890 submit date:201806251516 done date:201806251517 stat:DELIVRD err:002"
One byte before message body is holding message length, and it's correct. Wireshark tries to decode, you see message body highlighted blue, because of zero byte at the beggining, final "2" char is treated as next field and generates error. I think, that removing this single zero byte will fix that, but I have no idea how to do this
Please take a look at [login to view URL] and try solve this problem
It's also possible that's other error that I don't see. Maybe related to encoding TLVFields witch I don't fully understand
I can provide full code of my app (that's only app skeleton) and access to working SMPP v3.4 server or you can use our own.
I use Diafaan SMS for that purpose, its free up to 30 days