is it possible to figure out, or be notified if a peer to whom you are connected is using TCP keepalives?
Furthermore to be notified when a keepalive is sent?
Without resorting to packet-level filtering in a kernel driver?
We have a plug proxy, and a customer wishes client keepalives to be forwarded to the server. At the moment our best option I think is just to allow setting keepalives on the server-side connection, but I wanted to check if anyone knew a way to detect what the client behaviour was so that relaying of keepalives could be more closely approximated.
Thanks.
it possible to figure out, or be notified if a peer to whom you are connected is using TCP keepalives?
No. TCP keepalive doesn't use a protocol extension. It just uses the existing protocol in a specific way so as to provoke a response.
Furthermore to be notified when a keepalive is sent?
No. A TCP keepalive segment cannot be identified as such.
Without resorting to packet-level filtering in a kernel driver?
Not even if you do.
We have a plug proxy, and a customer wishes client keepalives to be forwarded to the server.
Your customer is misinformed.
At the moment our best option I think is just to allow setting keepalives on the server-side connection
Correct.
but I wanted to check if anyone knew a way to detect what the client behaviour was so that relaying of keepalives could be more closely approximated.
Not possible.
Related
As my knowledge, in normal behavior, client will make random port to connect the SNMP service port, now the client use SNMP trap port (162) to communicate with server.
My questions:
As the client setting, I do not have configure any SNMP setting for the client, why WireShark able to capture SNMP traffic came from the client?
Why the client use SNMP trap port (162) to communicate with server, rather than using random port?
SNMP is usually transmitted over UDP, so there is actually no "connection", and speaking technically the source port doesn't matter. You can just send out datagrams (e.g. traps) without binding to a port.
However, even when run over UDP, SNMP does involve some two-way communication. If you are expecting a response (which a client does if it's sending an SNMP Get or Set request), the only place the other end knows to send it is back where the request came from, i.e. the original IP/port combination. There's no information in a SNMP packet that provides any alternative "return address" information.
So, in order to get a response on a predictable port, you'll send the request datagram from a bound socket. Typically the client will run its own listening "server" on port 162, send requests from there, and then it can receive responses there too. Otherwise you wouldn't see the responses. This also allows us to set up simple firewall rules (though you can often get away without firewall rules for the return path, due to hole punching*).
This is also true for the server, which emits traps and informs on a known, standard, predictable port not only so that you can configure your trap receiver and firewalls in a reliable way, but so that inform responses can be sent back to a known, standard, predictable port that you're listening on.
tl;dr: You can send your requests from an arbitrary port if you like, but it's not very useful.
* My SNMP implementation seemed buggy when the client/receiver only saw traps emitted during the ~15 minutes after it had last poked out some kind of request packet. Subsequent traps seemed to be completely missing. After much debugging on the server end, it turned out that we'd forgotten to open the correct port on the inbound firewall for the client, and were accidentally relying on hole punching, which has a time limit. :D
As for why Wireshark is seeing traffic from an unconfigured SNMP client, well, either your SNMP client actually is configured to send requests, or you're misinterpreting the results. Wireshark doesn't invent traffic. Without a more complete picture of your network setup, software setup, and those packets you're seeing, we could only speculate as to the exact cause of your confusion.
I have a freeswitch based PBX that has been working fine. I was using Skype connect as a SIP provider and I have had no difficulty making and receiving calls using this. Also, no difficulty with internal local-local calls.
I have just changed my sip trunk provider to voip-unlimited (based in the UK) and updated my sip profile accordingly. I can receive calls fine with the new provider, but when I make a call, the other party can hear me, but I cannot hear them. I do not get a ringing tone when I dial out (the remote party's phone rings, he answers the call, he hears me, but I cannot hear him).
I have ports 5060 and 5080 open to both UDP and TCP traffic and the router also supports PnP. I am uncertain if it is a firewall issue but certainly no problems were experienced with Skype connect previously.
the best thing would be to run a packet sniffer (tcpdump or wireshark) and see what's going on when the call is set up.
It might be:
codec negotiation problem
firewall settings problem
NAT traversal problem
Ok, got it sorted.
I set the PBX back to using Skype Connect. I ran wireshark and could see the connection getting established over TCP and the RTP packets flowing to and from the PBX using UDP.
I then switched over to the new SIP trunk provider. I again ran wireshark, could see the connection getting established over TCP, but this time incoming RTP packets were not present.
I checked the router's firewall and all seemed fine. Nothing in the log files etc. I still suspected the router however. Upon googling for my router model (a Netgear WNR2200) I came across a setting to disable the SIP ALG (Application Level Gateway). I did this (disabled) it and problem solved. By the looks of things, the SIP ALG feature of the router was interfering with and breaking SIP. It is supposed to solve some NAT problems, but in this case its use was undesirable.
I am using SharpPCap to filter packets. Does anyone know how to detect if a packet is for a secured http connection?
You would have to sniff the traffic from the start of the TCP session to observe the SSL handshake go back and forth. Once the encrypted session is set up, any individual packet is going to be indistinguishable from random noise.
To discover otherwise is to find a major flaw in the symmetric cipher. (Yes, the encryption really is that good.)
Of course, having a destination of port 443 is a hint that you are looking at an https connection... But that is just a convention.
In a recent series of question I have asked alot about UDP, boost::asio and c++ in general.
My latest question, which doesn't seem to have an answer here at Stackoverflow, is this:
In a client/server application, it is quite okay to require that the server open a port in any firewall, so that messages are allowed in. However, doing the same for clients is definately not a great user experience.
TCP-connections typically achieve this due to the fact that most routers support stateful packet inspection, allowing response packets through if the original request originated from the local host.
It is not quite clear to me how this would work with UDP, since UDP is stateless, and there is no such thing as "response packets" (to my knowledge). How should I account for this in my client application?
Thanks for any answers!
UDP itself is stateless, but the firewall typically is not. The convention on UDP is that if a request goes out from client:port_A to server:port_B, then the response will come back from server:port_B to client:port_A.
The firewall can take advantage of this. If it sees a UDP request go out from the client, it adds an entry to its state table that lets it recognise the response(s), to allow them in. Because UDP is stateless and has no indication of connection termination, the firewall will typically implement a timeout - if no traffic occurs between that UDP address pair for a certain amount of time, the association in the firewall's state table is removed.
So - to take advantage of this in your client application, simply ensure that your server sends responses back from the same port that it uses to receive the requests.
Does windows closes idle sockets? I mean if I'm a client connecting to a service on Windows server, is it possible that Windows server closes the connection after certain idle-time?
If yes, how to change this behaviour, or at least change the idle-time value?
Thanks in advance.
The behavior depends on the SO_KEEPALIVE socket option. Here's the MSDN page about it. After some further digging you can adjust the KEEPALIVE semantics with a WSAIoctl and the SIO_KEEPALIVE_VALS Control Code.
I find, that if you control both ends, it is usually better to implement keepalive messages as part of the protocol used to communicate between the client and server instead of relying on SO_KEEPALIVE.
I would imagine that depends on the protocol, implementation and perhaps server config.
PuTTY has an option to prevent timing out of SSH sessions by periodically sending null packets to the server - I suspect this is a simply packet with no actual payload. Perhaps you could implement something like this?
On MSDN you will find that the defaul keep-alive timeout is set to 2 hours. You are maybe able to manipulate this by using setsockopt/SO_SNDTIMEO/getsockopt