4.57. fcoe-utils

When stopping the fcoe service, the fcoe initscript did not properly clean up after itself as expected (did not remove FCoE devices, kill related processes and unload FCoE drivers). As a consequence, FCoE interfaces were not brought down and FCoE related threads were still running after the fcoe had been stopped. The "service fcoe stop" command is used to ensure safe after-update service restarts on FCoE dependent systems, therefore it cannot be used to remove FCoE devices and unload related kernel modules. Concerning this situation, the initscript has been modified to use the "stop force" command option to completely remove FCoE devices and unload related kernel modules. The fcoe service now should be stopped using the "service fcoe stop force" command.

When removing a network interface with no fcoe port using the "fcoeadm -d" command, the fcoe port state machine set the removal operation incorrectly to wait without responding to fcoemon. This led to an internal error because fcoemon timed out waiting for the response. To resolve the problem, the code has been modified to return the code for no further action under these circumstances. The "fcoeadm -d" command now works for interfaces without the fcoe port as expected.

The fcoemon service did not maintain any information about the relative state of a physical network interface and its dependent VLAN interfaces. As a consequence, the fcoe port of the VLAN interface could have been out of sync with the fcoe port of the physical device, resulting in undesired behavior, such as processing link events improperly. To fix this problem, a ready flag has been introduced. This flag is set to false when the physical port is disabled. Link events are now processed correctly for the vlan ports.

When answering to an FCoE Initialization Protocol (FIP) VLAN Discovery request, some switches encapsulate FIP VLAN Discovery replies in a VLAN 0 tag which is wrapped around the packet's FIP frame header. Previously, when a packet containing such a reply reached a target network interface, some devices did not remove the VLAN tag before they started to process the FIP header. If the VLAN tag was not removed, the length of the processed header was larger than was expected, therefore the FIP parsing logic was not able to parse the FIP header correctly causing a loss of the packet. With this update, the parsing logic has been modified to skip over the VLAN header when necessary, and point to the correct start of the FIP header.

The timeout for a kernel reply to fcoeadm operations was set to 5 seconds, which was not enough when processing an fcoeadm operation on a system with a large number of FCoE ports while a kernel was under heavy load. As a consequence, the "internal error" message was displayed even though the operation was finished successfully. To prevent this bug, the timeout for the kernel reply was increased to 30 seconds. No error message is now sent when an fcoeadm operation succeeds.