I have two different systems running restcomm smsc gw. I'm trying to configure one as a server side and other as client side. Logs for both PC are given below:
SERVER ERROR
10:40:32,975 INFO [SmppServerConnector] (SmppManagement) New channel from [172.31.130.126:33712]
10:40:33,020 INFO [UnboundSmppSession] (SmppManagement.UnboundSession.172.31.130.126:33712) received PDU: (bind_transceiver: 0x0000002F 0x00000009 0x00000000 0x00000001) (body: systemId [jazz] password [jazz123] systemType [] interfaceVersion [0x34] addressRange (0x00 0x00 [^[0-9a-zA-Z]*])) (opts: )
10:40:33,022 ERROR [DefaultSmppServerHandler] (SmppManagement.UnboundSession.172.31.130.126:33712) Received BIND request but no ESME configured for SystemId=jazz Host=172.31.130.126 Port=33712 SmppBindType=TRANSCEIVER
10:40:33,022 WARN [UnboundSmppSession] (SmppManagement.UnboundSession.172.31.130.126:33712) Bind request rejected or failed for connection [172.31.130.126:33712] with error [SMPP processing error [0x0000000F]]
10:40:33,029 INFO [UnboundSmppSession] (SmppManagement.UnboundSession.172.31.130.126:33712) send PDU: (bind_transceiver_resp: 0x00000022 0x80000009 0x0000000F 0x00000001 result: "System ID invalid") (body: systemId [RestCommSMSC]) (opts: (sc_interface_version: 0x0210 0x0001 [34]))
10:40:33,034 INFO [UnboundSmppSession] (SmppManagement.UnboundSession.172.31.130.126:33712) Connection closed with [172.31.130.126:33712]
CLIENT ERROR
10:40:33,012 INFO [DefaultSmppSession] (Thread-45) sync send PDU: (bind_transceiver: 0x0000002F 0x00000009 0x00000000 0x00000001) (body: systemId [jazz] password [jazz123] systemType [] interfaceVersion [0x34] addressRange (0x00 0x00 [^[0-9a-zA-Z]*])) (opts: )
10:40:33,015 INFO [DefaultSmppSession] (Thread-45) write bytes: [0000002f0000000900000000000000016a617a7a006a617a7a31323300003400005e5b302d39612d7a412d5a5d2a00]
10:40:33,063 INFO [DefaultSmppSession] (jazz) read bytes: [00000022800000090000000f0000000152657374436f6d6d534d5343000210000134]
10:40:33,070 INFO [DefaultSmppSession] (jazz) received PDU: (bind_transceiver_resp: 0x00000022 0x80000009 0x0000000F 0x00000001 result: "System ID invalid") (body: systemId [RestCommSMSC]) (opts: (sc_interface_version: 0x0210 0x0001 [34]))
10:40:33,071 ERROR [SmppSessionHandlerInterfaceImpl] (jazz) Rx : fireChannelUnexpectedlyClosed for SmppSessionImpl=client Default handling is to discard an unexpected channel closed
10:40:33,072 ERROR [SmppClientOpsThread] (Thread-45) Exception when trying to bind client SMPP connection for ESME systemId=jazz
com.cloudhopper.smpp.type.SmppBindException: Unable to bind [error: 0x0000000F "System ID invalid"]
at com.cloudhopper.smpp.impl.DefaultSmppSession.bind(DefaultSmppSession.java:341)
at com.cloudhopper.smpp.impl.DefaultSmppClient.doBind(DefaultSmppClient.java:215)
at com.cloudhopper.smpp.impl.DefaultSmppClient.bind(DefaultSmppClient.java:196)
at org.restcomm.smpp.SmppClientOpsThread.initiateConnection(SmppClientOpsThread.java:292)
at org.restcomm.smpp.SmppClientOpsThread.run(SmppClientOpsThread.java:129)
at java.lang.Thread.run(Thread.java:745)
Server Bind
ESME name=server systemId=jazz state=CLOSED password=jazz123 host=127.0.0.1 port=-1 networkId=21 chargingEnabled=false bindType=TRANSCEIVER systemType=
Client Bind
ESME name=client systemId=jazz state=CLOSED password=jazz123 host=172.31.130.101 port=2776 networkId=21 chargingEnabled=false bindType=TRANSCEIVER systemType=
As you can see SystemID is same on both side but still im getting this error. Any help will be appreciated.
Related
Below is the connection parameters in the python program to connect to ActiveMQ
broker_url = config_params.items('BROKERS')
conn = stomp.Connection12(broker_url,
reconnect_sleep_initial=20.0,
reconnect_sleep_increase=2.0,
reconnect_attempts_max=10,
heartbeats=(60000,60000)
)
So the ReadCheckInterval and WriteCheckInterval are set to 1 minute for the connection. It looks like the heartbeats are being missed. I am just trying to figure out if the heart beats are missing from the client or the ActiveMQ server end. Can someone help me?
Below are the logs from the Python program:
2020-02-25 12:27:16,141 - INFO - Attempting connection to host
2020-02-25 12:27:16,142 - INFO - Established connection to host
2020-02-25 12:27:16,142 - INFO - Starting receiver loop
2020-02-25 12:27:16,143 - DEBUG - Sending frame: ['STOMP', '\n', 'accept-version:1.2\n', 'client-id, 'heart-beat:60000,60000\n',]
2020-02-25 12:27:16,143 - DEBUG - Received frame: 'CONNECTED', headers={'server': 'ActiveMQ/5.15.2', 'heart-beat': '60000,60000']body=''
2020-02-25 12:27:16,143 - DEBUG - Sending frame: ['SUBSCRIBE', '\n', 'ack:auto\n', 'activemq.subscriptionName:subscriber\n']
2020-02-25 12:30:16,144 - DEBUG - Received frame: 'heartbeat', headers={}, body=None
2020-02-25 12:30:16,145 - ERROR - disconnected from broker, will attempt to reconnect...
2020-02-25 12:30:16,145 - INFO - Receiver loop ended
2020-02-25 12:30:16,320 - INFO - Attempting connection to host
2020-02-25 12:30:16,321 - INFO - Established connection to host
2020-02-25 12:30:16,321 - INFO - Starting receiver loop
2020-02-25 12:30:16,321 - DEBUG - Sending frame: ['STOMP', '\n', 'accept-version:1.2\n', 'client-id:\n', 'heart-beat:60000,60000\n']
2020-02-25 12:30:16,322 - DEBUG - Received frame: 'CONNECTED', headers={'server': 'ActiveMQ/5.15.2', 'heart-beat': '60000,60000']body=''
2020-02-25 12:30:16,322 - DEBUG - Sending frame: ['SUBSCRIBE', '\n', 'ack:auto\n', 'activemq.subscriptionName:subscriber]
I see client and the server both missing sending heart beats to each other. Below is a log where the client has missed sending the heartbeat. The connection gets established at 12:03:32. The client sends the first heart beat at 12:03:32 and then subscribes to the ActiveMQ destination. It keeps getting messages, so there is activity, until 12:12:08. Then a period of inactivity until 12:13:32 (>60 seconds) and the connection gets terminated. Is this a problem of the ActiveMQ server being too less tolerant to missed heart beats from the client. Would increasing the heartbeat interval from the client to 120 seconds help in this case?
2020-02-26 12:03:32,498 - INFO - Established connection to host, port 61613
2020-02-26 12:03:32,499 - INFO - Sending frame: 'STOMP', headers={'heart-beat': '60000,60000'}
2020-02-26 12:03:32,512 - INFO - Received frame: 'CONNECTED', headers={'heart-beat': '60000,60000'}
2020-02-26 12:03:32,513 - INFO - Sending frame: 'SUBSCRIBE'
2020-02-26 12:04:27,924 - INFO - Received frame: 'MESSAGE'
.
.
2020-02-26 12:12:08,475 - INFO - Received frame: 'MESSAGE'
2020-02-26 12:13:32,519 - INFO - Received frame: 'heartbeat'
2020-02-26 12:13:32,548 - ERROR - disconnected from broker
I also see problems os the server missing to send the heartbeat and the client getting a heartbeat timeout error. I am thinking of disabling heartbeats from the server by setting the heartbeat configuration to (120000,0). Any suggestions?
After some testing it turned out that even a few milliseconds delay in the client heartbeat was causing the connection to be closed by the broker.
For the same reason, from ActiveMQ server version 5.9.0,
transport.hbGracePeriodMultiplier (default=1) was added. This would increase the heartbeat timeout by a factor of the set value. Below is the JIRA link which was used to implement this feature.
https://issues.apache.org/jira/browse/AMQ-4674
I've also removed the broker heartbeat, by setting the heartbeat as (60000,0) as it was redundant.
The first value in the Connect hear-beat header is the 'will send' value for client heart beats to the broker. The client should be attempting to maintain a consistent heart beat at the level indicated which is defined as
smallest number of milliseconds between heart-beats that it can
guarantee
The broker will allow for some grace period based on that value after which if the client has not sent a heart beat or any other frame the connection will be closed. From the trace given the client is not sending any heart beats or other wire level activity so the broker is dropping the connection.
Everything was working fine for us from last 8 months and suddenly we started getting this error.
We configured SMPP driver properties in Oracle EM console and sending SMS using UMS integrated with Oracle SOA server.
Found a link related to this error but it doesn't help:
https://support.nowsms.com/discus/messages/485/1176.html
[2017-10-17T10:33:16.806+05:30] [WLS_SOA] [ERROR] [SDP-25700]
[oracle.sdp.messaging.driver.smpp] [tid: Workmanager: , Version: 0,
Scheduled=false, Started=false, Wait time: 0 ms\n] [userId:
OracleSystemUser] [ecid:
49d20b62a8084325:-5336381e:15f247fea2f:-8000-000000000001c322,0] [APP:
usermessagingdriver-smpp] An unexpected exception was caught.[[
oracle.sdp.messaging.driver.DriverException: Invalid Source Address[a]
at
oracle.sdpinternal.messaging.driver.smpp.SMPPDriver.send(SMPPDriver.java:1073)
at
oracle.sdpinternal.messaging.driver.smpp.SMPPDriver.send(SMPPDriver.java:3268)
at
oracle.sdpinternal.messaging.driver.smpp.SMPPDriver.send(SMPPDriver.java:2849)
at
oracle.sdpinternal.messaging.driver.smpp.SMPPDriver.send(SMPPDriver.java:2724)
at
oracle.sdpinternal.messaging.driver.smpp.SMPPManagedConnection.send(SMPPManagedConnection.java:95)
at
oracle.sdpinternal.messaging.driver.DriverConnectionImpl.send(DriverConnectionImpl.java:41)
at
oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean.onMessage(DriverDispatcherBean.java:296)
at sun.reflect.GeneratedMethodAccessor1629.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606) at
com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at
com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at
com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at
com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at
com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at
com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at
com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy532.onMessage(Unknown Source) at
oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean_xfokw2_MDOImpl.__WL_invoke(Unknown
Source) at
weblogic.ejb.container.internal.MDOMethodInvoker.invoke(MDOMethodInvoker.java:35)
at
oracle.sdpinternal.messaging.dispatcher.DriverDispatcherBean_xfokw2_MDOImpl.onMessage(Unknown
Source) at
oracle.sdpinternal.messaging.jmsmessagereceiver.ResourceAdapterImpl$RaMessageListener.onMessage(ResourceAdapterImpl.java:167)
at
oracle.sdpinternal.messaging.jms.QueueWorker.run(QueueWorker.java:73)
at
weblogic.work.j2ee.J2EEWorkManager$WorkWithListener.run(J2EEWorkManager.java:184)
at weblogic.work.DaemonWorkThread.run(DaemonWorkThread.java:30)
]] [2017-10-17T10:33:16.807+05:30] [WLS_SOA] [NOTIFICATION]
[SDP-26003] [oracle.sdp.messaging.driver.dispatcher] [tid:
Workmanager: , Version: 0, Scheduled=false, Started=false, Wait time:
0 ms\n] [userId: OracleSystemUser] [ecid:
49d20b62a8084325:-5336381e:15f247fea2f:-8000-000000000001c322,0] [APP:
usermessagingdriver-smpp] Dispatcher sent message with id:
eb50c4cdc0a800ab12d5fbbdbbbbd46a.
Network Logs (Using Wireshark):
We figured out and resolved this issue. Posting its resolution here. May be it can help someone other and save their precious time.
SMPP driver configured in Oracle EM console has a bug due to which Source address and Default source address are always null even if you pass it from driver configurations.
It was due to multiple Source Address at SMSC and our system was passing null
value in Source Address field. Due to this SMSC was not able
to recognize correct source address and throw "Invalid Source
Address" exception.
If single/static source address is configured at SMSC then you can
pass null values and SMSC will automatically recognize source address.
I am testing my rabbitmq 3 nodes cluster these days,
I use the java tool to test,
[root#server-42 bin ]$ ./runjava com.rabbitmq.perf.PerfTest -x1 -y1 -e testex -Hmqp://username:password#123.123.123.2/test' -t topic -k sample.info -s 1500 -i 20
id: test-154506-639, starting consumer #0
id: test-154506-639, starting consumer #0, channel #0
id: test-154506-639, starting producer #0
id: test-154506-639, starting producer #0, channel #0
id: test-154506-639, time: 20.000s, sent: 8913 msg/s, received: 8804 msg/s, min/avg/max latency: 6317/251907/727492 microseconds
id: test-154506-639, time: 40.004s, sent: 8993 msg/s, received: 8991 msg/s, min/avg/max latency: 157294/256691/387926 microseconds
id: test-154506-639, time: 60.011s, sent: 9029 msg/s, received: 9019 msg/s, min/avg/max latency: 146744/255631/384696 microseconds
id: test-154506-639, time: 80.017s, sent: 8946 msg/s, received: 8972 msg/s, min/avg/max latency: 164969/259147/723908 microseconds
id: test-154506-639, time: 100.019s, sent: 8971 msg/s, received: 8949 msg/s, min/avg/max latency: 164012/258115/353767 microseconds
I find my rabbitmq connection and channel status keeps at flow status.
however why is it ? is there any way to increase the performance?
I thought the flow status to keep the publisher to send messages to quick, in case that server can not queue the messages.
but the sending rate I used to test seems not high at all, why they are still in flow status?
anyone can help? thanks in advance.
Flow Control:
RabbitMQ will reduce the speed of connections which are publishing too quickly for queues to keep up.
If you want to learn more about the credit flow you can read this doc, in particular:
To see how credit_flow and its settings affect publishing, let’s see how internal messages flow in RabbitMQ. Keep in mind that RabbitMQ is implemented in Erlang, where processes communicate by sending messages to each other.
you can try to increase credit_flow parameter
in my case, I was getting this due to Lack of memory (Too many unacked messages causes memory to be full which makes the connection in flow state)
I send PowerOn CCID command on card insertion to receive ATR. But instead I always get this error:
PC_to_RDR_IccPowerOn (00h Automatic):
bStatus: 0x0
bError: 0x80
Error 80h according to CCID spec "Reserved for future use".
But same code working correctly with other CCID device I have and this device works with other apps. So how I can find what I'm doing wrong?
I have tried different voltages 3v,5v, 1.8v, but for all of them I get exactly same error.
Even when this happens I get correct ATR. So then I'm trying to send APDU (select non existing file to warm up connection) and then I get:
Slot Status: 40h "An ICC is present and inactive (not activated or
shut down by hardware error)"
So what does it mean "inactive" What I should do?
CCID device descriptor:
CCID Device Descriptor:
bcdCCID: 0110
5V Support true
3V Support true
1.8V Support true
dwDefaultClock: 3.75 MHz
dwMaximumClock: 7.5 MHz
dwDataRate: 10080 bps
dwMaxDataRate: 10080 bps
T0 Support true
T1 Support true
dwFeatures * 0x4c4b400
* Automatic IFSD exchange as first exchange
* Short and Extended APDU exchange level support
dwMaxCCIDMessageLength 271 bytes
wLcdLayout 0000
bMaxCCIDBusySlots 01
I am developing a simple ejabberd client in C using libstrophe. It connects and begins to handle messages as it's supposed to do.
However, after a while (following two or three pings from the ejabberd server), my connection closes and the status is set to DISCONNECTED. Below is the tail of the debug lines:
xmpp DEBUG Unrecoverable TLS error, 5.
xmpp DEBUG Closing socket.
DEBUG: disconnected event DEBUG Stopping event loop.
event DEBUG Event
oop completed.
I initialize and connect as below.
xmpp_initialize();
/* read connection params */
if( set_xmpp_conn_params( &conn_params ) < 0 ) {
fprintf(stderr, "Could not retrieve connection params from %s\n",
SERVER_CONF_FILE);
return -1;
}
/* initialize the XMPP logger */
xmpp_log = xmpp_get_default_logger(XMPP_LOG_LEVEL);
xmpp_ctx = xmpp_ctx_new(NULL, xmpp_log);
/* create a connection */
xmpp_conn = xmpp_conn_new(xmpp_ctx);
/* login */
xmpp_conn_set_jid(xmpp_conn, conn_params.jid);
xmpp_conn_set_pass(xmpp_conn, conn_params.password);
/* create a client */
xmpp_connect_client( xmpp_conn, conn_params.host, 0,
agent_conn_handler, xmpp_ctx );
/* enter the event loop */
xmpp_run( xmpp_ctx );
/* the code below is executed
whenever connection handler #agent_conn_handler exits */
/* release the connection and context */
xmpp_conn_release(xmpp_conn);
xmpp_ctx_free(xmpp_ctx);
Why am I getting that TLS error message?
Thanks.
Error 5 is SSL_ERROR_SYSCALL. The OpenSSL docs say:
Some I/O error occurred. The OpenSSL error queue may contain more
information on the error. If the error queue is empty (i.e.
ERR_get_error() returns 0), ret can be used to find out more about the
error: If ret == 0, an EOF was observed that violates the protocol. If
ret == -1, the underlying BIO reported an I/O error (for socket I/O on
Unix systems, consult errno for details).
In practice, this may mean the server dropped your connection for some reason. I'd suggest doing a packet trace with WireShark to get more info. For example, we have seen this happen with servers that use the RSA libraries for TLS, when the client offers TLS version 1.1.