I have configured a v3 SNMP trap and I have confirmed a trap is being received but the following error is appearing:
"RFC3414 §3.2.7.a Not in time window; engineID='', engineBoots=19, engineTime=60374
"
From various articles I can see it is due to the engineBoots and engineTime not being in sync between the sender and receiver of the trap.
Can someone recommend what is the best way to sync the sender and receiver of the trap?
Related
We have built a fix client. The fix client can receive incoming messages but cannot send outgoing heartbeat message or reply the TestRequest message after the last heartbeat was sent, something is triggered to stop sending heartbeat anymore from client side.
fix version: fix5.0
The same incident happened before, we have tcpdump for one session in that time
we deploy every fix session to separated k8s pods.
We doubted it's CPU resource issue because the load average is high around the issue time, but it's not solved after we add more cpu cores. we think the load average is high because of fix reconnection.
We doubted it's IO issue because we use AWS efs which shared by 3 sessions for logging and message store. but it's still not solved after we use pod affinity to assign 3 sessions to different nodes.
It's not a network issue either, since we can receive fix messages, other sessions worked well at that time. We have disabled SNAT in k8s cluster too.
We are using quickfixj 2.2.0 to create a fix client, we have 3 sessions, which are deployed to k8s pods in separated nodes.
rate session to get fx price from server
order session to get transaction(execution report) messages from server, we only send logon/heartbeat/logout messages to server.
backoffice session to get marketstatus
We use apache camel quickfixj component to make our programming easy. It works well in most time, but it keeps happening to reconnect to fix servers in 3 sessions, the frequency is like once a month, mostly only 2 sessions have issues.
heartbeatInt = 30s
The fix event messages at client side
20201004-21:10:53.203 Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not valid for message (MsgType=1)
20201004-21:10:53.271 MINA session created: local=/172.28.65.164:44974, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/10.60.45.132:11050
20201004-21:10:53.537 Initiated logon request
20201004-21:10:53.643 Setting DefaultApplVerID (1137=9) from Logon
20201004-21:10:53.643 Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1
20201004-21:10:53.643 Received logon
The fix incoming messages at client side
8=FIXT.1.1☺9=65☺35=0☺34=2513☺49=Quote1☺52=20201004-21:09:02.887☺56=TA_Quote1☺10=186☺
8=FIXT.1.1☺9=65☺35=0☺34=2514☺49=Quote1☺52=20201004-21:09:33.089☺56=TA_Quote1☺10=185☺
8=FIXT.1.1☺9=74☺35=1☺34=2515☺49=Quote1☺52=20201004-21:09:48.090☺56=TA_Quote1☺112=TEST☺10=203☺
----- 21:10:53.203 Already disconnected ----
8=FIXT.1.1☺9=87☺35=A☺34=1☺49=Quote1☺52=20201004-21:10:53.639☺56=TA_Quote1☺98=0☺108=30☺141=Y☺1137=9☺10=183☺
8=FIXT.1.1☺9=62☺35=0☺34=2☺49=Quote1☺52=20201004-21:11:23.887☺56=TA_Quote1☺10=026☺
The fix outgoing messages at client side
8=FIXT.1.1☺9=65☺35=0☺34=2513☺49=TA_Quote1☺52=20201004-21:09:02.884☺56=Quote1☺10=183☺
---- no heartbeat message around 21:09:32 ----
---- 21:10:53.203 Already disconnected ---
8=FIXT.1.1☺9=134☺35=A☺34=1☺49=TA_Quote1☺52=20201004-21:10:53.433☺56=Quote1☺98=0☺108=30☺141=Y☺553=xxxx☺554=xxxxx☺1137=9☺10=098☺
8=FIXT.1.1☺9=62☺35=0☺34=2☺49=TA_Quote1☺52=20201004-21:11:23.884☺56=Quote1☺10=023☺
8=FIXT.1.1☺9=62☺35=0☺34=3☺49=TA_Quote1☺52=20201004-21:11:53.884☺56=Quote1☺10=027☺
Thread dump when TEST message from server was received.BTW, The gist is from our development environment which has the same deployment.
https://gist.github.com/hitxiang/345c8f699b4ad1271749e00b7517bef6
We had enabled the debug log at quickfixj, but not much information, only logs for messages receieved.
The sequence in time serial
20201101-23:56:02.742 Outgoing heartbeat should be sent at this time, Looks like it's sending, but hung at io writing - in Running state
20201101-23:56:18.651 test message from server side to trigger thread dump
20201101-22:57:45.654 server side began to close the connection
20201101-22:57:46.727 thread dump - right
20201101-23:57:48.363 logon message
20201101-22:58:56.515 thread dump - left
The right(2020-11-01T22:57:46.727Z): when it hangs, The left(2020-11-01T22:58:56.515Z): after reconnection
It looks like that the storage - aws efs we are using made the issue happen.
But the feedback from aws support is that nothing is wrong at aws efs side.
Maybe it's the network issue between k8s ec2 instance and aws efs.
First, we make the logging async at all session, make the disconnection happen less.
Second, for market session, we write the sequence files to local disk, the disconnection had gone at market session.
Third, at last we replaced the aws efs with aws ebs(persist volume in k8s) for all sessions. It works great now.
BTW, aws ebs is not high availability across zone, but it's better than fix disconnection.
Is there any SNMP manager or trap manger with buzzer notifications on PC normal speaker? With alarms that can be defined to activate this buzzer upon specific traps.
You can use NetDecision TrapVision for that. It comes with built-in trap handler that supports audible alarms.
I am new to SNMP and to Kapacitor-InfluxDB. I have InfluxDB and Kapacitor installed on a server. Kapacitor is generating alarms using data pushed into InfluxDB. I was wondering if it is possible to consider the server on which Kapacitor and InfluxDB are installed an SNMP agent and use the alarms that Kapacitor generates as traps to be sent to an SNMP manager installed on a separate machine?
Please let me know if my question is not clear.
You could implement it as an Output Node in Kapacitor: https://docs.influxdata.com/kapacitor/v0.13/about_the_project/custom_output/
Kapacitor can not natively send SNMP traps out of the box (yet). That functionality will likely require adding an SNMP trap event handler to the alert node.
Kapacitor's alert node exec event handler can be set to trigger a SNMP trap via snmptrap or another SNMP command line agent.
Working on USB Modem, Used RAS interface for dial/hangup.
For connection used RASDial() and for disconnection used RASHangUp() API's.
After successful connection waiting for the disconnect event using function RasConnectionNotification(rasHandle, event, RASCN_Disconnection), event notifies successfully when disconnect happens.
I need to find out the reason of disconnection, if it disconnect due to lost network signal then put my application on auto reconnect.
Is there any method or API which provides the reason for disconnection like LINK_FAILED, USER_SWITCH, USER_LOGOFF ... etc.
RasGetConnectStatus API can give you the reason in RASCONNSTATUS.dwError field.
I can finally make a phone call, receive, and answer it. But if I try to send an SMS I receive CMS ERROR: 500. The GSM modem I am using is Telit GL865-Quad module. Since the Call function is working, what's preventing the SMS to work? please enlightenment me. The Sim Card works fine on my phone to rule out some of the problems. I am using a hyperterminal to type the commands at 19200 speed. This is the user guide with commands for your own convenience.
To send an SMS:
AT+CMGF=1 // Select Text Mode
OK
AT+CMGW=”+xxxxxxxxxxxx” // my number
> Hi
>
+CMGW: 8
OK
AT+CMSS=8
Error: +CMS ERROR: 500
Any ideas to what the error means, since its unknown error? What are some commands to type out to pinpoint the problem?
I would appreciate your help, thanks!
+CMS ERROR: 500 is unfortunately a very generic error message.
I have a few suspicions which may solve your problem:
1) Timing problem
Writing an SMS to the SIM card will take a "significant" amount of time. Between writing the SMS to SIM and sending the SMS wait a couple of seconds.
2) Check that the SMS really did get written to SIM
Using the CMGR command you can verify if the SMS is written to SIM and it's current status.
For example:
AT+CMGR=8
Alternatives:
You can always send an SMS directly without storing on the SIM. This is generally a more favored approach for multiple reasons including SMS sending is quicker and SIM lifetime is extended due to reduced read/writes.
This can be achieved by using:
AT+CMGS=<destination address>
>Hi
You can additionally use the CNMI command to prevent incoming messages being stored on the SIM and being output directly to the console/telnet connection.
Replying on a 7 year old thread - sorry.
Make sure you terminate your message "Hello" with ASCII SUB (0x1A)