I have an RN-171 wifly module connected with a micro-controller.
I am using the UDP-protocol to communicate with the module. Also, I am using the firmware's UDP auto-pair feature to set the host ip. As soon as the module receives a UDP packet, it sets the host IP address to the ip from where it received the data. Now, this host ip cannot be changed without entering into the command mode.
I want the module to behave in the following way:
Every time it receives a UDP packet, it updates the host ip to the ip address from where that signal came from.
Also, I can use the TCP protocol but it only allows a single connection at a time. One more problem that I faced using the TCP protocol was that if I try to initiate a second TCP connection with the module, it not only refuses the second connection but also hangs the first stable connection. Even if the second connection initiation does not hang the module and it just gets refused, I will be ready to work with TCP.
I have been researching a lot on the web regarding this problem but since these modules are not widely used, they have a very limited support.
I've used RN-171 extensively and have many resolved tickets in their support system.
According to the WiFly Command Reference, Advanced Features and Applications User’s Guide, you cannot open more than one TCP port with the module. (the default number being 2000)
Unfortunately, regarding the UDP functionality, there's not much you can do. If you have a new host wishing to communicate over UDP, connect to the module over TCP, go into command mode and set the address using "$$$", "set ip host 0.0.0.0", "save", "exit" commands. Alternatively, instead of 0.0.0.0, you can enter the new host's own ip address: "$$$", "set ip host ###.###.###.###", "exit". Replace "###.###.###.###" with the ip address of the device.
This way, you won't get wrong host ip in case more than one device communicates over UDP at the same time. Also, by not using "save", the auto-pairing will still be saved to EEPROM memory. Also, you can send "ip flags 0x##" before "exit", this way you can also set bit[6] to 0 (UDP auto pairing disabled) temporarily by using the hex value that has this bit set to zero.
One of my problems that Microchip technical support tested around the summer of 2013 is that you cannot use RN-171 as an access point for other RN-171s since they have a firmware error preventing one from doing that and, as of firmware v4.41, released in January of 2014, there is no fix yet nor planned.
I myself do not recommend the latest firmware version v4.41, since it does not appear to work with most routers; however Soft AP mode on this works fine. On the other hand, v4.00.1 is much more compatible, however you should take care when cutting off the power since it has a potentially disastrous bricking problem if you cut the power when flash writing is in progress - the module may lock its memory forever.
I recommend registering and opening a Microchip ticket which usually will be answered within two business days and they're quite supportive. Their firmware update cycle is however quite long, and it usually takes a year or so for a new update.
Related
I am puzzled...
My project is a PC connected to multiple micro-controller boards in an isolated network. So far the protocol has been UDP which is easy to deal with, has no particular client/server but has its obvious shortcomings of lost messages when things get busy.
The micro-controllers have fixed IP-addresses (set by dip switches), the PC SW has a list of them, sends at present UDP messages to each of them and they reply to the address they came from (i.e. the PC) with status and/or data.
My question is now that I switch to TCP instead of UDP, should the PC be the listening server with many clients (could be anything from 1 - 50), or should the micro controllers be listening servers the PC can connect to as client? Note: controllers have fixed/known addresses - the PC does not.
An additional concern is re-connection. The micro-controllers are external and may lose connection, reset or otherwise need to connect again.
Thanks....
should the PC be the listening server with many clients (could be anything from 1 - 50), or should the micro controllers be listening servers the PC can connect to as client?
That is a basic design question that we cannot answer for you. Likely, it's more practical for arbitrary devices to connect to a central server but that's not a given.
controllers have fixed/known addresses - the PC does not.
That might turn the previous question around.
The micro-controllers are external and may lose connection, reset or otherwise need to connect again.
That's something you need to put into your design - have TCP connections time out and reconnect. Usually, a finite-state machine is useful here. You should also consider whether you use a one-shot connect-transmit-disconnect similar to UDP (easier to implement) or a longer TCP session with multiple data transmissions (more efficient).
I have 16 Arduinos that are in very tight spaces and hard to get to when I need to reprogram them with my FTDI cable. I would like to have or create some sort of centralized place where I can connect my FTDI cable, make some sort of selection (switch of some sort), which will then connect the pins my cable is on to the selected arduino.
Does anyone have any thoughts on how this can be accomplished? I've toyed with transistors, but that takes a lot of them and didn't quite work.
Are there any premade solutions that are out there that I have yet to find?
Thanks very much!
Here is a thought! TCP to Serial.
Sound complicated.
Not really.
Note from AVRDUDE's manual the following
For programmers that attach to a serial port using some kind of higher
level protocol (as opposed to bit-bang style programmers), port can be
specified as net:host:port. In this case, instead of trying to open a
local device, a TCP network connection to (TCP) port on host is
established. The remote endpoint is assumed to be a terminal or
console server that connects the network stream to a local serial port
where the actual programmer has been attached to. The port is assumed
to be properly configured, for example using a transparent 8-bit data
connection without parity at 115200 Baud for a STK500.
With this, One could place your Arduino's behind your choice of TCP to Serial Server. Which is available in several forms. Cisco has a gang TS (but that is expensive, unless used). lantronix (and others have single end point devices. But then for Linux, there is "Net2Ser" which can serve up all your ttyS (aka Serial/COM ports).
With the later you could use a raspberry or TP-Link TL-WR703N (
In the latest IDE 1.5.6r2 add one entry for each TCP-to-Serial Port to ./Arduino/hardware/arduino/avr/programmers.txt file. While replacing the IP and Port with corresponding values.
TCP2001.name=TCP 2001
TCP2001.communication=serial
TCP2001.protocol=stk500v1
TCP2001.program.protocol=stk500v1
TCP2001.program.tool=avrdude
TCP2001.program.extra_params=-Pnet:192.168.1.100:2001
TCP2002.name=TCP 2002
TCP2002.communication=serial
TCP2002.protocol=stk500v1
TCP2002.program.protocol=stk500v1
TCP2002.program.tool=avrdude
TCP2002.program.extra_params=-Pnet:192.168.1.100:2002
...
Additionally change "protocol" to "upload.protocol" the following line in ./Arduino/hardware/arduino/avr/platform.txt
tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{build.path}/{build.project_name}.hex:i"
to
tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} -p{build.mcu} -c{upload.protocol} {program.extra_params} "-Uflash:w:{build.path}/{build.project_name}.hex:i"
With this you can use "Upload Using Programmer" with the selected programmer to send over TCP, rather then use the Upload.
That all said, it will only work on Linux.
avrdude: ser_open(): network connects are currently notimplemented for Win32 environments
I want to send files from Qt Application using Ethernet.As I click push Button the files must be transfered.
so my Question is:
Q: what are the configuration required because IP ,Net Mask is fixed in my device I am using :AM335x
:Linux OS
:Qt application
I am new to TCP/IP tell me how to proceed;
from Ethernet I am able to download Qt application executable file from PC to my device(AM335x) and it is running well .
But I want to send files from Am335x device to other device or PC.
Regards
Praveen
Basically what you want to be using is the Qt Network module. You can read about that here:
http://qt-project.org/doc/qt-5.0/qtnetwork/qtnetwork-programming.html
And find a class list here:
http://qt-project.org/doc/qt-5.0/qtnetwork/qtnetwork-module.html
Very briefly the two main classes you can use for TCP communication are QTcpServer and QTcpSocket. You can set up the server to listen for connections and it will return a QTcpSocket to do the actual communication. You can use the QTcpSocket for any outgoing communication.
If you don't want to use TCP, you can use datagrams (simpler, but ultimately less reliable). Here QUdpSocket is the main class to use, both for sending and receiving (you need to bind the socket to a port on your machine to receive).
It would be fairly easy to write a custom program to do simple file transfer based on these classes, however you can also look at higher level protocols designed to deal specifically with files.
For simple interaction with an FTP server at the other end of the connection you can use the QFtp class. An example of an FTP client application is here. Writing an FTP server in Qt would be rather more complicated, however you can look here: https://code.google.com/p/qt-ftp-server/.
All of this of this of course assumes that the Ethernet connection has been set up properly and that your computer has a valid IP address. Bear in mind that Ethernet is a link layer protocol and forms the raw basis for the higher level IP and TCP protocols. The idea of the higher level protocols is that they can used over a variety of link layers throughout the internet. It would be very unusual to write a program that interacts directly with a link layer protocol (unless of course you are writing a network stack for an OS).
On most networks configuration of IP addresses/netmasks etc is handled by a DHCP server running on one of the devices, most commonly on the router connecting everthing (if you have DHCP already running, then you probably don't have to worry). Without DHCP you can usually configure a static address and netmask on most devices. Choosing them is a fairly simple procedure. This page has a fairly good introduction to the concepts.
At first, you must be sure, that the target you want to send file to, is reachable. Use ping. If ping call is successful, then you can go further. Otherwise you should check your network settings to comply with your LAN.
You have then various ways to send files: FTP, HTTP, via netcat, using CIFS etc.
I am programming a server and client program to communicate between a windows PC using the Boost libraries and a Linux ARM beagleboard using the asio stand alone libraries. I have for a while had successful UDP communication between the two devices but now I want to recover the port from the endpoint the server discovers when the client connects. The way the client connects is via query:
udp::resolver resolver(io_service);
udp::resolver::query query_tx(udp::v4(), hostIP, "43210");
udp::endpoint receiver_endpoint_tx = *resolver.resolve(query_tx);
where host IP is a string and this works fine. Upon debugging though I notice that when i check the value returned by:
receiver_endpoint_tx.port()
This returns 51880. Now don't jump the guns and yell out network byte order and host byte order. I AM AWARE. The strange part is that this number 51880 sometimes is a different number and when i check what the server has stored in its endpoint it is a completely different number: 21743. Now I know I must be doing something wrong with the byte orders but i tried:
//unsigned long port_long = boost::asio::detail::socket_ops::host_to_network_long(receiver_endpoint_tx.port());
//unsigned long port_short = boost::asio::detail::socket_ops::host_to_network_short(receiver_endpoint_tx.port());
And they do not give me back my original port: 43210. Neither does network to host. So what am i missing and how can I on both ends recover my 43210 port? Obviously it must be there somewhere because they are successfully communicating.
Thanks in advance, sorry if noob mistake :)
Fistly, UDP is connectionless, there is no connection.
I'm not sure if I understand you correctly, but it sound too me like you want to bind to specific port numbers. If you want the client to send a packet from port x to port y on the server, and the server should respond from port y to port x, then you need to bind the sockets to the desired ports. Alternatively you can use the constructor to bind. Not doing so will result in the OS using ephemeral ports.
Further, to get the remote endpoint that a packet was received from the async_receive_from takes the sender_endpoint reference parameter. When the read handler is called, you can retrieve host and port from it.
How can I connect a system to a network and sniff for virus/spyware related traffic? I'd like to plug in a network cable, fire up an appropriate tool sand have it scan the data for any signs of problems. I don't expect this to find everything, and this is not to prevent initial infection but to help determine if there is anything trying to actively infect other system/causing network problems.
Running a regular network sniffer and manually looking through the results is no good unless the traffic is really obvious,but I havn't been able to find any tool to scan a network data stream automatically.
I highly recommend running Snort on a machine somewhere near the core of your network, and span (mirror) one (or more) ports from somewhere along your core network path to the machine in question.
Snort has the ability to scan network traffic it sees, and automatically notify you via various methods if it sees something suspicious. This could even be taken further, if desired, to automatically disconnect devices, et cetera, if it finds something.
Use snort: An open source network intrusion prevention and detection system.
Wireshark, formerly ethereal is a great tool, but will not notify you or scan for viruses. Wireshark is a free packet sniffer and protocol analyzer.
Use the netstat -b command to see which processes have which ports open.
Use CPorts to see a list of ports and the associated programs, and have the ability to close those ports.
Download a free anti-virus program such as free AVG.
Setup your firewall more tightly.
Setup a gateway computer to let all network traffic go through. Take the above recommendataions to the gateway computer instead. You will be checking your whole network instead of just your one computer.
You can make Snort scan traffic for viruses. I think this will be the best solution for you.
For watching local network traffic your best bet (with a decent switch) is to set your switch to route all packets out a specific interface (as well as whatever interface it would normally send). This lets you monitor the entire network by dumping traffic down a specific port.
On a 100 megabit network, however, you'll want a gigabit port on your switch to plug it into, or to filter on protocol (e.g. trim out HTTP, FTP, printing, traffic from the fileserver, etc.), or your switch's buffers are going to fill up pretty much instantly and it'll start dropping whatever packets it needs to (and your network performance will die).
The problem with that approach is that most networks today are on switches, not hubs. So, if you plug a machine with a packet sniffer into the switch, it will only be able to see traffic to and from the sniffing machine; and network broadcasts.
As a followup to Ferruccio's comment you will need to find some method of getting around your switches.
A number of network switches have the option of setting up port mirrors, so that all traffic (regardless of the destination) will be copied, or "mirrored", to a nominated port. If you could configure your switch to do this then you would be able to attach your network sniffer here.
Network Magic, if you don't mind something that's not open source.
You can use an IDS, hardware or software
http://en.wikipedia.org/wiki/Intrusion-detection_system