I am new to GNU Radio and Linux.
I want to send processed data out from gnu companion to a software/dashboard whose input is LAN/TCP/IP.
I am using RTL dongle and USRP and i have done GMSK demodulation successfully.Now want to send the demodulated data to a software for presentation and display developed by another team.The dashboard/software uses Ethernet data as input and has ip address and port as input parameters.
Currently i failed to send a random data via TCP sink and receive it via TCP source blocks on loopback address.
Please help me
Did you set the TCP Sink to "Server", and the Source Block to "Client"? Only the block that is set to "Client" needs to know the address, but both need to know the Port.
And is the port you use for your loopback test free, or could another program be using it?
Also, if the Nonblocking mode for the TCP blocks is off, the execution of the flowgraph is halted until a connection is established. I’m not sure but I think that could lead to problems if they are supposed to connect to each other in the same flowgraph.
Try using an external program (like netcat) for debugging instead. netcat will probably not display it correctly but it’ll tell you if any data at all is coming through.
Additionally, the TCP source and TCP sink blocks are deprecated and shouldn’t be used, use UDP or ZeroMQ for communicating with external programs instead, if possible.
Related
I have a language monitor that I am trying to query the printer from.
First let me apologize for the possible confusion since "port" means 2 things in this description. There is the one use that refers to the port that the printer is configured to use, which could be TCP, USB, etc. And then there is the use of port that refers to the port address to send data to when communicating with the printer's IP address.
I need to be able to specify different port addresses to send different custom queries to a printer over the same IP that are specific to it's firmware. I can't find any examples or documentation on what the standard way is to do this communication... I can extract the IP address and open a net socket, but I am not sure if this is the appropriate way to handle this communication. It's not uncommon for printers to send status over one port, and print data over another. If i want to write to the Default port I can use pfnWritePort and pfnReadPort, but these don't allow me to specify the actual port.. it uses whatever the driver is configured as.
Can anyone provide some guidance or examples of how I should do this from my language monitor?
EDIT: As an example for clarification, all commands are sent to the same IP, but depending on the command/query I need to send, the TCP port needs to change. The way I am handling it now is opening up a net socket with the same IP and different port numbers for data and status channels).
You should be required to write an app that would be able to reconfigure driver. Ideology of OS is that EACH real device would corresponds to instance of driver and\or interface. Which might be an elevated action, because it requires to create new printer interface("port" in Windows GUI terms) and change driver settings.
As I know raw socket allows to send and receive IP packets without any specific transport layer protocol.
Dart's "dart:io" comes with RawSocket class defined as a low-level interface to a socket (maybe they mean TCP socket).
My question is does Dart's RawSocket allow to directly send and receive IP packets? if not, is there're any way to do so in Dart?
As far as I know, there is no possible way to directly send and receive IP packets in Dart. RawSocket and its variants shouldn't be confused with what are known as raw sockets, as they just expose raw events signaled by the system. The fact that these socket classes have the Raw prefix is just the result of an unfortunate naming choice.
I am trying to program a script to interface two applications, so I need to understand a few basic concepts, if someone could please help me grasp them:
When an application's manual says: This app listens to localhost:9763, it means it receives live data from the same machine on port number 9763. Is this correct?
So, if an application's manual says: Listen on UDP port 6004, it means I have to specify localhost:6004 similar to the first point?
Or does the first point (localhost:9763) imply that TCP/IP is being used, but the second point is on UDP?
Generally speaking, if an app says it is listening on a particular port and doesn't specify TCP or UDP, that usually means TCP. If you're not sure, you can probably figure it out based on what that particular app does and how it does it.
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 want to implement a demo application to listen data via TCP/IP.
Data Transmitter will transmit a series or ASCII char or a series of string all the time. It feeds data into TCP/IP address (eg. 127.0.0.1:22) This could be a GPS transmitter.
I want to implement a demo application for receiving data by clicking the start button and listening to the data via TCP/IP and display it accordingly.
Correct me if I am wrong, I don't think I can use Server/Client server for this purpose. I tried to create a client application with TIdTcpClient, it receives only one time data. I don't think Indy has a TCP listening component.
Thanks in advance.
If you wanna monitor network comunications between some device and some other program on your computer using of TIdTCPServer won't work. Why? Once Indy will read network data it will mark it as processed and delete it from network buffer. So that data probably won't even reach to the other program on your computer. Workaround for this is that you design your application to actually work similar as network bridge. Your application listens to the data on one port and then forwards that data on another port on which the other program is listening. But the main problem is that you have to make this to work both ways.
What you need is somekind of a component which is able to peek at the network data but don't interact with it. This is usually done on driver level.
Now if it is not abolutely necessary to have such functionality in your own software but you are only interested in getting the data I recomend you try Wireshark (http://www.wireshark.org/). Wireshark is a verry powerfull freware software which alows you to monitor all netwrok traffic on basically all protocols without causing any interuptions. In order for this software to work it instals special driver which serves for intercepting the network data.
Maybe you would want to use same driver in your application if this functionality needs to be in your application.
Based on your diagram I think that your implementation could also be based on a message-oriented middleware, using a message broker which receives the GPS transmitter or other data.
The message broker would then store the data internally and forward it to all interested clients which are connected. A typical messaging pattern in this case is a "Topic", which broadcasts the messages similar to a radio station.
So the middleware will ensure that the information will be collected (optionally also persisted to disk) and then guarantees the delivery to the receivers. This can be done even in a way where receivers which have been off-line for a while still receive the GPS messages created while they where not listening ('retroactive consumers').
There are many popular free open source message brokers, and most of them also can be used with Delphi.