Using iperf3 for measuring UDP throughput on STM32 board - udp

I have STM3220G-Eval board with STM32F207 MCU. I've loaded UDP Echo Server lwIP based sample application (from CubeMX archive). This app used port #7. I've tried to use iperf3 in client mode (Windows OS), but it failed to work with the board (though Echotool successfully worked as a client). Can iperf3 work with custom UDP echo server?

Short answer: Not really. The iperf3 client and server need to communicate with each other over a control channel that is set up before the test starts. This allows them to exchange test parameters, ending conditions, and so on. If you wanted to make an iperf3 server on your embedded system, it would need to speak the (not very well documented) control protocol used by the iperf3 client.
iperf version 2 doesn't use a control channel; it might work for your application if all you need to do is send UDP packets to your board.
Bruce.

Related

replaying multicast UDP packet capture via tcpreplay not being seen by client

I'm having no joy in getting a replayed UDP Multicast packet to be "seen" by a client program on a different machine.
Details:
I have two machines on my local (wired) network connected through one unmanaged switch. One machine (running tcpreplay) is running Ubuntu 20.04, the other machine is running Windows 10.
On the Windows machine I have a Python program I wrote which listens for UDP multicast packets on port 5110 (this is dictated by the source of the UDP stream which is a commercial program). When I run the commercial program, my Python code correctly consumes the incoming packets and all seems to be working fine. I have a lot of work yet to do on the contents of those packets after they are received, but that isn't important for this issue.
So, moving forward, I decided it would be great to be able to work on the Python code without having the commercial program always running in the background hogging up resources. I figured if I could catch a snippet of UDP broadcasts from that program, I should be able to replay at leisure without having to run that resource hog.
So, on the Windows machine, I captured a UDP multicast packet stream using Wireshark and saved to a pcap file which I then copied to the Ubuntu machine.
I then attempted to replay that pcap file (on the Ubuntu machine) as follows:
$sudo tcpreplay -i enp5s0 single.pcap
To my disappointment, my Python program (on the Windows machine) did not receive the incoming packets.
Back on the Windows machine, I fired up Wireshark again and captured the "replayed" packet coming from the Ubuntu machine - so it appears the packet did make it out of my Ubuntu machine and into my Windows one. The contents of both the source packet (sent by tcpreplay) and the received packet (grabbed by Wireshark) appear identical - including the source and destination MAC addresses and the checksums. A diff on the byte contents of each packet yields no differences.
However, my Python program still stoically sits there waiting at:
data, address = sock.recvfrom(1024)
Here on stackoverflow, I did find this thread which seems to be an identical problem, however none of the solutions presented within helped (including changing the rp_filter parameter). I also saw mention of a Windows program, "Colasoft PacketPlayer", which I tried - running on the same machine as my Python client. This appears to have the same apparent results (i.e. no joy). I did not initially try that route as I was concerned with generating the packet on the same machine which is listening for it. (As an aside, I did also capture the replayed packet from Colasoft PacketPlayer and it too appears identical to the source packet).
At this point I'm out of ideas and am reaching out to the community for possible next steps?

Consistent increases and decreases in iPerf TCP throughput

I am using iPerf to try and test the Wi-Fi performance on my router. I have set up two computers, a HP Zbook (Client) and a Macbook Pro (Server), to demonstrate this connection. The client is connected directly to the router via LAN and the server is connected to the router via Wi-Fi.
My iPerf script sets the TCP window size and sends data for certain time limits from the client to the server. The output on my server goes up to an expected throughput for a few seconds and down to a very low throughput for a few seconds at relatively constant intervals for all Wi-Fi configurations on my router (various bands, 802.11 protocols and channel bandwidths) as well as in noisy and clean environments. Can anyone suggest a possible reason for this? Is this how the Wi-Fi protocol works? Or is this a problem with iPerf?
The iperf version on the client is iperf3 v3.0.11 (windows 64 bit) and iperf3 v3.0.1 (mac osx).
Client OS: Windows 10
Server OS: Mac OS X El Capitan v 10.11.5
I have ran a TCP test as well as two UDP tests (with bandwidth set to 1.05Mbps and 150Mbps) and attached the output screenshots. Wi-Fi config: 802.11ac, 40MHz, 5GHz
jPerf depiction of my iPerf script for a 180 second test case on 5GHz, 80MHz, 802.11ac
Testing screenshots: https://imageshack.com/a/SktM/1
Please include the iperf output for both client and server and use interval reports (-i). Also, include iperf -v and the operating system information. Also, make a run with UDP and capture the reports on both client and server. If you're using Linux on the client and iperf 2.0.9, the -e (enhanced reports) can provide even more information.
Wi-Fi throughput problems are like somebody having a fever in an Emergency Room. There are many different factors that have to be looked at.
Bob

how to transmit serial data from GPS device to computer through IP?

