Bug 678582
Summary: | ping traffic (icmp) sends xfrm ACQUIRE msgs with protocol 17 (UDP) | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Avesh Agarwal <avagarwa> |
Component: | kernel | Assignee: | Herbert Xu <herbert.xu> |
Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
Severity: | high | Docs Contact: | |
Priority: | urgent | ||
Version: | 6.1 | CC: | iboverma, latten, sgrubb |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-03-09 14:17:20 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 584498, 846801, 846802 |
Description
Avesh Agarwal
2011-02-18 14:18:36 UTC
Before sending icmp-echo-request, ping gets the source address via opening a DGRAM socket and doing a connect(). This results in a __xfrm_lookup() in ip_route_output_flow(), which can trigger an ACQUIRE depending on ipsec policy. However, ping opening this dgram socket, does not result in an outgoing pkt, just in it acquiring some info it needs to form and then send the icmp-echo-request pkt. So, this is not a kernel problem, but rather a side effect of ping. "ping -I <srcaddr> dstaddr" will give ping the src addr and it does not have to open the dgram socket to get src addr info. And thus an ACQUIRE won't be triggered. > > However, we tested this on upstream kernel 2.6.36, and this issue is not found. > Also found from discussion with Joy that the behaviour is same with upstream kernel, and the issue is found. However as Joy noted in comment 3 that this seems more likely related to behaviour of Ping command. I would like to ask that even though it seems its a side effect of Ping command, is the kernel behaviour, of sending ACQUIRE for UDP policy when ping opens a dgram (UDP) socket, right? Because dgram (UDP) socket seems local to the machine and the UDP ipsec policy we have is for a outside box. So I am wondering why the kernel is matching this local dgram stuff with the ipsec policy specific to UDP? Just curious? If we know that kernel is doing it right, then perhaps we can close this bz. Avesh, I had thought about that too. It's the connect() that ping does after it opens the dgram socket that results in the ACQUIRE. It does something similar to, connect(socket_fd, dst, sizeof(dst)) since we do the connect with the dst, the guy we want to ping... then we are planning on querying routes to see which route to use for our source address using dst. The ip_route_output_flow, calls __xfrm_lookup() which results in that ACQUIRE. here is what my dump looked like from upstream kernel... km_query xfrm_state_find xfrm_resolve_and_create_bundle xfrm_bundle_lookup flow_cache_lookup __xfrm_lookup ip_route_output_flow ip4_datagram_connect inet_dgram_connect sys_connect So I think you guys have figured this out already :) Ping does a connect to obtain routing information for the actual ICMP packets. It does so using a UDP socket. That's why you end up with a UDP ACQUIRE message. IOW I don't think we have a bug here at all. |