* [LTP] [RFC PATCH 1/1] doc: Remove network stress related doc
@ 2017-09-11 20:00 Petr Vorel
2017-10-03 8:50 ` Petr Vorel
0 siblings, 1 reply; 3+ messages in thread
From: Petr Vorel @ 2017-09-11 20:00 UTC (permalink / raw)
To: ltp
File doc/network_stress.txt is outdated and duplicite (network stress
related docs is in each directory in 00_Descriptions.txt files).
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
IMHO it doesn't make sense to have duplicity in docs.
Next step could be rename 00_Descriptions.txt files to something reasonable (README ?).
---
doc/network_stress.txt | 531 -------------------------------------------------
1 file changed, 531 deletions(-)
delete mode 100644 doc/network_stress.txt
diff --git a/doc/network_stress.txt b/doc/network_stress.txt
deleted file mode 100644
index fb936ef79..000000000
--- a/doc/network_stress.txt
+++ /dev/null
@@ -1,531 +0,0 @@
-interface
----------
-if4-updown
- Verify the IPv4 connectivity is not broken when the interface is
- upped and downed many times
- test01 - by ifconfig command
- test02 - by ip command
-
-if4-addr-change
- Verify the IPv4 connectivity is not broken when the IPv4 address
- is changed many times
- test01 - by ifconfig command
-
-if4-alias-adddel01
- Verify the IPv4 connectivity is not broken when an IPv4 alias is
- added, then deleted many times
- test01 - by `ifconfig add' command
- test02 - by `ifconfig ethn:n' command
- test03 - by ip command
-
-if4-alias-addlarge01
- Verify the IPv4 connectivity is not broken when a large number of
- IPv4 alias is created
- test01 - by `ifconfig add' command
- test02 - by `ifconfig ethn:n' command
- test03 - by ip command
-
-if4-route-adddel01
- Verify the IPv4 connectivity is not broken when an IPv4 route is
- added, then deleted many times
- test01 - by route command
- test02 - by ip command
-
-if4-route-addlarge01
- Verify the IPv4 connectivity is not broken when a large number of
- IPv6 route is created
- test01 - by route command
- test02 - by ip command
-
-if4-mtu-change01
- Verify the IPv4 connectivity is not broken when the mtu of interface
- is changed many times every 5 seconds
- test01 - by ifconfig command
- test02 - by ip command
-
-if6-updown
- Verify the IPv6 connectivity is not broken when the interface is
- upped and downed many times
- test01 - by ifconfig command
- test02 - by ip command
-
-if6-alias-adddel01
- Verify the IPv6 connectivity is not broken when an IPv6 alias is
- added, then deleted many times
- test01 - by ifconfig command
- test02 - by ip command
-
-if6-alias-addlarge01
- Verify the IPv6 connectivity is not broken when a large number of
- IPv6 alias is created
- test01 - by ifconfig command
- test02 - by ip command
-
-if6-route-adddel01
- Verify the IPv6 connectivity is not broken when an IPv6 route is
- added, then deleted many times
- test01 - by route command
- test02 - by ip command
-
-if6-route-addlarge01
- Verify the IPv6 connectivity is not broken when a large number of
- IPv6 route is created
- test01 - by route command
- test02 - by ip command
-
-if6-mtu-change01
- Verify the IPv6 connectivity is not broken when the mtu of interface
- is changed many times every 5 seconds
- test01 - by ifconfig command
- test02 - by ip command
-
-routing table
--------------
-route4-change-dst
- Verify the kernel is not crashed when the destination of an IPv4 route
- is changed frequently
- test01 - by route command
- test02 - by ip command
-
-route4-change-gw
- Verify the kernel is not crashed when the gateway of an IPv4 route is
- changed frequently
- test01 - by route command
- test02 - by ip command
-
-route4-change-if
- Verify the kernel is not crashed when the interface of an IPv4 route is
- changed frequently
- test01 - by route command
- test02 - by ip command
-
-route4-redirect01
- Verify the kernel is not crashed when the IPv4 route is modified by
- ICMP Redirects frequently
-
-route4-ifdown
- Verify the kernel is not crashed when IPv4 route is add then it is
- deleted by the interface down
- test01 - by route command and ifconfig command
- test02 - by ip command
-
-route4-rmmod
- Verify the kernel is not crashed when IPv4 route is add then it is
- deleted by the removing network driver
- test01 - by route command
- test02 - by ip command
-
-route6-change-dst
- Verify the kernel is not crashed when the destination of an IPv6 route
- is changed frequently
- test01 - by route command
- test02 - by ip command
-
-route6-change-gw
- Verify the kernel is not crashed when the gateway of an IPv6 route is
- changed frequently
- test01 - by route command
- test02 - by ip command
-
-route6-change-if
- Verify the kernel is not crashed when the interface of an IPv6 route is
- changed frequently
- test01 - by route command
- test02 - by ip command
-
-route6-redirect01
- Verify the kernel is not crashed when the IPv6 route is modified by
- ICMP Redirects frequently
-
-route6-ifdown
- Verify the kernel is not crashed when IPv6 route is add then it is
- deleted by the interface down
- test01 - by route command and ifconfig command
- test02 - by ip command
-
-route6-rmmod
- Verify the kernel is not crashed when IPv6 route is add then it is
- deleted by the removing network driver
- test01 - by route command
- test02 - by ip command
-
-
-broken_ip
----------
-broken_ip4-version01
- Verify that the kernel is not crashed with receiving a large number of
- IPv4 packets that have wrong value in version field
-
-broken_ip4-ihl01
- Verify that the kernel is not crashed with receiving a large number of
- IPv4 packets that have wrong value in the header length field
-
-broken_ip4-totlen01
- Verify that the kernel is not crashed with receiving a large number of
- IPv4 packets that have wrong value in the total length field
-
-broken_ip4-fragment01
- Verify that the kernel is not crashed with receiving a large number of
- IPv4 packets that have wrong fragment information
-
-broken_ip4-protcol01
- Verify that the kernel is not crashed with receiving a large number of
- IPv4 packets that have wrong value in the protocol field
-
-broken_ip4-checksum01
- Verify that the kernel is not crashed with receiving a large number of
- IPv4 packets that have wrong value in the checksum field
-
-broken_ip4-dstaddr01
- Verify that the kernel is not crashed with receiving a large number of
- IPv4 packets whose destination address is wrong
- (destination MAC address is correct)
-
-broken_ip6-version01
- Verify that the kernel is not crashed with receiving a large number of
- IPv6 packets that have wrong value in version field
-
-broken_ip6-plen01
- Verify that the kernel is not crashed with receiving a large number of
- IPv6 packets that have wrong value in the payload length field
-
-broken_ip6-nexthdr01
- Verify that the kernel is not crashed with receiving a large number of
- IPv6 packets that have wrong value in the next header field
-
-broken_ip6-dstaddr01
- Verify that the kernel is not crashed with receiving a large number of
- IPv6 packets whose destination address is wrong (destination MAC
- address is correct)
-
-
-icmp
-----
-uni-basic
- Verify that the kernel is not crashed with receiving and sending various
- size of ICMP message
-
-multi-diffip
- Verify that the kernel is not crashed with receiving and sending various
- size of ICMP message at the different IP address(alias) simultaneously
-
-multi-diffnic
- Verify that the kernel is not crashed with receiving and sending various
- size of ICMP message at different NIC simultaneously
-
- *) Each section have 7 testcases for IPv4 and 7 testcases for IPv6
- test01 - without IPsec / IPComp
- test02 - IPsec [ AH / transport ]
- test03 - IPsec [ AH / tunnel ]
- test04 - IPsec [ ESP / transport ]
- test05 - IPsec [ ESP / tunnel ]
- test06 - IPComp [ transport ]
- test07 - IPComp [ tunnel ]
-
-
-udp
----
-uni-basic
- Verify that the kernel is not crashed with receiving and sending UDP
- datagram with the following conditions
-
-multi-diffip
- Verify that the kernel is not crashed with receiving and sending UDP
- datagram at the different IP addresses(aliases)
-
-multi-diffnic
- Verify that the kernel is not crashed with receiving and sending UDP
- datagram at the different NICs with the following conditions
-
-multi-diffport
- Verify that the kernel is not crashed with receiving and sending UDP
- datagram at many different ports with the following conditions
-
- *) Each section have 7 testcases for IPv4 and 7 testcases for IPv6
- test01 - without IPsec / IPComp
- test02 - IPsec [ AH / transport ]
- test03 - IPsec [ AH / tunnel ]
- test04 - IPsec [ ESP / transport ]
- test05 - IPsec [ ESP / tunnel ]
- test06 - IPComp [ transport ]
- test07 - IPComp [ tunnel ]
-
-
-tcp
----
-uni-basic
- Verify that the kernel is not crashed by a TCP connection
-
-uni-smallsend
- Verify that the kernel is not crashed by a connection disabling
- NAGLE algorithm
-
-uni-winscale
- Verify that the kernel is not crashed by a connection enabling TCP
- window scaling
-
-uni-tso
- Verify that the kernel, whose NIC supports TCP Segmentation Offload,
- is not crashed by a connection enabling TCP window scaling
-
-uni-pktlossdup
- Verify that the kernel is not crashed by a TCP connection on an
- unreliable network (Namely, some of the packets are lost, some of
- them is duplicated.)
-
-uni-dsackoff
- Verify that the kernel, when the Duplicate SACK support is off, is not
- crashed by a TCP connection on an unreliable network (Namely, some of
- the packet is lost, some of them is duplicated).
-
-uni-sackoff
- Verify that the kernel, when both SACK and Duplicate SACK supports are
- off, is not crashed by a TCP connection on an unreliable network
- (Namely, some of the packet is lost, some of them is duplicated).
-
-multi-sameport
- Verify that the kernel is not crashed with multiple connection to the
- same ports
-
-multi-diffport
- Verify that the kernel is not crashed with multiple connection to the
- different ports
-
-multi-diffip
- Verify that the kernel is not crashed with multiple connection to the
- different IP address(alias)
-
-multi-diffnic
- Verify that the kernel is not crashed with multiple connection to the
- different NIC
-
- *) Each section have 14 testcases for IPv4 and 14 testcases for IPv6
- test01 - without IPsec / IPComp
- test02 - IPsec [ AH / transport ]
- test03 - IPsec [ AH / tunnel ]
- test04 - IPsec [ ESP / transport ]
- test05 - IPsec [ ESP / tunnel ]
- test06 - IPComp [ transport ]
- test07 - IPComp [ tunnel ]
- test08 - delayed network - without IPsec / IPComp
- test09 - delayed network - IPsec [ AH / transport ]
- test10 - delayed network - IPsec [ AH / tunnel ]
- test11 - delayed network - IPsec [ ESP / transport ]
- test12 - delayed network - IPsec [ ESP / tunnel ]
- test13 - delayed network - IPComp [ transport ]
- test14 - delayed network - IPComp [ tunnel ]
-
-
-multicast
----------
-mcast4-grpope01
- Verify that the kernel is not crashed when joining lots of IPv4
- multicast groups on a single socket
-
-mcast4-grpope02
- Verify that the kernel is not crashed when joining lots of IPv4
- multicast groups on lots of sockets
-
-mcast4-grpope03
- Verify that the kernel is not crashed when joining and leaving the same
- IPv4 multicast group on multiple sockets lots of times
-
-mcast4-grpope04
- Verify that the kernel is not crashed when joining and leaving the same
- IPv4 multicast group with the different source filter on multiple
- sockets lots of times
-
-mcast4-pktfld01
- Verify that the kernel is not crashed when joining a IPv4 multicast
- group a single socket, then receiving a large number of UDP packets
- at the socket
-
-mcast4-pktfld02
- Verify that the kernel is not crashed when joining plural IPv4
- multicast groups on separate sockets, then receiving a large number
- of UDP packets at the each socket
-
-mcast4-queryfld01
- Verify that the kernel is not crashed when joining an IPv4 multicast
- group on a single socket, then receiving a large number of General Query
-
-mcast4-queryfld02
- Verify that the kernel is not crashed when joining an IPv4 multicast
- group on a single socket, then receiving a large number of Multicast
- Address Specific Query
-
-mcast4-queryfld03
- Verify that the kernel is not crashed when joining an IPv4 multicast
- group on a single socket, then receiving a large number of Multicast
- Address and Source Specific Query
-
-mcast4-queryfld04
- Verify that the kernel is not crashed when joining plural IPv4 multicast
- groups on separate socket, then receiving a large number of General
- Query
-
-mcast4-queryfld05
- Verify that the kernel is not crashed when joining joining plural IPv4
- multicast groups on separate socket, then receiving a large number of
- Multicast Address Specific Query
-
-mcast4-queryfld06
- Verify that the kernel is not crashed when joining joining plural IPv4
- multicast groups on separate socket, then receiving a large number of
- Multicast Address and Source Specific Query
-
-mcast6-grpope01
- Verify that the kernel is not crashed when joining lots of IPv6
- multicast groups on a single socket
-
-mcast6-grpope02
- Verify that the kernel is not crashed when joining lots of IPv6
- multicast groups on lots of sockets
-
-mcast6-grpope03
- Verify that the kernel is not crashed when joining and leaving the same
- IPv6 multicast group on multiple sockets lots of times
-
-mcast6-grpope04
- Verify that the kernel is not crashed when joining and leaving the same
- IPv6 multicast group with the different source filter on multiple
- sockets lots of times
-
-mcast6-pktfld01
- Verify that the kernel is not crashed when joining a IPv6 multicast
- group a single socket, then receiving a large number of UDP packets
- at the socket
-
-mcast6-pktfld02
- Verify that the kernel is not crashed when joining plural IPv6
- multicast groups on separate sockets, then receiving a large number
- of UDP packets at the each socket
-
-mcast6-queryfld01
- Verify that the kernel is not crashed when joining an IPv6 multicast
- group on a single socket, then receiving a large number of General Query
-
-mcast6-queryfld02
- Verify that the kernel is not crashed when joining an IPv6 multicast
- group on a single socket, then receiving a large number of Multicast
- Address Specific Query
-
-mcast6-queryfld03
- Verify that the kernel is not crashed when joining an IPv6 multicast
- group on a single socket, then receiving a large number of Multicast
- Address and Source Specific Query
-
-mcast6-queryfld04
- Verify that the kernel is not crashed when joining plural IPv6 multicast
- groups on separate socket, then receiving a large number of General
- Query
-
-mcast6-queryfld05
- Verify that the kernel is not crashed when joining joining plural IPv6
- multicast groups on separate socket, then receiving a large number of
- Multicast Address Specific Query
-
-mcast6-queryfld06
- Verify that the kernel is not crashed when joining joining plural IPv6
- multicast groups on separate socket, then receiving a large number of
- Multicast Address and Source Specific Query
-
-
-ssh
----
-ssh4-stress01
- Verify the ssh connectivity over IPv4 is not broken after creating
- many ssh sessions
-
-ssh4-stress02
- Verify the ssh connectivity over IPv4 is not broken after logged
- in/out by many clients asynchronously for a long time
-
-ssh4-stress03
- Verify the ssh connectivity over IPv4 is not broken after forwarding
- TCP traffic for a long time
-
-ssh6-stress01
- Verify the ssh connectivity over IPv6 is not broken after creating
- many ssh sessions
-
-ssh6-stress02
- Verify the ssh connectivity over IPv6 is not broken after logged
- in/out by many clients asynchronously for a long time
-
-ssh6-stress03
- Verify the ssh connectivity over IPv6 is not broken after forwarding
- TCP traffic for a long time
-
-
-dns
----
-dns4-stress01
- Verify the dns server or the kernel is not down after handling
- many name lookup queries
-
-dns4-stress02
- Verify the dns server or the kernel is not down after handling
- many reverse lookup queries
-
-dns6-stress01
- Verify the dns server or the kernel is not down after handling
- many name lookup queries
-
-dns6-stress02
- Verify the dns server or the kernel is not down after handling
- many reverse lookup queries
-
-
-http
-----
-http4-stress01
- Verify the http server or the kernel is not down after a http client
- requests large data via IPv4
-
-http4-stress02
- Verify the http server or the kernel is not down after many http
- clients request data over IPv4 asynchronously for a long time
-
-http6-stress01
- Verify the http server or the kernel is not down after a http client
- requests large data via IPv6
-
-http6-stress02
- Verify the http server or the kernel is not down after many http
- clients request data over IPv6 asynchronously for a long time
-
-
-ftp
----
-ftp4-download-stress01
- Verify the ftp server or the kernel is not down after a ftp client
- requests large data via IPv4
-
-ftp4-download-stress02
- Verify the ftp server or the kernel is not down after many ftp
- clients request data over IPv4 asynchronously for a long time
-
-ftp6-download-stress01
- Verify the ftp server or the kernel is not down after a ftp client
- requests large data via IPv6
-
-ftp6-download-stress02
- Verify the ftp server or the kernel is not down after many ftp
- clients request data over IPv6 asynchronously for a long time
-
-ftp4-upload-stress01
- Verify the ftp server or the kernel is not down after a ftp client
- uploads a large data via IPv4
-
-ftp4-upload-stress02
- Verify the ftp server or the kernel is not down after many ftp clients
- uploads data over IPv4 asynchronously for a long time
-
-ftp6-upload-stress01
- Verify the ftp server or the kernel is not down after a ftp client
- uploads a large data via IPv6
-
-ftp6-upload-stress02
- Verify the ftp server or the kernel is not down after many ftp clients
- uploads data over IPv6 asynchronously for a long time
--
2.14.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [LTP] [RFC PATCH 1/1] doc: Remove network stress related doc
2017-09-11 20:00 [LTP] [RFC PATCH 1/1] doc: Remove network stress related doc Petr Vorel
@ 2017-10-03 8:50 ` Petr Vorel
2017-10-06 14:27 ` Alexey Kodanev
0 siblings, 1 reply; 3+ messages in thread
From: Petr Vorel @ 2017-10-03 8:50 UTC (permalink / raw)
To: ltp
> File doc/network_stress.txt is outdated and duplicite (network stress
> related docs is in each directory in 00_Descriptions.txt files).
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> IMHO it doesn't make sense to have duplicity in docs.
> Next step could be rename 00_Descriptions.txt files to something reasonable (README ?).
> ---
> doc/network_stress.txt | 531 -------------------------------------------------
> 1 file changed, 531 deletions(-)
> delete mode 100644 doc/network_stress.txt
Hi,
ping.
Kind regards,
Petr
^ permalink raw reply [flat|nested] 3+ messages in thread
* [LTP] [RFC PATCH 1/1] doc: Remove network stress related doc
2017-10-03 8:50 ` Petr Vorel
@ 2017-10-06 14:27 ` Alexey Kodanev
0 siblings, 0 replies; 3+ messages in thread
From: Alexey Kodanev @ 2017-10-06 14:27 UTC (permalink / raw)
To: ltp
On 10/03/2017 11:50 AM, Petr Vorel wrote:
>> File doc/network_stress.txt is outdated and duplicite (network stress
>> related docs is in each directory in 00_Descriptions.txt files).
>> Signed-off-by: Petr Vorel <pvorel@suse.cz>
>> ---
>> IMHO it doesn't make sense to have duplicity in docs.
>> Next step could be rename 00_Descriptions.txt files to something reasonable (README ?).
>> ---
>> doc/network_stress.txt | 531 -------------------------------------------------
>> 1 file changed, 531 deletions(-)
>> delete mode 100644 doc/network_stress.txt
> Hi,
> ping.
Applied, thanks!
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-10-06 14:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-11 20:00 [LTP] [RFC PATCH 1/1] doc: Remove network stress related doc Petr Vorel
2017-10-03 8:50 ` Petr Vorel
2017-10-06 14:27 ` Alexey Kodanev
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.