It can happen that the secure channel thinks that it is connected
to the controller, but in fact the connection has dropped. For
example, a switch intermediate between the secure channel and the
controller could have a flow inserted, due to a malfunction, that
causes packets in one direction or the other to be dropped. When
this happens, the Linux kernel's TCP implementation will continue
retransmitting packets for somewhere between 13 and 30 minutes,
depending on the connection's retransmission timeout (according
to linux/Documentation/networking/ip-sysctl.txt) with the default
Linux settings.
We want to detect the lost connection and re-connect much faster
than that. We use OpenFlow echo request and reply messages: if
no message is received from the controller for N seconds, we
send out an echo request. If no reply (actually, any message at
all) is received for an additional N seconds, then we assume
that the connection has been lost, and reconnect.
The new OFPT_ECHO_REQUEST and OFPT_ECHO_REPLY OpenFlow messages
have the same functionality and are more general (in that they
are not Netlink-specific).
This makes the handling of defining and printing actions more consistent in
dpctl. The flow portion of the output of "dump-flows" can now be used as the
input of "add-flows". Flows can be added on the command line with the new
"add-flow" command.
Otherwise the secchan considers the NLMSG_DONE at the end of a stats
dump to be an error and disconnects from the netlink connection.
Thanks to Martin for discovering the problem.
This allows us to open network devices without bringing them up
and setting them for promiscuous mode, which will be useful in the
secchan for in-band communication.
This message is not too useful since there are various legitimate
ways that we can end up with runt frames, e.g. frames that only
ever passed through virtual network devices and never touched a
physical Ethernet.
This changes the kernel switch implementation to use the kernel Netlink
"dump" interface to allow flow stats that don't fit in the socket buffer
to be dumped gradually as the caller drains the socket buffer.
One of the changes here is a bug fix for nla_unreserve. Because Netlink
attributes' lengths are rounded up to a multiple of 4 bytes, reducing
the length of the payload by N bytes doesn't necessarily reduce the
length of the skb by N bytes. Instead, we need to know the original
length and final length of the attribute. This means that using 'len'
as a difference in bytes doesn't really make sense, so this changes
'len' to be the new length of the attribute payload and renames the
function to nla_shrink to (IMO) better reflect what it is now doing.
Since we have to release the RCU read lock between calls to the dump
function, we need table iterators that persist across RCU epochs. One
way to do this would be to add new "iterator_save" and "iterator_restore"
functions, but this seemed like overkill since there would then be a
total of 5 iterator functions that have only one user (flow stats dumping).
Instead, this patch refactors table iteration into a single "iterate"
function that takes a callback. This simplifies the table iteration code
significantly.
This change also modifies dpctl to understand the new format of flow
stats.
The Linux kernel returns ENOBUFS to userspace code to indicate that
a netlink message that the kernel wanted to send could not be due to
a lack of buffer space. We checked for this and dealt with it in
one recvmsg call but not in another. This change tolerates it in
both places.
Should fix a problem encountered on the OF6k under "hping3 --flood".
** This fix was done by Ben. **
Commit 0a9024a2d7, "Changes based on feedback from GigaFin," added support
for compiling on a system that lacked up-to-date Linux kernel headers, by
dropping support for a feature only in newer kernels on such a system.
But the code already supported such a system properly; only the lack of
a macro definition kept it from compiling. So define the macro ourselves
instead of disabling the feature.
To elaborate, there are two issues here.
The first is kernel support for NETLINK_ADD_MEMBERSHIP. Older
kernels don't support this. But NETLINK_ADD_MEMBERSHIP was added
at the same time as support for more than 32 netlink multicast
groups. Netlink multicast groups numbered less than 32 can be
subscribed using a different mechanism, and in fact we do that
for such groups. Thus, attempting to use NETLINK_ADD_MEMBERSHIP
on an older kernel basically can't happen, and if it did it would
be a bug in the OpenFlow kernel module for telling userspace to
subscribe to a multicast group that cannot exist on that kernel.
The second is the kernel headers that the userspace programs are
compiled with. Without the change quoted below, the userspace
programs will silently fail if they are compiled with 2.4.x
headers and then run on a 2.6.x kernel and given a multicast
group numbered above 32, because they will not even try to
subscribe to that group. With the change, the userspace programs
will work properly when run on 2.4.x or 2.6.x kernels regardless
of the multicast group number and regardless of whether the
headers they were compiled against were from 2.4.x or 2.6.x.
Ben Pfaff
Justin Pettit
Ben Pfaff
root