/var/empty/sshd must be owned by root and not group or world-writable.
이란 메시지가 뜨면서 실행이 안 되는 경우가 있습니다
이럴 경우에는
/var/empty/sshd 디렉토리를 root로 소유자를 바꿔 주고 다시 sshd를 수행하면 됩니다
(chown root /var/empty/sshd/ )
tcpreplay has evolved quite a bit over the years. In the 1.x days, it merely read packets and sent then back on the wire. In 2.x, tcpreplay was enhanced significantly to add various rewriting functionality but at the cost of complexity, performance and bloat. Now in 3.x, tcpreplay has returned to its roots to be a lean packet sending machine and the editing functions have moved to tcprewrite.
To replay a given pcap as it was captured all you need to do is specify the pcap file and the interface to send the traffic out interface 'eth0':
# tcpreplay --intf1=eth0 sample.pcap
You can also replay the traffic at different speeds then it was originally captured. Some examples:
To replay traffic as quickly as possible:
# tcpreplay --topspeed --intf1=eth0 sample.pcap
To replay traffic at a rate of 10Mbps:
# tcpreplay --mbps=10.0 --intf1=eth0 sample.pcap
To replay traffic 7.3 times as fast as it was captured:
# tcpreplay --multiplier=7.3 --intf1=eth0 sample.pcap
To replay traffic at half-speed:
# tcpreplay --multiplier=0.5 --intf1=eth0 sample.pcap
To replay at 25 packets per second:
# tcpreplay --pps=25 --intf1=eth0 sample.pcap
To replay packets, one at a time while decoding it (useful for debugging purposes):
# tcpreplay --oneatatime --verbose --intf1=eth0 sample.pcap
Using the loop flag you can specify that a pcap file will be sent two or more times:
To replay the sample.pcap file 10 times:
# tcpreplay --loop=10 --intf1=eth0 sample.pcap
To replay the sample.pcap an infinitely or until CTRL-C is pressed:
# tcpreplay --loop=0 --intf1=eth0 sample.pcap
If the pcap files you are looping are small enough to fit in available RAM, consider using the --enable-file-cache option. This option caches each packet in RAM so that subsequent reads don't have to hit the slower disk. It does have a slight performance hit for the first iteration of the loop since it has to call malloc() for each packet, but after that it seems to improve performance by around 5-10%. Of course if you don't have enough free RAM, then this will cause your system to swap which will dramatically decrease performance.
Another useful option is --quiet. This suppresses printing out to the screen each time tcpreplay starts a new iteration. This can have a dramatic performance boost for systems with slower consoles.
By utilizing tcpprep cache files, tcpreplay can split traffic between two interfaces. This allows tcpreplay to send traffic through a device and emulate both client and server sides of the connection, thereby maintaining state. Using a tcpprep cache file to split traffic between two interfaces (eth0 & eth1) with tcpreplay is simple:
# tcpreplay --cachefile=sample.prep --intf1=eth0 --intf2=eth1 sample.pcap
The --verbose flag turns on basic tcpdump decoding of packets. If you would like to alter the way tcpreplay invokes tcpdump to decode packets, then you can use the --decode flag. Note: Use of the --verbose flag is not recommended when performance is important. Please see the tcpdump(1) man page for options to pass to the --decode flag.
tcpreplay now supports two methods for creating delays between two packets:
The important thing to understand is that nanosleep() isn't always very accurate. Linux 2.4 and 2.6 kernels for example are accurate to 10ms, hence any packet may be sent 10ms too soon or late. The result is that nanosleep() may not provide the accuracy reqiured for all situations. Specifying the --accurate flag to tcpreplay switches to using gettimeofday() in a loop. The result is much better accuracy (~1ms), but higher CPU utilization since tcpreplay isn't sleeping between packets.
Of course neither method is really sufficient for all situations. If you wanted to send 4,000 packets per second, that would require sending a packet every .25ms which would require a higher resolution timer then either method provides. See ticket #41 for more details.
Regardless of the size of physical memory, UNIX kernels will only allocate a static amount for network buffers. This includes packets sent via the "raw" interface, like with tcpreplay. Most kernels will allow you to tweak the size of these buffers, drastically increasing performance and accuracy.
NOTE: The following information is provided based upon my own experiences or the reported experiences of others. Depending on your hardware and specific hardware, it may or may not work for you. It may even make your system horribly unstable, corrupt your harddrive, or worse.
NOTE: Different operating systems, network card drivers, and even hardware can have an effect on the accuracy of packet timestamps that tcpdump or other capture utilities generate. And as you know: garbage in, garbage out.
NOTE: If you have information on tuning the kernel of an operating system not listed here, please send it to me so I can include it.
The following is known to apply to the 2.4.x series of kernels and may work with 2.6.x (I haven't bothered to try yet). If anyone has any information regarding other kernel versions, please let me know. By default Linux's tcpreplay performance isn't all that stellar. However, with a simple tweak, relatively decent performance can be had on the right hardware. By default, Linux specifies a 64K buffer for sending packets. Increasing this buffer to about half a megabyte does a good job:
echo 524287 >/proc/sys/net/core/wmem_default echo 524287 >/proc/sys/net/core/wmem_max echo 524287 >/proc/sys/net/core/rmem_max echo 524287 >/proc/sys/net/core/rmem_default
On one system, we've seen a jump from 23.02 megabits/sec (5560 packets/sec) to 220.30 megabits/sec (53212 packets/sec) which is nearly a 10x increase in performance. Depending on your system and capture file, different numbers may provide different results.
*BSD systems typically allow you to specify the size of network buffers with the NMBCLUSTERS option in the kernel config file. Experiment with different sizes to see which yields the best performance. See the options(4) man page for more details.
redhat 계열에서는(redhat, Fedora, Red Hat Enterprise Linux, CentOS등) 해당하는 배포판의 버전을 /etc/redhat-release에 해당하는 배포판의 버전이 있습니다
간혹 하위 버전의 배포판으로 만들어진 소스가 상위 버전의 배포판에서도 컴파일이 되지만
지원하지 않는 배포판이라고 컴파일이 안 될 경우에는 이 파일에 해당하는 하위 버전의 배포판으로 변경해 주면 됩니다
참고로 아래는 자주 쓰는 redhat 9 이랑 Fedora에서 redhat-release입니다
Fedora Core release 1 (Yarrow)
Fedora Core release 2 (Tettnang)
Fedora Core release 3 (Heidelberg)
Fedora Core release 4 (Stentz)
Fedora Core release 5 (Bordeaux)
Fedora Core release 6 (Zod)
Fedora Core release 7 (Moonshine)
Red Hat Linux release 9 (Shrike)