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.
Related
Requesting the local machine fails right away:
telnet localhost 65535
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
while it runs forever when requesting google or any other remote machine:
telnet www.google.com 65535
Trying 2a00:1450:4007:812::2004...
I suppose non standard ports should be closed on web servers. If yes, telnet should end up with a "Connection refused" right away as well. right?
Actually, this can be caused by multiple sources. A not so known, but common one:
There are some firewalls allowing you to delay requests to specific ports.
Think about this: Scanning one IP address for all ports only takes a few seconds.
If you delay the response (in case the port is not opended for instance) it will take a potential attacker much longer to scan all ports.
You could argue that the attacker could count anything taking let´s say 5 seconds or longer as timeout, but, there are applications, SMTP servers for instance, that often actually respond only after 20 seconds or so because of this.
May protocols are trying to be attacked and if you generally define that your mailserver will only respond after 20 seconds, that does not really matter to mails in most cases, most attacks will already count this as timeout and won´t even notice that a mailserver is running there whereas the clients get configured for timeouts of 30 seconds or so and they can connect.
Another common thing is that the windows telnet client won´t really post the output until you press any key.
Can software respond to a Wake-on-Lan packet, or does it get filtered out by the NIC and/or OS?
My PC receives a Wake-on-Lan packet when one of my devices can't connect to the service it's expecting. If the PC is off, the packet will cause the machine to boot up, as expected. Unfortunately, it's possible (and common) for a PC user to quit the service manually. This leaves the system in a bad state where the machine is on but the service isn't running.
This particular service (Steam Big Picture Mode) doesn't have a 'run as service' option, and doesn't provide any other hooks to start it remotely. I'd like to write some bootstrap code that listens for the WoL packet and launches the service.
I want to honor the user's request to close the service on the host, up until the point that the WoL request is received. Thus, I'd prefer not to write a process that just monitors the service health and re-starts it when it's closed.
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 a simple client application which sends udp datagram to the server with known ip address and port and waits for respond. Client can be started on any computer or mobile device and it can be located behind several routers and firewalls... Server application listens certain port for client's datagram and replies to the client's endpoint with an answer. Server application works on windows computer with properly configured firewall, etc. So, as I understand, this simple scheme should work regardless to client's location and his firewall settings. But it looks like it doesn't work in about 75% of configurations. Server receives request from the client in 100% of cases, but in 75% of cases client can't receive response from the server, i.e. it looks like it's always blocked by something (server attempts 10 times to send an answer to the client, but without luck, i.e. client doesn't receive anything). I tried many different configurations of client computers to figure out the reasons of these issues and what I've found:
In some cases simple windows firewall can block respond packets (But how it could be possible? As I understand, all respond packets must be forwarded back to the client regardless to firewall settings.)
Some Hardware firewalls or NATs also can block respond UDP packets. And again, I can't understand why it could be possible?
The question is - is there any reliable method to deliver an answer to client? As I know, many programs, such as Skype works fine with UDP even with all these network "obstacles".
Thank you!
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...