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?
--
Kind Regards, Markus Falb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 306 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20121121/ec075a7d/attachment-0001.sig>
how about telnet yourself via the lo interface? Is there something different then? ------------ Banyan He Blog: http://www.rootong.com Email: banyan at 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. -- Kind Regards, Markus Falb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 306 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20121122/1387f3f2/attachment-0001.sig>
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? -- Kind Regards, Markus Falb