flushing stdout for flow -r

Change-Id: I9ccaaa40a14e6b8e8a88c4e0e50f4644c3f89323
- Ensure that inner header checksums are correct on the wire when the outer
header is UDP (MPLSoUDP or VXLAN).

- Outer UDP header source port is now a hash of inner header 5-tuple.

Bug 1338326

Change-Id: I8e1519b562faef30523a297e42c2a4a64759e6f4
- interface notifier argument changed in 3.11 kernel. Add #ifdefs
to accommodate that change

Change-Id: Ieb1b0512c9531fe0e67a562c92f3c91d93c8d540
Merge "- Ensure that inner header checksums are correct on the wire when the outer header is UDP (MPLSoUDP or VXLAN)."
Make vrouter coexist with Linux bridge (and not coexist with OVS).

Bug 1338900

Change-Id: Ie2455a070acd03f55d0a920a4495fe2fded1ab74
BUG:1336717
Do trap + forward the packet when the packet arrives from an ECMP source
that was different from the destination of the forward flow

[ forward port into mainline ]

Change-Id: If9283fde17f4353cd483b0f5b87100e82a4c8fca
BUG 1340528

- For ICMP error packets, the flow key has to be the same as that of the
original payload. This is because, in a floating IP case, default security
group rules allow only outgoing packets originated by the VM and incoming
packets to VM that belong to the same security group. Packets originated
from the destination floating ip network does not belong to the same security
group and hence will be dropped if we use the outer IP header for forming the
flow key.

Another issue is with the NAT-ing. The ip header source ip and destination ip
+ transport header ports in the icmp error payload have to be NAT-ed back.

Change-Id: If5082cc5fb9d20175a71abac42d09ac27100bf55
BUG 1341529

- if the packet from a resident VM has to go out on physical interface
and if vrouter needs to fragment the packet post tunnel header updation,
fragment only if DF bit is net set. Else, trap the packet to agent for
ICMP error reports

Change-Id: I1d7af762d1b3e095701e24f78737c31bcb9989cc
Merge "BUG 1341529"
- when the packet hits the resolve nexthop, the packet is trapped to
agent for route creation (resolve is valid only in fabric network).
While arp responses from fabric are trapped to agent for route creation
it is possible that the route will have valid information only after
the first data packet hits the route table, and hence there could be
packet loss

BUG 1336787

Change-Id: I345a343f478ddd8a7b62303d04a2e246825c403c
Merge "flushing stdout for flow -r"
- Now that agent has removed uses of hdr_nh, remove that field from
agent_hdr

Change-Id: I9767a0160390481e37c78f43cfb42a2fbb3fe55c
- In case of mirroring, packet data pointer can be above skb data
pointer, since for mirroring new headers are added on top of the
original packet. This results in get_udp_port misbehavior when it
tries to make sure that the all the headers (network + transport
/part of it) are in the contiguous memory area by doing a skb pull.

Make sure that pull_len has a valid positive value before trying to
pull.

Change-Id: I140ff67d9b67ddb66f075ba6659fa6e50d9bb436
Correcting the format of VIF index print

Change-Id: I4bf909bf28910c06ac6271cbcd3c886585b349ca
Merge "Correcting the format of VIF index print"
- There are two paths in the vrouter code where interfaces (OS visible
interfaces - netdev to be specific) are manipulated. One is in the call chain
to process agent request and the other is when the interface is deleted by linux
(for e.g.: a pseudo or a tap interface going away resulting in the notifier call
chain). In the latter path, netlink lock is acquired by the notifier chain,
whereas in the former path there is no netlink lock.

However, the common functions that are called in both paths need netlink lock.
The logic we had till now to decide whether we need to acquire lock in the
common functions is embarassingly buggy. rtnl_is_locked just says whether the
lock is locked or not and not whether the lock is owned by the thread or not,
as is in usage right now. So, in many cases it is possible that the lock is not
acquired, resulting in kernel warnings.

I guess, the usage was good when it was first used, but the subsequent copies of
the usage is not what is needed. To fix this issue, restructure the code path in
such a way that when common functions are entered, the lock is already taken.

BUG 1349258

- In 2.6.32-358.123.2.openstack.el6 kernel (and I guess all openstack kernels), the
first field in the skb->cb is an offset field that is used to calculate header length.
In those kernels, skb->cb is a structure of type skb_gso_cb with one field. Need to
set that field to zero.

BUG 1349560

Change-Id: I1e7e7b0e2f7cc7ee74b6db5ee91c347b7193a83b
Changes to accomodate drop reason for a flow, and display in flow utility.

Change-Id: I23da4c2b5eba49a53a5eb47c038d404f1cbe3984
If the mac address of the packet does not match with the mac address
of the physical interface in which the packet came, just drop the packet.

Other than broadcast and multicast macs, the mac address of the packet
will not match with that of the interface typically when the interface goes
into promiscuous mode. When in promiscuous mode, vrouter will forward all
the packets that it receives from the physical interface. This situation
takes an ugly turn when the switch broadcasts unknown unicast packets and
all the computes receives those packets and starts forwarding, resulting
in a storm.

[ Adding Centos bits ]

Change-Id: Ic756af6856f3c0b31ac9e7e5baadcf0da413f3fd
Closes-Bug: 1350774
modify vr_compat.h to compile on centos 6.5

Change-Id: Iea0183a9730ebe6397cafac38a1b08c6e2065997
In the pull inner header functions, get the outer ip header pointer with
the help of pkt_network_header rather than as an argument from parent
functions

When we receive an MPLSoUDP encapsulated packet, we pull till the end of
inner transport header to a contiguous buffer. As part of that we also do
checksum verification, if hardware has not done verification. To verify
checksum, ip header is needed and the header pointer is passed to checksum
verification functions. However, in case the headers are in different buffers
and the pull actually pulls data from different buffers, the ip pointer will
not be valid, since pulls can realloc buffers and hence can cause issues.

Closes Bug: 1352294

Change-Id: I918cd6c3046078abf07981e2438f2d11e914ac8a