search

emmericp / MoonGen

MoonGen is a fully scriptable high-speed packet generator built on DPDK and LuaJIT. It can saturate a 10 Gbit/s connection with 64 byte packets on a single CPU core while executing user-provided Lua scripts for each packet. Multi-core support allows for even higher rates. It also features precise and accurate timestamping and rate control.
MIT License
1.05k stars 235 forks source link

About Caida pcap #205

Open Scottbtang opened 7 years ago

Scottbtang commented 7 years ago

I use the replay-pcap.lua script to send the pcap file which download from CAIDA. But the terminal always print a error "unsupported link layer type", like this: [INFO] Found 2 usable devices: Device 0: 14:02:EC:89:ED:54 (Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection) Device 1: 14:02:EC:89:ED:55 (Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection) PMD: ixgbe_dev_link_status_print(): Port 0: Link Down [INFO] Waiting for devices to come up... [INFO] Device 0 (14:02:EC:89:ED:54) is up: 10000 MBit/s [INFO] 1 device is up. [FATAL] Lua error in task replay /root/dpdkovs/MoonGen/build/../libmoon/lua/pcap.lua:160: unsupported link layer type

So what should I do to fix this problem ? Thanks very much

emmericp commented 7 years ago

The error indicates that the pcap file claims to not contain ethernet packets but something else. The field is probably just 0, i'll change this to a warning later today.

Also checking if we have these traces somewhere so i can test it myself.

gkatsikas commented 7 years ago

As far as I recall, the CAIDA pcap traces contain raw IP packets (no Ethernet header). This is likely the reason you get this error. It would be nice if you could extend the script to account for such traces by e.g., prepending each packet with a fake Ethernet header.

Scottbtang commented 7 years ago

Thanks for getting back to me. So as the CAIDA pcap traces don't have the Ethernet header, I am not sure whether the Moongen has the ability to replay the traces (the trace without any modification), or the only way to solve the problem is to prepend a fake Ethernet header for each packet?

emmericp commented 7 years ago

looks like we don't have access the the caida traces here, i've requested access.

but in general the best way to do this is with a small patch in the pcap library modifying the offset where the packet is copied to. we can then use a pre-filled mempool with a header. i'll see what i can do, but probably not before tomorrow

emmericp commented 6 years ago

@scholzd you recently successfully replayed this trace, can you PR your changes?

scholzd commented 6 years ago

No, not a PR, I only hardcoded the offsets: https://github.com/scholzd/libmoon/commit/a79a908d2156777dad4dc87e507f21e007ede5cb

wujiahao15 commented 1 year ago

According to ACC-Turbo, using tcprewrite to add ethernet headers helps me solve the problem.

tcprewrite --dlt=enet --enet-dmac=00:11:22:33:44:55 --enet-smac=66:77:88:99:AA:BB --infile=equinix-nyc.dirA.20180315-125910.UTC.anon.pcap --outfile=fixed_demo1.pcap

Notice

$ tcprewrite --version
tcprewrite version: 4.3.4 (build git:v4.3.4)
Copyright 2013-2018 by Fred Klassen <tcpreplay at appneta dot com> - AppNeta
Copyright 2000-2012 by Aaron Turner <aturner at synfin dot net>
The entire Tcpreplay Suite is licensed under the GPLv3
Cache file supported: 04
Not compiled with libdnet.
Compiled against libpcap: 1.9.1
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Fragroute engine: disabled