My current scenario is
System A is able to ping System B.
System B is not able to ping System A. [ Due to Network misconfig ]
Socket Testing :
I am running a UDP server code in System B.
Is it possible to send UDP message to System B from System A(UDP client) even though ping(B-->A) is not working.
Thanks
Balaganesh
Related
Golang application with a client and server.
Server uses net.ListenUDP -- client also uses net.ListenUDP, connects to server and sends a packet with conn.WriteToUDP with the server address.
Server receives the packet with ReadFromUDP and grabs the return address. Using this return address, it then sends a large number of packets back to the client.
When running both client and server on local machine, this works perfectly. Using Wireshark I can inspect the UDP packets and see that they contain the source and destination ports - and in the application I can see that they arrive and my various checksum tests show the data is accurate.
I then moved the server off site to a remote machine. The application stops working. I can successfully send the first message from the client to server - this is received just fine. The server sends the response back 'toward' the client - but the client never receives them.
Using Wireshark, I can see that the packets do arrive back on the local machine with the correct IP address. It appears that my network router has performed NAT on the outgoing packets - and has correctly re-addressed response packets to the internal IP.. BUT there is no port.
So I have UDP packets arriving on the correct machine, but no port - so the client application does not receive them. Application times out on ReadFromUDP.
I don't know if it is relevant, but on local machine, Wireshark labels the packets as BT-uTP Utorrent packets. When they come in from remote server, this is what I see in Wireshark - note the lack of Port.
Any thoughts how I can solve this. I didn't think this was a UDP hole punching problem because although I am establishing a connection across a NAT it is with a server not a peer.
This packet is fragmented, You can see this under Internet Protocol Version 4 > Flags.
If you look at the frame as shown on the bottom of the picture you provided you should see the ports.
net.ListenUDP doesn't appear to support fragmentation at the socket level.
Do you have a PPPoe connection? You may need to reduce your packet size being sent by 8 bytes or change the MTU on the routers external interface of the remote side. You may also need to change the local routers MTU if it's on a PPPoe interface.
I want to implement a telnet server which listens on different ports for different applications. How to do it in a clean and efficient way?
Suppose I am able to do it, i.e my telnet server listens on port 23 and 12345. If an attacker launches an SYN flooding attack against the telnet server on my telnet server at port 23. What will happen to another port - 12345, when the attack is successful? Is it still accessible?
A SYN flood attack is fully handled in the OS kernel. A server doing accept will only return from accept if the three-way-handshake to establish the TCP connection was already successful, which is not the case with SYN flooding.
But, SYN flooding will affect the memory usage of the system. If this will only affect the single socket or will affect the system in general depends on the OS and maybe its configuration. But it should not actually matter if there is a process handling multiple sockets vs. multiple processes each handling a single socket.
I'm working on simple traffic tunneling solution (Linux).
Client side creates tun interface, routes all traffic on it, packages all arrived packets and sends to the server side via udp or tcp connection.
Server side expected to work like NAT. Change source ip address, source port (for tcp/udp) put packet on external network interface via sock_raw, listen for response via sock_raw, keep map of original-source-port <-> replaced-source-port and send responses back to the client.
The question is: how should I choose replaced-source-port ? OS chooses them from ephemeral ports. I can't choose it by myself, it would cause conflicts. OS kernel chooses port after I send packet via sock_raw and I have no chance to build original-source-port <-> replaced-source-port map. Even if I choose port by myself – OS kernel will reply with tcp rst to all incoming tcp packets with dst port not associated with particular app.
P.S. I'm not sure on the overall solution for tunneling too. Your suggestions would be highly appreciated.
Let's assume I'm in computer A, I have a few servers running on different ports, but all are basically an instance of the same program (just binding to different ports). Now, computer B, a client, does he need to know what port is the software he wishes to connect to on computer A?
The point is, I am implementing some sort of communication similar to sockets. Everything should work fine but I'm not sure how to create the initial-message from a computer to another - I just don't know to what port to send it to. Does the client know the port he's sending to on the server?
Say here (client): clientsocket.connect(('localhost', 8089)), does the client connect a server running on port 8089? If so, what port is his socket on (what port is he using for the client?
Yes. The only way for the network stack on computer A to know which process to deliver an incoming packet is for computer B to set the correct port in the packet. A web server runs on port 80 by default, but a machine running several distinct web servers will run them on distinct ports, and a client must be specific about which server they want to connect to. http://example.com, http://example.com:8080, and http://example.com:12345 would refer to the servers running on example.com on ports 80, 8080, and 12345, respectively.
In order to know which port to use in your client, you need to read the documentation for the server you want to connect to.
Going in the other direction, the port used by the client to receive responses is typically set by the networking stack automatically. The client doesn't need to do anything special to set it, and the server simply sends packets back to the address/port found in the source portion of the incoming packet.
I have 2 sip clients on the same computer.
Both of them is registering to a server that is running on port 5060.
For the first client the UDP is on port 5060 and for the other is 5061. When I come from one client to another, after the ringing part i receive the error:
only one usage of each socket address is normally permited.
Got any ideas why I got this error?
Your server and client are both trying to use port 5060, hence the error message. Change the first client to use 5062 or something else.
Also, 5061 is normally used for secured SIP (normal listening port + 1 in the proxy/server). Do not use it for the second client.
It means you're clients are both trying to claim the same socket for the communication channel, or the server is trying to reclaim the socket given to client A, to reuse it for client B.
The software handeling the socket, should be smart enough to rely on the OS to assign port numbers instead of hardcoding the port numbers in the code, this is a 100% guarantee for socket issues.