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)
Related
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.
I'm using a real machine (hp procurve) for my project, I need to send message of other protocol format, OSPF for instance, instead of flows, from controller side to OpenFlow switch through socket(by specifying ip address and port of the OF switch).
But everytime I try to do this, I get "Connection refused" error message, I guess that it might be that the port on OpenFlow switch I'm sending the message to is not listening, so I think I might need to use the same port for the sending which OpenFlow switch uses to talk to the controller, like the port 51067 in the log info :
Switch:192.168.1.11:51067 is connected to the Controller
My question is, how do I retrieve the port information on the controller side, since it is changing every time I restart it? I couldn't find this information.
Or am I going the wrong direction that I need to go another way around instead of sending the message using socket?
Thanks a lot in advance, any suggestions will be appreciated.
jonesir
I think you are misunderstanding the nature of networking ports, protocol numbers, and protocols such as OSPF. Let me clear those up:
Port numbers: Usually, there is exactly one application listening on a single port: The operating system/networking stack checks each packet of certain types (e.g. TCP or UDP) for the port number and then passes the packet to the application that registered itself for that specific port. If the application cannot handle the received packet then usually it will just ignore it or log an error.
Aside: It is possible for two applications to communicate on the same port only if you put some sort of multiplexing application before both (usually a reverse proxy, possibly a TCPMUX application). This multiplexing application would take incoming packets, determine what type of packet it is and then pass it to the correct application.
Protocol numbers: The protocol number is a field inside an IP packet that tells the networking stack what type of data is contained inside. For example, TCP is protocol 6, ICMP is 1, and OSPF is 89.
OF switches: Now, logically an OF switch consists of two components: 1) the switching fabric (which includes the physical ports and OF flow tables), and 2) a separate physical port to for out-of-band control, with several applications running behind it. One of these applications is the OpenFlow application, which in your case happens to listen on port 51067. But in real switches, other applications might also be running on different ports, e.g. a web interface running on port 80 for maintenance etc.
OSPF: If you now wanted to talk to the application serving the web interface, you'd send a TCP packet with destination port 80 from your controller to the switch. Similarly, if you'd like to install a new flow, you'd send an TCP packet with port 51067 in your case. OSPF is quite different, as it directly uses IP packets and does not use port numbers. To process an OSPF packet, an application needs to use a raw socket to process the incoming IP packets that have protocol number 89, and skip all others. See also the raw manpage here. This will already be built into your OF switch.
Thus, if you want to send an OSPF packet to the OF switch (and your OF switch supports OSPF on the separate physical port!), you'd just send an OSPF IP packet to the switch's IP address (192.168.1.11), no port needed!
Note that the separate physical port might not support all of the features of the other ports on the OF switch, as they are not intended for the same uses.
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.
In Rails what would be the best way of integrating a UDP listening process that updated certain elements of the model (specifically its going to be adding rows to one of the tables).
The simple answer seems to be start a thread with the UDP socket object within the same process, but its not clear quite where I should even do that which fits with the rails way. Is there a neat way to start listening to UDP? Specifically I'd love to be able to write a UDPController and have a particular method called on each Datagram message. Ideally I would want to avoid using HTTP over UDP (as it would waste some of what in this case is very precious space) but I am fully in control of the message format so I can provide Rails with any information it would need.
Rails is a web application framework, not a server daemon framework. Unless you know of a web server that passes UDP packets, I imagine you would have to write and run a separate process and either have it talk to your Rails app via HTTP or just manipulate the database directly.
Let me make a pitch for TCP. UDP is a "throw the packet to the wind" protocol which provides no reliability. It finds uses in, for example, voice over IP where the odd dropped packet is acceptable. By using a TCP socket, you can still avoiding using HTTP, plus TCP stack will handle retries & etc. for you.
A TCP server which is launched by inetd is the simplest thing in the world: you write a program that reads from stdin and writes to stdout, then tell inetd to run that program whenever requests come in on a certain port. You won't have to write any network code.
Here's a simple inetd tcp server:
#!/usr/bin/ruby1.8
input = gets
puts "You said: #{input}"
Here's how to tell inetd to run it:
1024 stream tcp nowait wconrad /tmp/tcpserver.rb
This means to listen for tcp connections on port 1024. When they occur, launch /tmp/tcpserver.rb as user wconrad. man inetd.conf for more information.
You can test it with telnet:
$ telnet localhost 1024
Trying 127.0.0.1...
Connected to ceres.
Escape character is '^]'.
Howdy!
You said: Howdy!
Connection closed by foreign host.
$
Or you can use a simple client:
$ cat /tmp/tcpclient.rb
#!/usr/bin/ruby1.8
require 'socket'
t = TCPSocket.new('localhost', 1024)
t.puts "Hello"
t.close_write
puts t.read
t.close
$ /tmp/tcpclient.rb
You said: Hello
and just to show that tcp servers in Ruby are easy:
!/usr/bin/ruby1.8
require 'socket'
def handle_session(socket)
s = socket.gets
socket.puts "You said: #{s}"
socket.close
end
server = TCPServer.new('localhost', 1024)
while (session = server.accept)
Thread.new do
handle_session(session)
end
end
With TCP being so easy, you need a compelling reason to bother with UDP.