I have a server and I need to simulate real network traffic. I've been asked to do this using a CAIDA Dataset. I have downloaded the public Dataset which can be found here:
CAIDA Public Dataset
I also need to rewrite the source ip address in the .pcap file to be the one of the server. I tried doing it the way it's described at the end of this page: tcprewrite wiki
I run:
tcprewrite --infile=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --outfile=oc48-mfn.dirA.20020814-160000.UTC.anon_rewrite.pcap --dstipmap=0.0.0.0/0:10.101.30.60 --enet-dmac=00:0c:29:00:b1:bd
And I get:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
Fatal Error: From ./plugins/dlt_hdlc/hdlc.c:dlt_hdlc_encode() line 255:
Non-HDLC packet requires --hdlc-address
So after some tries like this I finally run these to get an error free tcprewrite:
tcpprep --auto=bridge --pcap=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --cachefile=cache1.cache
Which gives:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
And then I run:
tcprewrite --infile=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --outfile=oc48-mfn.dirA.20020814-160000.UTC.anon_rewrite.pcap --dstipmap=0.0.0.0/0:10.101.30.60 --enet-dmac=00:0c:29:00:b1:bd --cachefile=cache1.cache --hdlc-control=0 --hdlc-address=0xBF
And I get:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
So it seems like a success, except the warning that shows up in every command.
I open the new .pcap file with tcpdump to check that the destination IP addresses have changed to the one of the server and it has been done.
So then I run tcpreplay:
tcpreplay -i ens160 --loop 5 --unique-ip oc48-mfn.dirA.20020814-160000.UTC.anon.pcap
And I run tcpdump on the server to see the traffic from the .pcap file, but the traffic looks like this:
13:30:50.194780 05:8c:55:6f:40:00 (oui Unknown) > 0f:00:08:00:45:00 (oui
Unknown), ethertype Unknown (0x3406), length 60:
0x0000: ed11 f484 7785 f477 0d79 0050 0487 007c ....w..w.y.P...|
0x0010: e7d5 d203 c32b 5010 27f7 aa51 0000 4854 .....+P.'..Q..HT
0x0020: 5450 0000 0000 0000 0000 0000 0000 TP............
I have tried the smallFlow.pcap from the sample captures of tcpreplay: Sample Captures
and it worked just fine.
So any suggestions on how to properly use the CAIDA .pcap files?
Your stated goal is "I need to simulate real network traffic", but you're using pcaps where "the payload has been removed from all packets" (per the CAIDA web page you linked to).
These two statements are in conflict with each other. All your packets are literally no larger then 48bytes which is merely enough for the TCP/IP header (and then even so, may not be sufficient in all cases). This is what the warning is telling you. You can't put the data back.
You'll need to find a new source of pcaps.
Related
I'm going mad with a stupid issue I can't solve.
During the testing of my Yocto project I always used connmactl in order to connect my board to the internet.
Now I am going to release the product but before releasing I am working on an “internet connection manager”
I guess I can’t use connmanctl anymore since it consist in an interactive command (isn’t it?) so I’m going to use directly wpa_supplicant.
In my script I edit wpa_supplicant.conf as follow:
root#localhost:~# cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
bgscan=""
network={
ssid="Obi_Lan_Kenobi"
psk="TheForceIsStrongWithThisOne"
}
After that I try to start wpa_supplicant with this command:
wpa_supplicant -B -i mlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf wext
as result of this command I get:
Successfully initialized wpa_supplicant
But if I try to ping google.com (or any other website) i seet that the network doesn’t work, In particular I get this message: ping: sendto: Network is unreachable
Everything is working under connmanctl, but not under wpa_supplicant.
The strange thing is that running iw command everything seems to be configurated in the right way:
root#localhost:~# iw dev mlan0 link
Connected to 56:0c:ff:37:1a:69 (on mlan0)
SSID: Obi_Lan_Kenobi
freq: 2412
RX: 32154 bytes (310 packets)
TX: 19436 bytes (128 packets)
signal: -38 dBm
rx bitrate: 1.0 MBit/s
tx bitrate: 72.2 MBit/s MCS 7 short GI
bss flags: short-preamble short-slot-time
dtim period: 2
beacon int: 100
I honestly can’t understand why.
Does anybody have a suggestion about that?
When I am writing message length is more than 1024B(mtu), it failed in softroce mode, pls help check why.
Using the standard tool ib_write_lat to test:
when ib_write_lat -s 1024 -n 5
When ib_write_lat -s 1025 -n 5, it fails.
My softroce version in in Red Hat Enterprise Linux Server release 7.4 (Maipo)
Is it a bug in softroce?
No it isn't a bug. I had similar problems.
What did you configure at your interface configuration?
I expect that you have a MTU of 1500 Bytes configured (or leaved the default value), this will result in RoCE using 1024. If you configure your interface MTU to 4200 you can use the ib_write_lat command with up to 4096 bytes.
InfiniBand protocol Maximum Transmission Unit (MTU) defines several fix size MTU: 256, 512, 1024, 2048 or 4096 bytes.
RoCE based application that uses RDMA that runs over Ethernet should take into account that the RoCE MTU is smaller than the Ethernet MTU. (normally 1500 is the default).
https://community.mellanox.com/docs/DOC-1447
I am trying to run short from Linux Device Drivers book, a driver which uses by default the parallel interface of a pc at io address base 0x378. I am specifically using the /dev/short0 device.
Quoting from the book
/dev/short0 writes to and reads from the 8-bit port
located at the I/O address base (0x378 unless changed at load time).
The write operation (on default behavior) essentially does that
while (count--) {
outb(*(ptr++), port);
wmb( );
}
The ptr variable holds a pointer to the data the user has requested to be written to the device. Only the last byte of course survives, as preceding bytes get overwritten. The read operation works similarly, by using inb instead of outb.
Quoting also from the book
If you choose to read from an output
port, you most likely get back the last value written to the port (this applies to the parallel interface and to most other digital I/O circuits in common use)
So when i do
$ echo -n "a" > /dev/short0
$ dd if=/dev/short0 bs=1 count=1 | od -t x1
as suggested in the book, i expect to get back the ascii code for 'a' in hex, but what i get is 0xff:
1+0 records in
1+0 records out
1 byte (1 B) copied, 0,000155485 s, 6,4 kB/s
0000000 ff
0000001
I have verified, adding some printks and using dmesg, that the relevant code of the driver actually gets executed and beyond that, i' m stuck. What are some possible reasons for this not working? Or where should i look next to find out why it is not working?
For what it matters, the io address range 0x378-0x37a is initially allocated from the parport module, so i rmmod it along with a few other modules that use parport before i load the short module. Finally, on my system uname -a gives
Linux Crete 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:31:42 UTC 2014 i686 i686 i686 GNU/Linux
I have written a program in golang to make request about 2000qps to different remote ip with local port randomly selected by linux, and close request immediately after connection established, but still encounter bind: address already in use error periodically
what I have done:
net.ipv4.ip_local_port_range is 15000-65535
net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_fin_timeout=30
above is sockstat:
sockets: used 1200 TCP: inuse 2302 orphan 1603 tw 40940 alloc 2325 mem 201
I don't figure it out why this error still there with kernel selecting available local port,will kernel return a port in use ?
This is a good answer from 2012:
https://serverfault.com/questions/342741/what-are-the-ramifications-of-setting-tcp-tw-recycle-reuse-to-1#434669
As of 2018, tcp_tw_recycle exists only in the sysctl binary, is otherwise gone from the kernel:
https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=tcp_tw_recycle&type=
tcp_tw_reuse is still in use as described in the above answer:
https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_ipv4.c#L128
However, while a TCP_TIMEWAIT_LEN is in use:
https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=TCP_TIMEWAIT_LEN&type=
the value is hardcoded:
https://github.com/torvalds/linux/blob/master/include/net/tcp.h#L120
and tcp_fin_timeout refers to a different state:
https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt#L294
One can relatively safely change the local port range to 1025-65535.
For kicks, if there were a situation where this client was talking to servers and network under my control, I would build a new kernel with a not-to-spec TCP_TIMEWAIT_LEN, and perhaps also fiddle with tcp_max_tw_buckets:
https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt#L379
But doing so in other circumstances- if this client is behind a NAT and talking to common public servers- will likely be disruptive.
i had already used the LIRC of the raspberry pi to record and use the IR signals of a samsung TV remote. the recording process was fine. i used this site for reference.But now i am unable to record the IR signals from a bluestar AC in the same method. After 1-3 dots (not always the same number), irrecord exits with the following error message:
irrecord: could not find gap.
irrecord: gap not found, can't continue
then i tried recording the AC remote signals using mode2 and routing it to a text file and manually modified the lircd.conf file to include the raw code as shown in the link
How to use irrecord with 2ms timing instead of the default 5ms?
but then i get the error that
irsend: command failed: SEND_ONCE /etc/lirc/lircd.conf KEY_POWER
irsend: unknown remote : "/etc/lirc/lircd.conf"
Possibly lircd doesn't accept all characters (e.g. slash) for the remote name. Try changing the:
name /etc/lirc/lircd.conf
in the .conf file to a different name (e.g. MY_REMOTE), then invoke the irsend like:
irsend SEND_ONCE MY_REMOTE KEY_POWER
The air conditioning controls send more bits than the television ones for example. You have to configure the lirc.conf header as:
begin remote
name IRAIR1
bits 48 #Configuración para 48 bits
flags SPACE_ENC
eps 30
aeps 100
header 3388 1678
one 430 1257
zero 430 412
ptrail 428
gap 108399
begin raw_codes
name KEY_POWER
3478 1676 500 1218 501 388
472 ..................................
end raw_codes
end remote
I think exactly what 48 bits are sending. This guy explains it: http://absurdlycertain.blogspot.com.es/2013/03/lirc-raspi-remote-control-configuration.html
Do not forget to restart the device, with me it does not work if I do not.
Sorry for my English