Hi, I am trying to get ipv6 firewall running. I did a very simple ip6tables rules and noticed very long running yum updates. I think that happened because firewall is dropping outgoing packets to port 80. Well, I thought to mitigate the issue and changed outgoing from drop to reject.
Now I try manually
# strace telnet 2a02:180:ffff:1::551f:b966 80 ... connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2a02:180:ffff:1::551f:b966", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28
3 second delay
) = -1 ECONNREFUSED (Connection refused) ...
The ECONNREFUSED is quite expected of course, but what is not expected that the connect syscall lasts 3 seconds. This 3 second delay is not happening with a equivalent telnet to a IPv4 address.
Why is this 3 second delay?
how about telnet yourself via the lo interface? Is there something different then?
------------ Banyan He Blog: http://www.rootong.com Email: banyan@rootong.com
On 2012-11-22 12:40 AM, Markus Falb wrote:
Hi, I am trying to get ipv6 firewall running. I did a very simple ip6tables rules and noticed very long running yum updates. I think that happened because firewall is dropping outgoing packets to port 80. Well, I thought to mitigate the issue and changed outgoing from drop to reject.
Now I try manually
# strace telnet 2a02:180:ffff:1::551f:b966 80 ... connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2a02:180:ffff:1::551f:b966", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28
3 second delay
) = -1 ECONNREFUSED (Connection refused) ...
The ECONNREFUSED is quite expected of course, but what is not expected that the connect syscall lasts 3 seconds. This 3 second delay is not happening with a equivalent telnet to a IPv4 address.
Why is this 3 second delay?
On 21.11.2012 17:40, Markus Falb wrote:
Hi, I am trying to get ipv6 firewall running. I did a very simple ip6tables rules and noticed very long running yum updates. I think that happened because firewall is dropping outgoing packets to port 80. Well, I thought to mitigate the issue and changed outgoing from drop to reject.
Now I try manually
# strace telnet 2a02:180:ffff:1::551f:b966 80 ... connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2a02:180:ffff:1::551f:b966", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28
3 second delay
) = -1 ECONNREFUSED (Connection refused) ...
The ECONNREFUSED is quite expected of course, but what is not expected that the connect syscall lasts 3 seconds. This 3 second delay is not happening with a equivalent telnet to a IPv4 address.
Why is this 3 second delay?
There are 2 destination unreachables sent, one immediate and the second after 3 seconds. There are also 2 log entries from ip6tables. It looks like the connect() is really trying a second time.
On 22.11.2012 12:21, Markus Falb wrote:
On 21.11.2012 17:40, Markus Falb wrote:
connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2a02:180:ffff:1::551f:b966", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28
There are 2 destination unreachables sent, one immediate and the second after 3 seconds. There are also 2 log entries from ip6tables. It looks like the connect() is really trying a second time.
btw, on CentOS 6 the timeout is 1 second instead of 3, but the questions remains the same.
Why is a retry necessary? The kernel says no, but it is retried anyways. Why? Is it CentOS/RHEL specific?
I realize that I got not many answers. Do you know of a better place to ask such things?
-
Banyan He -
Markus Falb