I am using STM32 microcontroller for sending UDP message. I did everything about microcontroller side. I followed this video:
https://www.youtube.com/watch?v=Kc7OHc7JfRg&list=RDCMUCkdqtSMnhYuMsJkyHOxiPZQ&index=4&ab_channel=ControllersTech
But while i am sending to UDP message to server, i am observing ECHO protocol instead of UDP protocol on WIRESHARK. Why it seems like ECHO? Normally i have to see UDP. Is there any different reason about this result?
WIRESHARK RESULT SCREEN
I applied UDP prossedure in STM32 microcontroller side. But i didn't see UDP protocol on WIRESHARK. I see ECHO Protocol.
Echo protocol is a protocol on top of UDP or TCP. Your implementation is using port 7 - which is the port reserved for the Echo protocol. Wireshark is smart enough to know this and therefore show the detected protocol as Echo. It is still UDP though as you can see from the detailed packet information in Wireshark.
Related
I have built a small UPnP framework on top of ASIO (https://think-async.com/Asio/), and the UDP listener joins the UPnP multicast address like so:
socket_.set_option(multicast::join_group(
address::from_string("239.255.255.250").to_v4(),
host_address_));
This works nicely, as I can receive UPnP multicast queries. However, when sending unicast UDP messages directly to ip_address:1900 the UDP listener does not receive anything. Is this to be expected?
Reading this question: Why can't I get UPnP unicast M-SEARCH to work instead of MultiCast M-SEARCH? it seems like it is supposed to work.
Maybe this is a quirk with ASIO?
Edit: Testing the multicast (cpp11) ASIO example, it all works as expected. I can send multicast and unicast messages, all get received. But this is with port 30001 and most other ports I've tested with. EXCEPT port 1900. If I use port 1900, only multicast messages get received.
Can it be that another application has bound to 1900 in non-reuse mode?
The problem is: Sometimes tcpdump sees that the receiving of a UDP packet is held back until the next incoming UDP packet, although the network tap device shows it goes without delay through the cable.
Scenary: My profinet stack on Linux (located in user space) has a cyclic connection where it receives and sends Profinet protocol packets every 4ms (via raw sockets). About every 30 ms it also receives UDP packets in another thread on a UDP socket and replies them immediately, according to that protocol. It's around 10% CPU load. Sometimes it seems such received UDP packets are stuck in the network driver. After 2 seconds the next UDP packet comes in and both, the missed UDP packet and that next one is received. There are no dropped packets.
My measuring:
I use tcpdump -i eth0 --time-stamp-precision=nano --time-stamp-type=adapter_unsynced -w /tmp/tcpdump.pcap to record the UDP traffic to a RAM disk file.
At the same time I use a network tap device to record the traffic.
Question:
How to find out where the delay comes from (or is it a known effect)?
(2. What does the timestamp (which tcpdump sets to each packet) tell me? I mean, which OSI layer refers it to, in other words: When is it taken?)
Topology: "embedded device with Linux and eth0" <---> tap-device <---> PLC. The program "tcpdump" is running on the embedded device. The tap device is listening on the cable. The actual Profinet connection is between PLC and embedded device. A PC is connected on the tap device to record what it is listening to.
Wireshark (via tap and tcpdump): see here (packet no. 3189 in tcpdump.pcap)
It was a bug in the freescale Fast Ethernet Driver (fec_main.c) which NXP has fixed by its awesome support now.
The actual answer (for the question "How to find out where the delay comes from?") is: One has to build a Linux with kernel tracing on, patch the driver code with kernel tracing and then analyse such tracing with the developer Linux tool trace-cmd. It's a very complicated thing but I'm very happy it is fixed now:
trace-cmd record -o /tmp/trace.dat -p function -l fec_enet_interrupt -l fec_enet_rx_napi -e 'fec:fec_rx_tp' tcpdump -i eth0 --time-stamp-precision=nano --time-stamp-type=adapter_unsynced -w /tmp/tcpdump.pcap
I've got a little client program that listens on an IPv6 multicast group (e.g. ff12::blah:blah%en0) for multicast packets that are sent out by a server. It works well.
The server would also like to sometimes send a unicast packet to my client (since if the packet is only relevant to one client there is no point in bothering all the other members of the multicast group with it). So my server just does a sendto() to my client's IP address and the port that the client's IPv6 multicast socket is listening on.
If my client is running under MacOS/X, this works fine; the unicast packet is received by the same socket that receives the multicast packets. Under Windows, OTOH, the client never receives the unicast packet (even though it does receive the multicast packets without any problems).
My question is, is it expected that a multicast-listener IPv6 UDP socket should also be able to receive unicast packets on that same port (in which case perhaps I'm doing something wrong, or have Windows misconfigured)? Or is this something that "just happens to work" under MacOS/X but isn't guaranteed, so the fact that it doesn't work for me under Windows just means I had the wrong expectations?
It should work fine. As long as you bind to IN6ADDR_ANY, then join the multicast groups, you should be able to send and receive unicast packets with no problem.
It's important to bind to IN6ADDR_ANY (or INADDR_ANY for IPv4) when using multicast. If you bind to a specific interface, this breaks multicast on Linux systems.
I am sending udp packets from one pc to other. I am observing the traffic on wireshark on the pc where I am receiving udp packets. One interesting thing I see is icmp packets appearing suddenly. Then they disappear and again appear in a cyclic manner. What can be the reason for this. Am I doing some thing wrong. And what bad effects can it have on my udp reception performance.
Please also find the attached wireshark figure taken from the destination pc.
The ICMP packets are created by the other host because the UDP port is not open. The ICMP packet includes the first X bytes of the packet that was dropped so the sender can read out which session was affected.
Using wxWidgets 2.8.9 on Mac/Win/Linux, how do I send a UDP broadcast message? Receiving is working using wxDatagramSocket, but it's not obvious to me how I would go about SENDING a UDP broadcast message.
In principle simply using wxSOCKET_BROADCAST in the socket flags should work (it's going to result in SO_BROADCAST being set for the socket).