Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Here is my analysis, and reply:

(In reply to comment #0)
> +++ This bug was initially created as a clone of Bug #682371 +++
> 
> Description of problem:
> 
> Network devices can have arbitrary names, and due to
> http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming, will have
> different names in Fedora 15.
> 
> openswan-2.6.32/programs/pluto/nat_traversal.c:int
> nat_traversal_espinudp_socket (int sk, const char *fam, u_int32_t type)
> 
> ...
> 
>                 switch(kern_interface) {
> 
>                         case USE_MASTKLIPS:
>                                 strcpy(ifr.ifr_name, "mast0");
>                                 break;
>                         case USE_KLIPS:
>                                 strcpy(ifr.ifr_name, "ipsec0");
>                                 break;
>                         case USE_NETKEY:
>                                 /* Let's hope we have at least one ethernet
> device */
>                                 strcpy(ifr.ifr_name, "eth0");
>                                 break;
>                         default:
>                                 /* We have nothing , really prob just abort and
> return -1 */
>                                 strcpy(ifr.ifr_name, "eth0");
>                                 break;
>                 }
>                 fdp[0] = sk;
>                 fdp[1] = type;
>                 r = ioctl(sk, IPSEC_UDP_ENCAP_CONVERT, &ifr);
> 
> Depending on how forgiving the kernel is, this looks like it will fail on any
> machine that doesn't happen to have an eth0 device.

Not really because  I have tested it with system without eth0 and with eth0 device, and it seems to work fine. And the reason is that the call

r = ioctl(sk, IPSEC_UDP_ENCAP_CONVERT, &ifr)

always fails with NETKEY (something Openswan uses in RH products), so passing "eth0" or not does not seem to make any difference. Infact the next call 

r = setsockopt(sk, SOL_UDP, UDP_ESPINUDP, &type, sizeof(type));

decides the state of "ESP in UDP" to be set on the socket. 

So in practicality, and given the state of current code and NETKEY functionality, this does not seem an issue.

On the other hand, this code change to test on "eth0" was done by upstream recently in december 2010 to avoid issue in some other context. Before that the above test on eth0 did not exist.

> 
> Version-Release number of selected component (if applicable):
> 
> openswan-2.6.32
> 
> How reproducible:
> 
> By inspection.

That said, I have come up with some ideas to fix the root cause of the above issue, and I would be happy to discuss this with upstream, once I comp up with a patch and after testing with NETKEY. However upstream uses KLIPS, and this code changes will affect their code too. Given that I (or we at RedHat) do not test KLIPS, and it is not advisable to patch the openswan code without upstream review and their testing. 


Avesh

Proposing for 6.2

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Filed as https://bugs.libreswan.org/show_bug.cgi?id=63

Avesh is correct in that it does not affect RHEL/Fedora that uses NETKEY, not KLIPS/MAST

As this is not a problem in RHEL/Fedora I am closing this bug as NOTABUG.