| Summary: | different ways of blocking a packet using ip6tables leads to different results | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Pavel Šimerda (pavlix) <psimerda> | ||||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 23 | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, psimerda, psutter | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2016-10-26 16:43:33 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 883152 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Pavel Šimerda (pavlix)
2016-05-16 15:59:28 UTC
Created attachment 1158014 [details]
a test script
Sorry actual/expected results were swapped. Created attachment 1158016 [details]
a test script
For quick assessment of the bug it should be enough to see the time output that shows that the first two runs (no firewall, tcp rejected) finish quickly while the last run (all rejected) takes 10 seconds in my case. $ grep '' *.time 01-no-firewall.time: 0.02user 0.02system 0:00.05elapsed 86%CPU (0avgtext+0avgdata 7064maxresident)k 0inputs+56outputs (0major+736minor)pagefaults 0swaps 02-tcp-rejected.time: 0.03user 0.02system 0:01.08elapsed 5%CPU (0avgtext+0avgdata 7108maxresident)k time:0inputs+56outputs (0major+732minor)pagefaults 0swaps 03-all-rejected.time: 0.03user 0.03system 0:10.08elapsed 0%CPU (0avgtext+0avgdata 7104maxresident)k 0inputs+56outputs (0major+733minor)pagefaults 0swaps The most notable difference in strace is:
$ diff -u 02-tcp-rejected.strace 03-all-rejected.strace
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 4
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(4, {sa_family=AF_INET6, sin6_port=htons(22), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINPROGRESS (Operation now in progress)
-select(5, [4], [4], [4], {10, 0}) = 2 (in [4], out [4], left {8, 998426})
-getsockopt(4, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
+select(5, [4], [4], [4], {10, 0}) = 0 (Timeout)
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
fcntl(5, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("127.0.0.1")}, 1
While in one case an error is returned imediately using the sequence of connect, select and getsockopt, in the other case the select actually times out which also explains the 10 seconds when using nc for testing.
Created attachment 1158044 [details]
a test script
Created attachment 1158045 [details]
output of the script as a tarball (script included)
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs. Fedora 23 has now been rebased to 4.7.4-100.fc23. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25. If you experience different issues, please open a new bug report for those. *********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously. So this is apparently the very classic problem with blocked ICMP messages. |