#
346783 |
|
27-Apr-2019 |
kevans |
MFC r345139, r345151, r346324, r346328: ether_gen_addr KPI
if_bridge and if_vxlan conversion to this deterministic MAC address KPI has been MFC as well. This is potentially error prone as the generated address range for these has decreased, but I've deemed this acceptable for stable branches due to collisions for thees interfaces being easily remedied.
I have no intention of switching anything else to this KPI in any stable branches.
r345139: ether: centralize fake hwaddr generation
We currently have two places with identical fake hwaddr generation -- if_vxlan and if_bridge. Lift it into if_ethersubr for reuse in other interfaces that may also need a fake addr.
r345151: ether_fakeaddr: Use 'b' 's' 'd' for the prefix
This has the advantage of being obvious to sniff out the designated prefix by eye and it has all the right bits set. Comment stolen from ffec.
I've removed bryanv@'s pending question of using the FreeBSD OUI range -- no one has followed up on this with a definitive action, and there's no particular reason to shoot for it and the administrative overhead that comes with deciding exactly how to use it.
r346324: net: adjust randomized address bits
Give devices that need a MAC a 16-bit allocation out of the FreeBSD Foundation OUI range. Change the name ether_fakeaddr to ether_gen_addr now that we're dealing real MAC addresses with a real OUI rather than random locally-administered addresses.
r346328: Compile sha1.c when ether support is included
sha1 is used by ether_gen_addr after r346324. Perhaps in an ideal world we could detect that the kernel's been compiled without sha1_* bits included and silently fallback to arc4random instead because these platforms/kernel configs are far and few between. It's fairly lightweight, though, so just include it for now.
|
#
327927 |
|
13-Jan-2018 |
bryanv |
MFC r327375, r327385, r327386:
Add support for IPv6 scoped addresses to vxlan
Advertise IFCAP_LINKSTAT after r326480 added link status support
Add macro for vxlan list mutex lock and unlock
|
#
327217 |
|
26-Dec-2017 |
bryanv |
MFC r326480:
Add if media and link status events to vxlan
|
#
327141 |
|
24-Dec-2017 |
ae |
MFC r326898: Fix possible memory leak.
vxlan_ftable entries are sorted in descending order, due to wrong arguments order it is possible to stop search before existing element will be found. Then new element will be allocated in vxlan_ftable_update_locked() and can be inserted in the list second time or trigger MPASS() assertion with enabled INVARIANTS.
PR: 224371
|
#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
301538 |
|
07-Jun-2016 |
sephe |
net: Use M_HASHTYPE_OPAQUE_HASH if the mbuf flowid has hash properties
Reviewed by: hps, erj, tuexen Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D6688
|
#
298747 |
|
28-Apr-2016 |
rrs |
Complete the UDP tunneling of ICMP msgs to those protocols interested in having tunneled UDP and finding out about the ICMP (tested by Michael Tuexen with SCTP.. soon to be using this feature).
Differential Revision: http://reviews.freebsd.org/D5875
|
#
275358 |
|
01-Dec-2014 |
hselasky |
Start process of removing the use of the deprecated "M_FLOWID" flag from the FreeBSD network code. The flag is still kept around in the "sys/mbuf.h" header file, but does no longer have any users. Instead the "m_pkthdr.rsstype" field in the mbuf structure is now used to decide the meaning of the "m_pkthdr.flowid" field. To modify the "m_pkthdr.rsstype" field please use the existing "M_HASHTYPE_XXX" macros as defined in the "sys/mbuf.h" header file.
This patch introduces new behaviour in the transmit direction. Previously network drivers checked if "M_FLOWID" was set in "m_flags" before using the "m_pkthdr.flowid" field. This check has now now been replaced by checking if "M_HASHTYPE_GET(m)" is different from "M_HASHTYPE_NONE". In the future more hashtypes will be added, for example hashtypes for hardware dedicated flows.
"M_HASHTYPE_OPAQUE" indicates that the "m_pkthdr.flowid" value is valid and has no particular type. This change removes the need for an "if" statement in TCP transmit code checking for the presence of a valid flowid value. The "if" statement mentioned above is now a direct variable assignment which is then later checked by the respective network drivers like before.
Additional notes: - The SCTP code changes will be committed as a separate patch. - Removal of the "M_FLOWID" flag will also be done separately. - The FreeBSD version has been bumped.
MFC after: 1 month Sponsored by: Mellanox Technologies
|
#
273371 |
|
21-Oct-2014 |
bryanv |
Use the size of the Ethernet address, not the entire header, when copying into forwarding entry.
Reported by: Coverity CID: 1248849
|
#
273331 |
|
20-Oct-2014 |
bryanv |
Add vxlan interface
vxlan creates a virtual LAN by encapsulating the inner Ethernet frame in a UDP packet. This implementation is based on RFC7348.
Currently, the IPv6 support is not fully compliant with the specification: we should be able to receive UPDv6 packets with a zero checksum, but we need to support RFC6935 first. Patches for this should come soon.
Encapsulation protocols such as vxlan emphasize the need for the FreeBSD network stack to support batching, GRO, and GSO. Each frame has to make two trips through the network stack, and each frame will be at most MTU sized. Performance suffers accordingly.
Some latest generation NICs have begun to support vxlan HW offloads that we should also take advantage of. VIMAGE support should also be added soon.
Differential Revision: https://reviews.freebsd.org/D384 Reviewed by: gnn Relnotes: yes
|