Well..I have found some third party application regarding sending data from com port to IP. but I have not found any basic tutorial regarding them. so can anyone help me with this? I have a GPS device which I will connect to my laptop through usb to serial adapter.Now I need to send that data from a laptop to another laptop on same network. Can I use putty to view that data in another laptop(receiver)? Is virtual serial port driver meant for this kind of application?
If you do not want to write your own tool for it, you can simply use ncat and set up a daemon that reads piped data from one process and broadcasts it to all connected clients.
If you want something that reads the data from the serial port and then transmits it to clients, you'll need to write a server application that accepts connections and sends data around, but there's entire books on this. It should be easy to do for your purposes as written here, but it depends on the amount of control you need.
Alternatively you can use a virtual serial port application as you had mentioned, which might be the easiest route. The two devices will need to be on the same network unless the application supports TCP based virtualization instead of the common Ethernet based implementation.
This Python script works very well as a free "device server". Just enter the serial port configuration and the IP address and port information.
https://github.com/jaredly/pydbgp/blob/master/symbian/serial_tcp_redirect.py
This can work on both Windows and Linux.
You need pyserial.
You can always try using stand alone hardware such as the SENA LS100 device server.

WWAN Interface AT Commands

I've got a Windows 8 Professional device which has got a Mobile Broadband adapter embedded and I need to be able to send AT commands to the modem, usually I'd connect to the COM port and send the commands. However the device doesn't appear to have any COM ports, instead it presents its self as a network adapter.
I'm wanting to send AT commands to change the APN of the modem and to reset the device, I've looked into the 'netsh mbn add profile' but this command always returns an error advising that the XML profile is incorrect.
Also from looking at the functions of the netsh mbn it doesn't seem to provide as much control as sending AT commands.
The modem that I'm trying to interface to is the Ericsson C5621 GW on a Lenovo ThinkPad Tablet 2.
Is there another way to send AT commands?
Thanks
I do not know this product in particular, but since I worked in Ericsson, later in ST-Ericsson with mobile phone development for over a decade it is doomed to have some of my code in it so I'll answer on a general basis.
Short version is, no unless the device exposes a serial interface over one of the external interfaces (possible interface types are RS-232, IrDA, Bluetooth, USB or CAIF), there is no way of sending AT commands to it1.
Being an embedded device in a laptop and
your since you say it seems to be without serial interfaces I assume it uses CAIF (commonly used in embedded settings. It could also have be using USB with the serial interfaces disabled, but since this press release mentions that it will be available in a version with PCI interface, that is very unlikely). And thus unless the device is set up with any active VEI channels, there is no ways in for AT commands.
There might be other ways of changing the APN though.
1 We had a debug mechanism to inject AT commands onto arbitrary serial interfaces, but this itself was running on a serial interface, started by an AT command. And besides it will not be present in released products.

Virtual COM Communications Issue

I'm working on a Communications Device Class (CDC) driver for an embedded device, a Full Speed implementation of USB 2.0. The COM port settings are 115200, 8-bit, no parity, 1 stop bit, no flow control. Our PC application (32-bit, Windows 7, .NET 2.0) communicates with the target device through a virtual COM port, which on the target device can connect to either a FTDI (USB-to-SCI bridge) chip or the integrated USB peripheral in the microcontroller, depending on which port is selected by the application.
Both virtual COM ports work without any problems using Realterm. However, while our desktop application works using the virtual COM port connected via the FTDI chip, it hangs when attempting to use the virtual COM connected via the microcontroller's integrated USB peripheral.
When connected via the virtual COM port using the integrated USB, the application consistently hangs on the second call to SerialPort.Write(...). Using Serial Monitor from HHD Software I can see that the data is transmitted on the first call to SerialPort.Write(...). However, that data is never received by the target device.
It's odd because the only time I have seen similar problems on previous projects was when the flow control settings on each side of the bus were mismatched.
Additional info...
Here is the data captured from various port monitoring tools while running our PC application connected to the target device via its integrated USB peripheral. Any insight would be appreciated.
Sysinternals Portmon
Advanced USB Port Monitor
Device Monitoring Studio - Request View
Device Monitoring Studio - Packet View
For those that are interested, I am using CodeWarrior 10.2 with the MCF51JM128 from Freescale.
Any ideas or suggestions would be appreciated. Thanks.
It is clear from the logs that you are making the classic mistake of not taking care of the hardware handshaking signals. That only ever works by accident, a terminal emulator like Realterm will never make that mistake.
You must set the DtrEnable property to true. That turns on the Data Terminal Ready signal. It is important because RS-232 is an unterminated bus so is subject to electrical noise when the cable is disconnected or the power turned off. DTR convinces the device that it is in fact connected to a powered device. This is emulated of course in your case but the driver or firmware will still typically implement the RS-232 behavior.
And the RtsEnable property is important, used to handshake with the device and prevent the receive buffer from overflowing when the app isn't emptying the buffer in a timely matter. You really should set the Handshake property to Handshake.RequestToSend, the most common way a device implements it. Which then also takes care of turning RTS on. If you have to use Handshake.None for some reason then you have to turn it on yourself by setting RtsEnable to true.
This ought to take of the problem. If you still have trouble then use PortMon to spy on the way Realterm initializes the driver. Compare the commands you see against the commands that the SerialPort class sends. Make sure they are the same. In value, not in sequence.