socket-util: Avoid using the identical message for different errors

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Fix "sFlow packet sampling" tests on BSDs

The name of loopback interface is "lo0" on BSDs.

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
socket-util: Fix set_dscp for IPv6

Try IPPROTO_IPV6/IPV6_TCLASS socket option as well as IPPROTO_IP/IP_TOS
so that this can work for IPv6 sockets.

IPPROTO_IP/IP_TOS socket option is, as it's SOL indicates, for IPv4.
What happens when it's used for IPv6 sockets?  On Linux, it seems to
be forwarded to IPv4 code and affects IPv4 part of the socket.
(e.g. non-V6ONLY case)  But it doesn't seem to be the intention of
this function.  On other platforms including NetBSD, it just fails
with ENOPROTOOPT.

Probably this function should take the address family but passing
it around lib/*stream*.c would be a bigger change.

Cc: Arun Sharma <arun.sharma@calsoftinc.com>
Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto: Send port status message for port-mods, right away.

Until now, when it processes OFPT_PORT_MOD message, Open vSwitch has waited
for ports to notify it that their status has changed before it sends a
port status update to controllers.

Also, Open vSwitch never sent port config updates at all for port
modifications other than OFPPC_PORT_DOWN.  I guess that this is a relic
from the era when there was only one controller, since presumably the
controller already knew that it changed the port configuration.  But in the
multi-controller world, it makes sense to send such port status updates,
and I couldn't quickly find anything in OF1.3 or OF1.4 that said they
shouldn't be sent.

EXT-338.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reported-by: Kmindg G <kmindg@gmail.com>
meta-flow: Remove duplicate break statements.

Commit 8bfd0fda mistakenly introduced duplicate "break;" statements to
MFF_MPLS_BOS handling. This patch removes them.

Found by inspection.

Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
INSTALL: Mention that building a kernel module is optional.

It used to be essentially required, but now it's reasonable to use the
kernel's builtin module.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Flavio Leitner <fbl@redhat.com>
cccl: Remove the seemingly wrong "lib" prefix.

I have not seen a use case where the "lib" prefix is needed.
In my tests, I see that adding the additional "lib" prefix
causes libraries to not be recognized.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
fatal-signal: Fatal signal handling for Windows.

Windows does not have a SIGHUP or SIGALRM. It does have
a SIGINT and SIGTERM. The documentation at msdn says that
SIGINT is not supported for win32 applications because
WIN32 operating systems generate a new thread to specifically
handle Ctrl+C.

This commit handles SIGTERM for Windows. The documentation also
states that nothing generates SIGTERM in Windows, but one can
use raise(SIGTERM) to manage it. The idea for handling SIGTERM
for Windows is to just have a place holder if there is need to
raise() a signal for some other purpose.

We use SIGALRM in timeval.c if we wake up from a sleep after
'deadline'. For Windows, print an error message and then
use SIGTERM.

There is an atexit() function for Windows, so we can call cleanup
functions during exit.

An upcoming commit separately handles Ctrl+C so that we can call
clean up functions for that use case.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
signals: Don't compile for Windows.

There are no users in Windows for any of the
function in signals.c

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
socket-util: pipe for Windows.

Windows does have pipes (the interface is a little different).
We mostly use pipes in Linux to synchronize between parent and
children and also to handle fatal signals and then wake from poll_loop().

For Windows, we are using events for the same purpose. So don't
implement pipes for Windows.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
fatal-signal: Handle SIGINT for Windows.

Ctrl+C signals are a special case for Windows and can
be handled by registering a handle through
SetConsoleCtrlHandler() routine. This is only useful
when we run it directly on console and not as services in
the background.

Once we get a Ctrl+C signal, we call the cleanup functions
and then exit.

One thing to know here is that MinGW terminal handles
Ctrl+C signal differently (and looks a little buggy. I see
it exiting the handler midway with some sort of timeout).
So this implementation is only useful when run on Windows
terminal. Since we only use MinGW for compilation and
eventually to run unit tests, it should be okay. (The unit
tests would ideally use windows services and not expect
Ctrl+C)

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
fatal-signal: SIGPIPE for Windows.

Windows does not have a SIGPIPE. We ignore SIGPIPE for
Linux. To compile on Windows, carve out a new function
to ignore SIGPIPE on Linux.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
vswitchd: Split pick_local_hw_addr

This allows to reuse find_local_hw_addr for fake bridges.
Preparation for upcoming MAC address inheritance for fake bridges.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
vswitchd: Limit fake bridge MAC selection to ports in the same VLAN

Limit fake bridge MAC address selection to only consider ports
that use the same VLAN as the fake bridge itself.

This prevents OVS from selecting a MAC address that was not really
present in the VLAN of the fake bridge before.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
dpif-linux: Lookup netdev to get netdev type string.

When creating tap ports in dpif-linux, the "tap" type is treated the
same as "system", and the type is discarded. When dumping datapath
port types, this would cause "tap" type to be reported as a "system"
type.

Each time we see a port of the wrong type in bridge_reconfigure(), we
remove it and add a port with the correct configuration. This would
always occur for tap ports, causing deletion and re-creation of all tap
ports each time the bridge was reconfigured.

This patch makes dpif-linux use netdev to look up port types if the
datapath reports that they are of type OVS_VPORT_TYPE_NETDEV.

Bug #1196289.

Reported-by: James Schmidt <jschmidt@vmware.com>
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>