[BUG] SMPP trunk

OpenSIPS version you are running

opensips -V
version: opensips 3.0.0 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
main.c compiled on 13:21:56 May 29 2019 with gcc 8

Describe the bug

SMPP trunk setup with VoIP provider .
SMPP trunk initialized, but then get disconnected and opensips produce error in log

Jun 10 04:35:39 smsc /usr/sbin/opensips[29432]: ERROR:proto_smpp:smpp_send_msg: cannot fetch connection for SMS_C (0)
Jun 10 04:35:44 smsc /usr/sbin/opensips[29434]: ERROR:proto_smpp:smpp_send_msg: cannot fetch connection for SMS_C (0)

Based on information from provider opensips send incorrect information.

2019-06-07 14:30:53.959 [22670] [21] ERROR: SMPP: PDU length was too small (-797211610, minimum is 16). 
2019-06-07 14:30:53.959 [22670] [21] ERROR: ESME[username] Client sent garbage, closing connection from IP `207.35.127.183:49169'. 
2019-06-07 14:38:47.377 [23345] [25] ERROR: SMPP: PDU length was too large (1229866575, maximum is 7424). 
2019-06-07 14:38:47.377 [23345] [25] ERROR: ESME[username] Client sent garbage, closing connection from IP `207.35.127.183:53645'.

SMPP Trunk Flow

Opensips log says about unsupported format

Jun  7 10:02:34 smsc /usr/sbin/opensips[10821]: WARNING:proto_smpp:handle_smpp_msg: Unknown or unsupported command received 00000006
Jun  7 10:02:38 smsc /usr/sbin/opensips[10827]: ERROR:proto_smpp:smpp_send_msg: cannot fetch connection for SMS_C (0)
Jun  7 10:02:43 smsc /usr/sbin/opensips[10823]: ERROR:proto_smpp:smpp_send_msg: cannot fetch connection for SMS_C (0)
Jun  7 10:02:48 smsc /usr/sbin/opensips[10829]: ERROR:proto_smpp:smpp_send_msg: cannot fetch connection for SMS_C (0)
Jun  7 10:02:53 smsc /usr/sbin/opensips[10829]: ERROR:proto_smpp:smpp_send_msg: cannot fetch connection for SMS_C (0)

To Reproduce

Steps to reproduce the behavior:
Example:

1. Install Opensips SMPP module
2. Provision Database smpp table with provider information
3. Start opensips
4. Watch opensips log produce errors.

Expected behavior

Expect stable state for SMPP trunk where messages can flow without interruption bidirectional.

Relevant System Logs

OS/environment information

 cat /etc/redhat-release 
Fedora release 29 (Twenty Nine)
[root@smsc ~]# rpm -qa | grep opensips
opensips-proto_smpp-3.0.0-1.fc29.x86_64
opensips-proto_smpp-debuginfo-3.0.0-1.fc29.x86_64
opensips-debuginfo-3.0.0-1.fc29.x86_64
opensips-3.0.0-1.fc29.x86_64
opensips-httpd-3.0.0-1.fc29.x86_64
opensips-debugsource-3.0.0-1.fc29.x86_64
opensips-db_mysql-3.0.0-1.fc29.x86_64
python-opensips-cli-1.0.0.f1717ac-4.fc29.x86_64

Additional context

Also I provided pcap with time frame from opensips start.

Here some additional information from provider.

All we can tell you is, after we send deliver_sm, you should not
        send the generic_nack. But deliver_sm_resp.

Hello Everyone,
Is possible get update on this issue, tomorrow is 15 days ???

[razvancrainea]

I am sorry, I did receive your PCAPs, but I simply couldn't find the time to check them out. As soon as I do, I will get back to you.

Thank you for reply.

Opensips don't have debug for smpp I couldn't find what was event ID 6, so I tried debug with freeswitch and get the following information regard ID 6

2019-06-30 07:05:48.471881 [INFO] mod_smpp_utils.c:41 PDU 
command_length                [00000010] - [16]
command_id                    [00000006] - [UNBIND]
command_status                [00000000] - [ESME_ROK]
sequence_number               [5CFAB1E3] - [1559933411]

2019-06-30 07:05:48.471881 [ERR] mod_smpp_gateway.c:297 Unrecognized Command ID: 6
2019-06-30 07:05:48.471881 [ERR] mod_smpp_gateway.c:359 Unknown command_id[6]
2019-06-30 07:05:50.471884 [ERR] mod_smpp_gateway.c:224 Failed to recv on the socket

Here are list of events for smpp.

exports.command_ids = {                              // Use command_ids to look up by ID
    0x80000000: 'generic_nack',
    0x00000001: 'bind_receiver',
    0x80000001: 'bind_receiver_resp',
    0x00000002: 'bind_transmitter',
    0x80000002: 'bind_transmitter_resp',
    0x00000003: 'query_sm',
    0x80000003: 'query_sm_resp',
    0x00000004: 'submit_sm',
    0x80000004: 'submit_sm_resp',
    0x00000005: 'deliver_sm',
    0x80000005: 'deliver_sm_resp',
    0x00000006: 'unbind',
    0x80000006: 'unbind_resp',
    0x00000007: 'replace_sm',
    0x80000007: 'replace_sm_resp',
    0x00000008: 'cancel_sm',
    0x80000008: 'cancel_sm_resp',
    0x00000009: 'bind_transceiver',
    0x80000009: 'bind_transceiver_resp',
    0x0000000B: 'outbind',
    0x00000015: 'enquire_link',
    0x80000015: 'enquire_link_resp',
    0x00000021: 'submit_multi',
    0x80000021: 'submit_multi_resp',
    0x00000102: 'alert_notification',
    0x00000103: 'data_sm',
    0x80000103: 'data_sm_resp'
};

Razvan,
Can you please let me know when you can take a look on issue. It start affecting production deployment timelines. Thank you.

[razvancrainea]

I've just pushed a fix for this - could you please take the latest sources and test again?

Hello Razvan,
Thank you, going test right now.