I've written a program that can connect to another instance of the same program. I run both and they work for a time, happily sending data back and forth. But randomly, things mess up. Through Wireshark, I see that I'm getting ICMP Destination Unreachable (port unreachable) messages.
After testing this over two computers on the local network; the same issue occurred.
It appears to be random. I.e., everything is working correctly up until it decides to send these messages.
Does anyone have any idea what can cause this?
In UDP it is the equivalent of a TCP 'connection refused', i.e. nothing listening at the target port.
Related
I have the following problem with "Mikrotik RB3011UIAS-RM!
I downloaded the application form "Mikrotik"website BTest and run some test with it. The test with tcp protocol was successful but when I try to do a test with udp I get the message "disconnected" and this one shows only when i am sending info to it!
Here is is the picture and the result that
Btest
reruns
If the only thing you're changing between the TCP bandwidth test and the UDP bandwidth test is the protocol, verify that there are no firewall rules blocking UDP from port 2000 and up.
You could try adding a rule explicitly allowing UDP 2000 to 3000, which should be good for a bunch of tests since RouterOS allocates UDP ports as needed.
Please note that port UDP/2000 is the default and may be configured differently on your system.
You could also try to decrease the Local Tx Size in case the packets are unable to be delivered due to excessive size for your network.
-Rich Alloway (RogueWave)
We have installed a proxy inbetween host and internet. when i make a request google.com and if i see the communication in wireshark, i can just see the communication to proxy and reply from proxy, since proxy makes the actual request and reply to host.
in this case, how do we see the actual communication even if proxy is in intermediate. i have tried to open the packet and saw "Follow TCP Stream", but i could not find more information from it.
like communication from host to google.com in wireshark?
If you want to capture the traffic between the proxy and the destination, You would need to run wireshark on a machine that can see the traffic between the proxy and the destination. Eg, on the proxy, or on a machine connected to a switch setup to do port mirroring, or ...........
Basically though, without telling us the exact network layout, we cant help.
I'm trying to implement the following UDP protocol, but I'm having a little trouble figuring exactly how I should approach this.
The protocol states that I should send a particular UDP packet to a certain server, after which the server will stream (several UDP packets that are related) a response back to me, also as UDP packets. I have managed to send the UDP packet fine using the following code:
connection, error := net.DialUDP("udp", nil, endpoint)
...
if written, error := connection.Write(query.ToBytes()); error != nil {
...
} else {
log.Printf("Successfully wrote %d bytes to %s", written, connection.RemoteAddr())
}
When I use Wireshark and take a look at what's going over the wire, it looks like it sent the packet just fine (the only issue here is that I never get a reply from the server, but that's unrelated to this question).
What's the best way for me to handle the server reply in this case? Can I use the previously established connection to read server responses back (this seems unlikely to me, as it's UDP so connectionless) or should I use net.ListenUDP(...) to establish a server on the correct local address and port to read whatever the server sends back to me?
The intent of the protocol is clearly that you just use the same UDP socket to receive the reply that you used to send the request. If you have a client-side firewall, you will have to explicitly open a UDP port and bind the UDP socket to that port before you send. Otherwise just let the system choose the local port, by not binding at all.
The phrase 'the same port as was established by the intial packet' is misleading. Are they your words, or the protocol specification's? What really happens when you do the first send is that if you haven't bound the socket yet, it is automatically bound to a system-chosen port, exactly as if you had bound it to port zero.
Because of the specific protocol design, it's impossible to know on which port the server will send its reply packets. After taking a second look at the packet dumps, I noticed that the server in fact does reply, only the client immediately replies back with an ICMP message saying Destination port unreachable. So the server was trying to reply, but it couldn't because the client would not accept the packets on that port.
To solve this, I have used net.ListenUDP to listen for incoming packets immediately after the client sends the initial packet using the established connection's local address:
incomingConnection, _ := net.ListenUDP("udp", connection.LocalAddr().(*net.UDPAddr))
log.Printf("Listening for packets on %s", incomingConnection.LocalAddr())
defer incomingConnection.Close()
After which incomingConnection can be used as a Reader - for example - read the packets that the server is sending.
I have an application that is designed and working that is receiving UDP broadcasts on a port. The application has been working just fine, but I have wanted to compare the packets received by the application with a Wireshark capture. I'm trying to make sure that I'm capturing as many of the packets as possible with minimal data loss.
I initially thought that I'd run Wireshark and compare the raw packets captured against the packets shown in our application. However, when I run Wireshark, the packets are never captured at the IP layer for that port. I see other traffic from the server, but I never see Wireshare packets for this specific port.
The application continues to capture the data just fine. When I look at the IP src/dest fields, the src looks correct, 10.12.10.42, however the destination IP address is 0.0.0.0. I would have expected something like 255.255.255.255 instead for the destination address.
I don't have access to the application that is broadcasting the data, but I did write a quick sample UDP broadcaster and receiver to make sure I my expectations were correct. the sample application worked as expected.
Any ideas on why a UDP broadcast would be received by an application, but not show up in a Wireshark capture? Does Wireshark ignore an address like 0.0.0.0 and not capture it all?
Wireshark only captures Ethernet frames that are going through an interface you are listening on. Thus, packets destined on loopback addresses are not captured. I would check your machine's routing tables to see where packets are actually going.
I am a newbie in network related aspects. I have few basic questions related to tcp/ip protocol and network
If a network switch (in a LAN network) between two PC's running Client and server (that are communicating through async. sockets) is powered down. Can the client and server will be notified that the socket connection is no longer active. Client and server are running on Win XP OS and are coded using C#.
Does network topology play a role in case of half open connection between socket client and socket server. For e.g. Will a disconnect status of either one or both be notified to other end and does it depend on network topology.
Thanks in advance.
A network element such as a router/hub/switch does not activly cause anything anything to happen on the TCP layer if it goes down. The operating system might notice that the physical layer is down and error out all sockets bound on that network card if it's a network element directly connected to the PCs that breaks - this will vary among operating systems/network cards and other things. Other than that, in order to detect that the connection has been severed, you'll have to send something and rely on the TCP timeout mechanisms to error out. This can be done implicittly by enabling TCP Keepalives on the connection.
A disconnect on one side will only be noticed if those messages reach the other side, if the network topology changes or sometinhg breaks in the middle of the connection in such a way that messages no longer reach the other end, a disconnect won't be noticed. (NAT gateways are a big source of problems such as this, they might time out a TCP connection they're tracking and you'll never know the connection is no longer valid unless you try to write something (or enable TCP keepalives) to the connection). Note that most networking APIs require that you Read from the connection to discovver that a the other end has closed the connection - assuming those "close" messages actually reach your side.