I wanted to send data to the loop-back IP address 127.0.0.1 using the ping program.
$ping 127.0.0.1 "my data" and wanted to see it in the kernel space.
if anyone has some idea please respond to me
Use ping's -p option:
-p pattern
You may specify up to 16 ``pad'' bytes to fill out the packet you send.
This is useful for diagnosing data-dependent problems in a network.
For example, -p ff will cause the sent packet to be filled with all ones.
Related
I want to log and display a stream of data arriving at a serial port in hex with timestamps and all non printable characters (particularly any XON XOFF characters). don't need to transmit anything on the Tx port, it is not connected.
Been trying to use stty to set port parameters and socat to log but having trouble.
using /dev/null socat just exits without any doing any thing, using -u and /dev/null as second address doesn't show or log anything, using a PTY as second address works for a while but then hangs - I guess the PTY fills up and block with nothing reading it.
Thanks for any help.
Dear wireshark experts,
I got a tshark output image on ubuntu 16.04 after I ran the command curl www.baidu.com, as shown below. But I can't tell you the story from the output lines, because I can't find any mathematical relationships betweens the lines.
Could someone explain the meaning of each line, especially the field Ack and Win?
So appreciated in advance!
That's not related to tshark/wireshark, but generally to TCP protocol:
ACK (and SYN) are tcp flags being set during connection establishment
Win is also tcp parameter. see Window size
FrameNumber Timestamp Source-IP-Address -> Destination-IP-Address Protocol TCP-Source-Port TCP-Destination-Port [TCP-FLAGS] Protocol-Specific-Description
SYN/ACK/WIN are related to the TCP protocol which is used for reliable transmission on top of the unreliable IP network
I ran into a puzzling problem when trying to receive a multicast IP (of a video from 239.193.140.11:1234).
When $tcpdump dst 239.193.140.11 -w capturedData.pcap, the packets are captured correctly.
eg, 11:05:25.357138 IP 192.168.34.34.46192 > 239.193.140.11.1234: UDP, length 1328
This means that my machine is receiving the multicast IP packets.
However, when $iftop -i any is run, iftop doesn't show any bandwidth from 239.193.140.11. Furthermore, when I try to capture the multicast packets with ffmpeg: $ffmpeg -i udp://239.193.140.11:1234?localaddr=192.168.34.34, no packets are captured.
Why is there a discrepancy between what tcpdump and iftop shows, and how to resolve it so that ffmpeg can capture correctly?
Looks like Reverse Path Filter (rp_filter) is enabled, which is rejecting the packets.
From my experience in a PROD environment, I can say that disabling the rp_filter enabled my client/listener application to pick up the packets. Use the below command to disable rp_filter:
$echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
In the above, replace 'eth0' with the interface receiving the multicast if other than eth0, or alternately edit the rp_filter file and set the value to '0'
I need to exercise some hardware by sending a network traffic with it. While it is doing it I will probing some of the lines with an oscilloscope. Need to verify signaling. The problem is that I won't be able to connect to any server during the test. Many reasons for that, one of each is that hardware isn't complete yet.
Does anyone know if there is a away to generate network traffic with iperf without using a server? All I need is to just send some data, don't need to know if it was received. If there isn't can someone point me to a tool that can do that.
iperf UDP will do it you just need to make sure there is an arp entry for the destination (enter it manually) or use a multicast destination which doesn't require ARP, e.g. iperf -u -c 239.1.1.1 -b 10M
I am running some data throughput tests by sending UDP packets using iperf through a VM that does some sort of processing on those packets.
My application runs in promiscuous mode, so it will pick up all packets.
I saw my application drop some packets, but my application counters show that it was not due to any slowdown or failures.
I put some logs in my application and they suggested that the ethernet frame itself may be corrupted.
I was also running tcpdump on the vnics of both the iperf machine and my packet processor but these packets never showed up in the traces. I was hoping to see corrupted packets appear in the traces.
The commands looked like this:
tcpdump -i vnet11 -C 100 -w iperf.pcap
tcpdump -i vnet7 -C 100 -w sgi.pcap
My doubt is, if the ethernet frame is itself corrupted and the destination MAC itself does not match the MAC address of vnet7 or vnet11, will tcpdump capture those packets?
Edit:
It just struck me that if Ethernet frame itself was corrupted which caused destination MAC to mismatch, then the linuxbridge won't send that packet to my packet processor's vnet interface in the first place. So tcpdump does not have anything to capture here. Please ignore this question.
In fact, if the problem is a corrupt Ethernet frame, you will not see it at all. Your network card will discard the frame and your sniffer will never see it.
Running in promiscuous mode will normally disabled the MAC filtering on your network card so that the sniffer will see all packets, regardless of the destination MAC. However, you cannot see packets that are not sent to the NIC (obviously), so in a switched environment, unless you take additional steps to either attack the switch or configure a span or mirror ports, you will only see broadcasts and frames that are destined for a MAC on your system.
Virtual Machines can complicate this further. Different virtualization solutions handle this in different ways. In some, for instance, the administrator can choose to configure whether or not frames that do not match the host address are delivered to the VM, effectively making promiscuous mode moot.