I have a network of Lrwpan devices in NS3 and I want to make some nodes operate as sniffers. I enabled promiscuous mode in PCAP files but I want also to process the information that are contained in these packets. How should I get the actual content of the packet in NS3 so that I can do some calculations?
For example, if A -- B -- C is my topology and B is in RX/TX range of A and C, I want to enable B sniff packets of neighbors. Is this possible to do it in NS3? I don't want to see packets only in pcap file.
Edit: I found the SetPromiscuousMode() from MAC layer in Netdevice and enters promiscuous mode. However, is not able to send any packet, just receives. I want to enable TX and RX packets. Is that possible?
Related
If the datagram bigger than MTU， 2 layer switch will drop it? Dose 2 layer switch can report a ICMP? If not report ICMP, how can I determine the data size to pass the switch successfully?
If the datagram bigger than MTU， 2 layer switch will drop it?
Yes. A switch does not forward frames larger than the (configured) maximum size and drops them. For standard Ethernet, that's 1500 bytes payload plus 18 bytes L2 overhead. Note that MTU is an L3 term referring to the maximum packet size that an underlying network can transport.
Does 2 layer switch report a ICMP?
No. A layer-2 switch generally sends no ICMP messages nor is there an ICMP message to report oversized frames in L2.
A layer-3 switch used as gateway should return an ICMP Fragmentation required when the destination network's MTU does not admit the IP packet without fragmentation and its DF bit is set or IPv6 is used. For IPv4 without DF, the gateway just fragments the packet.
If not report ICMP, how can I determine the data size to pass the switch successfully?
On an unmanaged switch, see above for the maximum standard size. A few support jumbo frames, check their documentation. On some managed switches you can configure the maximum frame size globally or by VLAN. Methods and syntax vary.
I'm implementing a virtual instrument on STM32 (STM32F103x). Like a normal "hello world", I tried to start with the simplest MIDI message, sending NOTE-ON MIDI message in a loop to see if it works.
I send MIDI NOTE-ON message for every 500ms, only NOTE-ON message in a forever loop, but it not works. Is there any other MIDI message must be sent to make MIDI works? Like some initialize message?
Based on MIDI 1.0 spec, I finish my code on STM32 by sending MIDI message via USART interface.
Then use a logical analyzer, I confirmed my MIDI message is fully match the MIDI 1.0 spec. At least I believe it correct, no issue. 31250 baud rate, 1 start bit, 1 stop bit, one status message 0x92 followed by two data bytes 0x48 and 0x7F, LSB first.
Below is the NOTE-ON message captured by the logical analyzer on TX line of URAT interface. I continue send the same 3 bytes for every 500ms.
The totally time for those 3 bytes are 960 microseconds also match MIDI 1.0 spec mentioned value.
Then, based on "(CA-033) MIDI 1.0 Electrical Specification Update [2014]", I buy one 5 PIN MIDI OUT jack, connect the URAT TX line to PIN-5 through a 10 Ohm resister, connect 3.3V power to Pin-4 through a 33 Ohm resister, PIN-2 and Jack shield connect to GND. Other optional parts (buffer for Rc, ferrite beads) are not used.
However, when I use a USB-MIDI wire connect my MIDI OUT jack to my PC, nothing happen. The USB-MIDI wire has two LED indicators , one for power another for MIDI signal. After connect, the power LED is light, but the MIDI signal LED never light.
I tried to use logical analyzer to analysis PIN-5 of my MIDI OUT jack, the MIDI message byte are totally same with URAT TX line, and every 500ms one NOTE-ON message. However, it never works.
I also tried to create my own PCB with Dream SAM2695 by follow the SAM2695 Evaluation Boards. Then connect the URAT TX directly to MIDI_IN pin of SAM2695, it still no response. Since I have no confidence on my manual soldering PCB, not sure if the PCB itself has issue cause it no response. So I buy a USB-MIDI wire, but the result as I mentioned above, still no response.
======= Apr.26.2021 Update =========
Based on comments, have tried to check the output of the optocoupler.
Before do this check, I bought several BSS138 to transform the MIDI signal to 5V single use below circuit (of course change the resisters near MIDI JACK pin to 220 Ohm as the spec)
After this change I measured voltage of the 5V URAT TX, it show as 4.8+ V, and Logical Analyzer show correct MIDI note on message of this new 5V MIDI signal. However, it still not works.
The only left troubleshooting method for me is measure the output of the optocoupler on this USB-MIDI wire. But I didn't find an optocoupler on this MIDI USB wire PCB. There even do not have any one component has 4 pins on the PCB (based on my understanding, an optocoupler need at least 4 pins).
There only have one main chip on the PCB, it is possible that the optocoupler is embedded in that chip? Since the pin are too small I failed to connect my logical analyzer to those pin to check.
Description
I'm busy writing a high frequency UDP server with Go. I'd estimate at least 1000 packets/second both ways.
However as the size of data I'm sending over the UDP socket grew, I eventually ran into the follow error: read udp 127.0.0.1:1541->127.0.0.1:9737: wsarecv: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.
I eventually just grew the size of the buffers I was reading from and writing into as follows:
buffer := make([]byte, 64 * 1024 * 1024) // used to just be 1024
l, err := s.socketSim.Read(buffer)
This worked fine and I stopped getting the error... However then I can across two functions inside the net package:
s.socketSim.SetWriteBuffer(64 * 1024 * 1024)
s.socketSim.SetReadBuffer(64 * 1024 * 1024)
I learned that these two act on the operating system's transmit buffer
Question
Do I even care to set the operating system buffer size and why? How does the size on the application buffer impact the size of the operating system buffer? Should they always be the same and how big should/can they become?
First, not only do you have an MTU size for each interface on your device and whatever destination you're send/recving from, but there is also an MTU size for each device in between. For this reason, as others have mentioned, you might want to use what is generally accepted for MTU since you might not control every device in the data route. In the case of UDP, MTU really just means how big a datagram can be before fragmenting.
Second, you almost certainly want your SND/RCV buffers to be larger than the MTU. These are kernel buffers which hold on to data when you're not ready to receive them. A larger UDP RCV buffer means that the kernel will buffer more packets for you instead before dropping them into the abyss. Maybe you have some non-trivial work to do for each packet. Depending on the bitrate, you might want a larger or smaller kernel buffer.
Finally, you're using UDP. There is no guarantee that you'll receive packets in order or at all. Any router in between you and a peer could decide to drop the packet for any reason. Since you're using UDP, you should prepare for dropped and out-of-order packets. You also might need some sort of retransmission mechanism, which further complicates things.
Or you might consider using TCP if dropped packets are unacceptable, knowing that timing is indeterminate.
If you're on linux, you can see current buffer sizes in /proc/sys/net. Usually the kernel will double what you ask for.
Also, you can tune your buffer size by watching for packet drops in /proc/net/udp. If you see drops, you might want to make your rcv buffer bigger, especially if the data is bursty and the processing intensive. If you're data is coming in at a consistent rate and you're still dropping packets, then you aren't processing them fast enough.
I’m trying to use Matlab to control 8-channel perfusion device. The manual said that on the back of the device there are 8 BNC type connection ports for transmitting TTL signal to control the on/off of the 8 channels, respectively. How to use Matlab to control these 8 BNC ports to send TTL input? What accessories should I purchase?
There is also another single input port--analog input. The manual said it is an BNC connector to apply an analog signal to switch individual channels using Analog Discriminator. By varing the ampitude of signal, different channels will be triggered. Can Matlab control this analog input?
Thanks
My FPGA is continuously sending UDP packets on network using 10/100/1000 Mbps Ethernet. I am using Wireshark to capture the packets directly to a .pcap file & then extract & display UDP data in Matlab GUI. FPGA kit is connected to a 1 Gbps switch and then to PC.
Initially i tried using Matlab's built in UDP object instead of .pcap files but using that i was facing packet drop issue at high BW (>1 Mbps) and was only able to achieve drop free reception for very low BW around 110 kbps. That was not acceptable for my case. A link to the problem is given below:
Incorrect UDP data reception in Matlab
Based on these problems i moved towards using Wireshark. I use wireshark to create multiple .pcap files (1 Mb) of UDP data and then start extracting UDP data from these files in Matlab. A link also guided towards this approach i.e. writing packets directly to file(High speed UDP receiver in MATLAB
).
The problem is that i am getting some packets dropped at random intervals. The problem is very frequent when operating at High Ethernet BW - 220 Mbps. So i reduced my BW to around <50 Mbps still i get some packet drops. I tried using some of the tips provided by Wireshark (http://wiki.wireshark.org/Performance) for optimizing performance but still the issue persists.
This seems to be issue with memory as far as i have understood.
Some details about the design:
UDP Data Size = 64 Bytes
Ethernet Frame Size = 110 Bytes
PCAP File Size = 1 Mb
Wireshark Buffer Size = 1 Gb
Please guide me towards a possible solution.
Regards,
Sameed
I would suggest a larger file size may provide efficiency savings, something like 64MB. Also agree with Slava's suggestion - tcpdump is more efficient/robust than the wireshark GUI.
Try writing to a ram disk
[Padding]