I am using mosquitto as MQTT broker. I am using Paho Java library to connect to the broker with auto-reconnect as true. Normally, it works fine. Connection drop rate is there but auto-reconnect takes care of it. But sometimes, it looks like paho library is not attempting to auto connect. I captured network traffic in Wireshark:
Turns out that there are TCP retransmissions happening. As you can see, its happening continuously, and paho client is not able to reconnect. I am running client as well as server on same laptop, so I don't understand why failure / retransmission is happening.
Have anyone faced similar problem before?
OS: Windows 10.
Mosquitto and client, both are local processes
Related
Thanks in advance for the help.
Issue:
Unable to receive snmp-traps on udp 162 port.
Scenario: Trying to put a nexus 5672 in OpenNMS for monitoring
Pre-Checks done:
I am able to snmpwalk the nexus 5k from my linux node on which
OpenNMS is installed.
I am even able to do snmpgets.
I see snmp traffic on udp 161 but they are primarily because of the snmp-get's that opennms is doing.
UNABLE TO SEE ANYTHING WHEN I DO A TCPDUMP ON 162 PORT :(
I have checked if any ACLs are set locally but they are not, iptables as a service is stopped.
I have verified that the snmp-configs are properly pushed.
Configs are pushed on the loop-back interface and there are not acl-groups on the nexus 5k either and there is not firewall between the nexus 5k and the OpenNMS Hosted Linux System
Please help, i do not know what i am missing.
Ok, first of all, there are two concepts with SNMP, the first one is polling for data to get data from sensors or discover elements from your device. The monitoring application sends requests to your Nexus device. This is what you do when you issue a snmpwalk or snmpget command. The Nexus device has an SNMP agent running which is listening on port 161/UDP.
The second one is, your Nexus device can send messages to your monitoring application. Your monitoring application with OpenNMS needs to have a listener running on port 162/UDP, called SNMP Traps or SNMP Informs.
So trying to debug the problem not getting SNMP Traps with snmpget or snmpwalk does not help in the first place. The communication is initialized by the Nexus device and OpenNMS is the listener for the traps.
I would try to debug the problem with the following steps:
Ensure OpenNMS has Trapd enabled and is listening on the right interfaces, e.g. with ss -lnpu sport = :162
Make sure you don't have a firewall on your OpenNMS server which blocks traffic to 162/UDP, e.g. iptables -L
Use tcpdump to see if the SNMP trap from your Nexus arrives on the OpenNMS server by looking at traffic with target port 162 with protocol UDP.
If you're SNMP trap is received from the OpenNMS server, you can then start looking in trapd.log of your OpenNMS server and verify if community settings for the IP is correct. OpenNMS will use the community which is configured for the senders IP address to process the trap
In hope this helps
This got resolved. Everything from the Linux end, and the OpenNMS SNMP end was good. However, the network device had SNMP configs wrongly pushed. I changed it to use the default VRF rather than the loopback address, and it started working.
localhost Tcp connections randomly disconnecting. Running tcp client/server apps with simple echoing the server sees the local client connection breaking but any client connection over the network stays up. All local host connections get severed. One can immediately reconnect with no problem. This happens randomly and relatively rarely but is still problematic in my environment. Has anyone observed this pattern?
Instead of "Localhost" use 127.0.0.1
Localhost is used in Linux. Windows works better with 127.0.0.1.
Beats me, Google for explanation or just use the knowledge.
I am having some trouble with my asterisk install hanging up calls.
Initially I was having no audio on my calls so I opened up the ports to my gsu gateway which is on a different network then my asterisk box. I opened up the port on the gsm gateway side with is behind not and that resolved the audio issues
Now the issue is that asterisk drops the calls. I have checked and the rtp packets stream is only sending packets and doesn't seem to be getting anything back.
The asterisk box is hosted on vultr with Ubuntu server.
Any idea on whats going on?
Hangup in 10-12 seconds after call started usually issued by incorrect nat settings. Asterisk can't send back response to softphone/hardphone and hangup line(it think no internet connection to device).
See http://www.voip-info.org/wiki/view/Asterisk+SIP+NAT+solutions
In your case it also can be firewall or bad virtualization setup.
I have a puzzle I am not able to figure out, I would appreciate any help.
I am connected to a remote desktop using windows default remote desktop utility (Windows 8 locally, Windows 7 remotely).
The remote desktop is not in the same sub-network as my own.
Connection is made through default port 3389. Using Wireshark locally I can confirm the TCP connection being established and the data flow.
Running Wireshark in the remote desktop, I don`t see any flow of data between the two computers.
If I send a ICMP ping from the remote desktop to my computer, it works well and I can see it in Wireshark both remotely as well as locally. But if I send the ICMP ping from my computer to the remote desktop, it fails. I see it leaving my computer through Wireshark, but it never reaches the remote desktop (I don`t see it in Wireshark).
I don't think it is a firewall issue (specially since it can't explain why Wireshark won`t capture the port 3389 RPC flow).
Does anyone have any idea of what might be going on?
I found the main issue.
In Wireshark, turns out it is possible to configure the capture interface with a filter.
To change it, go to: Capture->Interfaces
On the interface being used, stop capturing to enable the Options, there it is possible to configure a capture filter.
I have two applications that talk via TCP, both of which run on Windows XP machines. The client is a third-party application for which I have only the executable, no source. The IP address of the server it connects to is set in a text configuration file. The server is an application I am writing.
All netmasks are 255.255.255.0.
In all cases, the client runs on 192.168.142.202.
I am seeing a case where if I run my server on 192.168.142.207, everything works, but if I move my server over to another machine on the same subnet (192.168.142.105), everything does not work fine. Specifically, the connection does not seem to get properly established. I have looked at what's going on in Wireshark and would like to request assistance interpeting what I see.
On the server side, I see the 3-way handshake: SYN, SYN/ACK, ACK. I get no error codes on the return of accept(), and netstat shows the connection as established.
On the client side, the connection does not seem to be established properly. This causes the client to reconnect periodically, and it will also occasionally close all of the not-correctly-connected sockets that get created as a result. When I look at the client side in Wireshark, I most often see a SYN, SYN, SYN pattern, rather that the expected 3-way handshake. Occassionally, the 3-way handshake does appear, but even then, the client doesn't seem to be happy with the connection because it closes it.
I will note that there are actually two TCP connections between the client and server. The other connection (i.e. not the problematic connection I described above) works just fine. The problematic connection has listening port 5004; the good connection has listening port 1234.
I have placed both .txt and .pcap versions of the client and server Wireshark captures at this link: https://skydrive.live.com/redir.aspx?cid=c5beaf58ac752bb0&resid=C5BEAF58AC752BB0!105&parid=root
As far as the physical network setup goes, there is one switch in between the client and server in the case that works, and there are two switches in between the client and server in the case that doesn't work. All ping tests are successful. There are no wireless connections involved; everything is wired.
All firewalls are off.
Does anybody have any thoughts on either what the problem is or what further data I could gather to solve the problem?
Well, it appears this is not a network or network programming problem at all. I've figured out by trial and error that the third-party software that connects to me wants the machine it runs on to have a smaller IP address than the machine my software runs on. This seems completely arbitrary to me, but empirically, this very strongly appears to be the case. Arghhhh............
Thanks to any and all who may have spent time poring over the Wiresharks dumps I provided...