summaryrefslogtreecommitdiff
path: root/sys/net
Commit message (Collapse)AuthorAgeFilesLines
* rtsock: Fix stack overflowMark Johnston2026-02-241-2/+2
| | | | | | | | | | | Approved by: so Approved by: re (cperciva) Security: FreeBSD-SA-26:05.route Security: CVE-2026-3038 Fixes: 92be2847e845 ("rtsock: Avoid copying uninitialized padding bytes") (cherry picked from commit f3be7df50f01d9a6ead9f27b55bb4dfd7dc4f9d2) (cherry picked from commit 1eb2beb3686c50a870ed7688f753f89dd0f0ab3e)
* sys/net/sff8436.h: Fix the register address of link length of copper or ↵Kirill Kochnev2026-01-311-1/+1
| | | | | | | | | | | | | | | | | active cable The register address of link length of copper or active cable is 146 as per the SFF-8436 specification [1]. [1] 7.6.2 Upper Memory Map Page 00h SFF-8436 Specification (pdf): https://members.snia.org/document/dl/25896 Reviewed by: imp, zlei MFC after: 1 week Pull Request: https://github.com/freebsd/freebsd-src/pull/1885 Closes: https://github.com/freebsd/freebsd-src/pull/1885 (cherry picked from commit a537694b49f719d84e3a69a2b8a3098f603da7d7) (cherry picked from commit fdd23fc3d0aacd1c80d0565d736591521b2421fc)
* net: Use proper prototype for SYSINIT functionsZhenlei Huang2026-01-313-3/+3
| | | | | | | MFC after: 1 week (cherry picked from commit 6f8259eae61981d7e5d049be7eed9235f0e8172e) (cherry picked from commit fa80382b99f934ab46b9365d1081c6425ed58026)
* if_ovpn: add interface countersKristof Provost2026-01-281-0/+32
| | | | | | | | | | | Count input/output packets and bytes on the interface as well, not just in openvpn-specific counters. PR: 292464 MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC ("Netgate") (cherry picked from commit 21d666a19331f31fb6dfa1e370de5a84a1a5cb46)
* iflib: remove convoluted custom zeroing codeBrooks Davis2026-01-161-60/+5
| | | | | | | | | | | | | | | | Replace a collection of aliasing violations and ifdefs with memset (which now expands to __builtin_memset and should be quite reliably inlined.) The old code is hard to maintain as evidenced by the most recent change to if_pkt_info_t updating the defines, but not the zeroing code. Reviewed by: gallatin, erj Effort: CHERI upstreaming Sponsored by: Innovate UK Fixes: 43d7ee540efe ("iflib: support for transmit side nic KTLS offload") Differential Revision: https://reviews.freebsd.org/D54605 (cherry picked from commit 31e7dc6b9a000b02353bfc41cbd897533287cda2)
* altq(4): Fix a typo in a source code commentGordon Bergling2026-01-101-1/+1
| | | | | | - s/backet/bucket/ (cherry picked from commit 1df4d82bd17ebd7449a6b58c32b65a12269ca068)
* pfsync: Avoid zeroing the state export unionMark Johnston2026-01-071-2/+4
| | | | | | | | | | | | | | | | | | pfsync_state_export() takes a pointer to a union that is in reality a pointer to one of the three state formats (1301, 1400, 1500), and zeros the union. The three formats do not have the same size, so zeroing is wrong when the format isn't that which has the largest size. Refactor a bit so that the zeroing happens at the layer where we know which format we're dealing with. Reported by: CHERI Reviewed by: kp MFC after: 1 week Sponsored by: CHERI Research Centre (EPSRC grant UKRI3001) Differential Revision: https://reviews.freebsd.org/D54163 (cherry picked from commit 796abca7e281f0d4b7f72f48da4f941e1c8b139c)
* if_ovpn: use epoch to free peersKristof Provost2025-12-171-2/+12
| | | | | | | | | | | | | | Avoid a possible use-after-free in the rx path. ovpn_decrypt_rx_cb() calls ovpn_finish_rx() which releases the lock, but continues to use the peer. Ensure that the peer cannot be freed until we're sure all potential users have stopped using it (i.e. have left net_epoch). Reported by: Kevin Day <kevin@your.org> MFC after: 1 week Sponsored by: Rubicon Communications, LLC ("Netgate") (cherry picked from commit 5e2bbfe387f7eac8f802c4b6ad2114f0e17bb5f2)
* if_ovpn: use IFT_TUNNELKristof Provost2025-11-251-1/+1
| | | | | | | | | | IFT_ENC has special behaviour in pf we don't desire, and this also ensures that for all interface types there is N:1:1 correspondence between if_type:dlt:header len. Requested by: glebius MFC after: 1 week (cherry picked from commit ff9f76a206c80c263050816735d537a151ee2999)
* if_vxlan: fix byteorder of source portSeyed Pouria Mousavizadeh Tehrani2025-11-071-2/+2
| | | | | | | | | | Fix the htons byteorder of vxlan packets after `vxlan_pick_source_port` picks a source port during encapsulation. Reviewed by: zlei, kp, adrian Differential Revision: https://reviews.freebsd.org/D53022 (cherry picked from commit 1cc316727ebae157b3d035d9fb1ad38310a80698)
* net: Validate interface group names in ioctl handlersMark Johnston2025-11-041-8/+26
| | | | | | | | | | | | The handlers were not checking that the group names are nul-terminated. Add checks for this. Reported by: Ilja Van Sprundel <ivansprundel@ioactive.com> Reviewed by: zlei MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D53344 (cherry picked from commit 32919a34f17ac1af99dec7376f22a8393c251602)
* altq: Clear stats structures in get_class_stats()Mark Johnston2025-11-043-0/+6
| | | | | | | | | | | | | These structures are copied out to userspace, and it's possible to leak uninitialized stack bytes since these routines and their callers weren't careful to clear them first. Add memsets to avoid this. Reported by: Ilja Van Sprundel <ivansprundel@ioactive.com> Reviewed by: kp, emaste MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D53342 (cherry picked from commit ff08916e9ac689e6ce734de72325fc2bd9495a35)
* epair: add support for checksum offloadingTimo Völker2025-09-291-2/+59
| | | | | | | | | | | | | | | | | | | | | | | Add capabilities RXCSUM and RXCSUM6 as well as TXCSUM and TXCSUM6 for for receive and transmit checksum offloading for TCP and UDP to the epair interface and enable them by default. RXCSUM and RXCSUM6 are enabled because an epair interface may receive a packet with the csum_flag CSUM_DATA_VALID set, which is expected only if these capabilities are enabled. Since it seems not helpful to remove this flag, it is not possible to disable these capabilities. TXCSUM and TXCSUM6 are synchronized between the two epair interface ends. If enabled/disabled on one end, it will be enabled/disabled on the other end. If the sending epair interface end has TXCSUM or TXCSUM6 enabled and the receiving end is in a bridge, it is assumed that all interfaces in the bridge have that capability enabled. Otherwise the bridge would have disabled that capability on the receiving epair interface end in the bridge which would have disabled that capability on the sending epair interface end as well due to the synchronization. Reviewed by: bcr, Seyed Pouria Mousavizadeh Tehrani Differential Revision: https://reviews.freebsd.org/D51639 (cherry picked from commit e4ea162509e400340a2bc3e755071a92f3465e2d)
* ifnet: Defer detaching address family dependent dataZhenlei Huang2025-09-271-5/+21
| | | | | | | | | | | | | | | While diagnosing PR 279653 and PR 285129, I observed that thread may write to freed memory but the system does not crash. This hides the real problem. A clear NULL pointer derefence is much better than writing to freed memory. PR: 279653 PR: 285129 Reviewed by: glebius MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D49444 (cherry picked from commit b5c46895fdddcdb7dd1994598925d6989ea7c8f2)
* ethernet: Prefer memcmp() over bcmp()Zhenlei Huang2025-09-271-1/+1
| | | | | | | | | | | | | The link-level address and the mbuf shall not overlap. Prefer memcmp() over bcmp() for slight performance gain. No functional change intended. Reviewed by: glebius MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D52345 (cherry picked from commit 51098f0529f0d1cc532512e0eae9bfcffb8e68e4)
* iflib: Set the get counter routine prior to attaching the interfaceZhenlei Huang2025-09-271-1/+1
| | | | | | | | | | | | | | | This ensures other threads, e.g. ioctl threads, see the correct counter routine once after the interface has been attached. This change partially reverts commit 23ac9029f96b, which for unclear reason moved setting the get counter routine after ether_ifattach(). Reviewed by: kbowling, kgalazka, #iflib Fixes: 23ac9029f96b Update iflib to support more NIC designs MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D50712 (cherry picked from commit ae7f8da8bf6ed0c4f0e9f0e95ae2b08abce54378)
* iflib: Make iflib_register() return voidZhenlei Huang2025-09-271-8/+3
| | | | | | | | | | | | It never fails since change [1]. No functional change intended. [1] aa3860851b9f net: Remove unneeded NULL check for the allocated ifnet Reviewed by: kbowling, #iflib MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D50713 (cherry picked from commit bb5135d0f2276e84b7abfcc481c92000647f68d4)
* bridge: Fix adding gif(4) interface assigned with IP addresses as bridge memeberZhenlei Huang2025-09-271-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | and fix assigning IP addresses to the gif(4) interface when it is a member of a if_bridge(4) interface. When setting the sysctl net.link.bridge.member_ifaddrs to 1, if_bridge(4) can eliminate unnecessary walk of the member list to determine whether the inbound unicast packets are for us or not. Well when a gif(4) interface is member of a if_bridge(4) interface, it acts as the tunnel endpoint to tunnel Ethernet frames over IP network, aka the EtherIP protocol, so the IP addresses configured on it are independent of the if_bridge(4) interface or other if_bridge(4) members, hence the sysctl net.link.bridge.member_ifaddrs should not have any influnce over gif(4) interfaces's behavior of assigning IP addresses. PR: 227450 Reported by: Siva Mahadevan <me@svmhdvn.name> Reviewed by: ivy, #bridge MFC after: 1 week Fixes: 0a1294f6c610 bridge: allow IP addresses on members to be disabled Differential Revision: https://reviews.freebsd.org/D52200 (cherry picked from commit 9764aa1ccad08a7ec53ed9b80741b9553f3fa4e6)
* EtherIP: Fix passing the address family from if_bridge(4) to gif(4)Zhenlei Huang2025-09-272-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | Given IPPROTO_IPV4, IPPROTO_IPV6 and IPPROTO_ETHERIP have different protocol numbers, then it is perfect valid to tunnel IPv4, IPv6 and Ethernet traffic over IPv[46] by the same interface. Since gif(4) has already utilized the inbound csum_data field to carry address family, also teach if_bridge(4) to do that, rather than checking if a gif(4) interface is member of a if_bridge(4) interface. Without this fix, tunnel IPv[46] over IPv[46] will not work when the gif(4) interface is member of a if_bridge(4) interface, aka the EtherIP setup, as the address family passed from gif_output() will be overwritten with the wrong one AF_LINK by gif_transmit(), and end up with incorrectly encapsulated packets. PR: 227450 Reviewed by: kp Tested by: meta Fixes: 8a0308722372 gif(4): Assert that gif_output() isn't called for EtherIP MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D51682 (cherry picked from commit f4744b8acb932fbb3e48b71d31b7cd585566b668)
* sys: add MBIM (mobile broadband interface module) interface type.Pierre Pronchery2025-09-151-0/+1
| | | | | | | | | | | This is part of the upcoming USB umb(4) work. PR: 263783 Approved by: adrian, zlei Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D48167 (cherry picked from commit 86bfbaf1002c88b5c1a6d3ed261becedb533490b)
* 590493c1:Ronald Klop2025-09-131-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | if_epair(4): use ether_gen_addr(9) for stable MAC address Before this change epair interfaces get a random MAC. This does not help dhcp/dyndns when an epair gets destroyed/recreated after restart of a jail. With this change: $ sysctl net.link.epair.ether_gen_addr=0 $ ifconfig epair8 create > /dev/null; ifconfig epair8a | grep ether; ifconfig epair8b | grep ether; ifconfig epair8a destroy ether 02:cb:78:56:e4:0a ether 02:cb:78:56:e4:0b $ ifconfig epair8 create > /dev/null; ifconfig epair8a | grep ether; ifconfig epair8b | grep ether; ifconfig epair8a destroy ether 02:8b:9b:6a:8f:0a ether 02:8b:9b:6a:8f:0b $ sysctl net.link.epair.ether_gen_addr=1 $ ifconfig epair8 create > /dev/null; ifconfig epair8a | grep ether; ifconfig epair8b | grep ether; ifconfig epair8a destroy ether 58:9c:fc:10:2b:b4 ether 58:9c:fc:00:39:10 $ ifconfig epair8 create > /dev/null; ifconfig epair8a | grep ether; ifconfig epair8b | grep ether; ifconfig epair8a destroy ether 58:9c:fc:10:2b:b4 ether 58:9c:fc:00:39:10 A follow up commit will change the default to 1 in main. Approved by: bz,ivy,kp Relnotes: yes Differential Revision: https://reviews.freebsd.org/D51157 78537728: Document tunable net.link.epair.ether_gen_addr Approved by: hrs Fixes: 590493c1419092e98f7ad1dcadb886973502341e ("if_epair(4): use ether_gen_addr(9) for stable MAC address") Differential Revision: https://reviews.freebsd.org/D51861 (cherry picked from commit 590493c1419092e98f7ad1dcadb886973502341e) (cherry picked from commit 78537728efc5387558c97ba2730ce746d6259013)
* epair: don't include if_var.h twiceMichael Tuexen2025-09-051-1/+0
| | | | | | Sponsored by: Netflix, Inc. (cherry picked from commit f5dbf1b1c725da226fd45937decb5a5652ac1422)
* IfAPI: fix LINT-NOIP buildKa Ho Ng2025-09-033-12/+4
| | | | | | | | | | Also, reimplement the wrappers with __strong_reference macro. Fixes: 7b3094df479f Reported by: zlei Sponsored by: Juniper Networks, Inc. Reviewed by: zlei, jhibbits Differential Revision: https://reviews.freebsd.org/D52362
* IfAPI: restore KBI after bceb9c2f2b19Ka Ho Ng2025-09-032-0/+14
| | | | | | | | | This commit restores if_bpfmtap and if_etherbpfmtap functions, and implement them as wrappers around bpf_mtap_if and ether_bpf_mtap_if funcitons. Fixes: bceb9c2f2b19 Sponsored by: Juniper Networks, Inc.
* IfAPI: Retire if_etherbpfmtap() and if_bpfmtap()Justin Hibbits2025-09-032-14/+0
| | | | | | | | | | | | | | Summary: These came in the original DrvAPI commits in 2014, and are obsoleted by bpf_mtap_if() and ether_bpf_mtap_if(). The `_if` suffix, rather than prefix, conveys that it's operating on the bpf of the interface, instead than the interface itself. Reviewed by: glebius Sponsored by: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D41146 (cherry picked from commit 2a3716432d209c5fef1eb1a719f4c1914e7c8b5a)
* ifnet: Don't include ethernet.h twiceZhenlei Huang2025-09-011-1/+0
| | | | | | MFC after: 3 days (cherry picked from commit 393356f25fb8b76e38b10347f0ad40d4a23372ba)
* if_ovpn: support IPv6 link-local addressesKristof Provost2025-08-131-1/+20
| | | | | | | | MFC after: 3 weeks Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D51596 (cherry picked from commit 60e92d17cfeba02bc3c7a6edfa0bcaf7c63e5f35)
* if_ovpn: support floating clientsKristof Provost2025-08-132-1/+193
| | | | | | | | | | | | | | | | | If a client changes its IP address notify userspace of this. The UDP filtering function supplies the remote IP address, so we check if the address changed there. If so, we tag the packet with the new address. Once the packet is decrypted (and as part of that, has had its signature checked) we can commit to the address change. Take the write lock and notify userspace of the change. Reviewed by: markj MFC after: 3 weeks Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D51468 (cherry picked from commit 9c52600a5a150117b4396df3b868cf2516e1674c)
* if_ovpn: fill out sin_len/sin6_lenKristof Provost2025-08-131-0/+2
| | | | | | | | | | | When we parse an nvlist sockaddr we should set the sockaddr_in(6)'s length field. This isn't currently used by anything yet, but it's reasonable to expect a sockaddr to contain its length. MFC after: 3 weeks Sponsored by: Rubicon Communications, LLC ("Netgate") (cherry picked from commit e83df5367d30761803e09bd7fcf518638dfe43d2)
* if_ovpn: Destroy cloned interfaces via a prison removal callbackMark Johnston2025-08-131-8/+40
| | | | | | | | | | | | | | | | | | | | A if_ovpn interface carries a reference to a socket, which has a credential reference, which holds a reference on the containing prison and prevents SYSUNINITs from being invoked. So, register a PR_METHOD_REMOVE callback and destroy the cloner from there instead, since that mechanism doesn't require the prison refcount to drop to zero first. This fixes a bug where jails get left stuck in the DYING state after running if_ovpn regression tests. Reviewed by: kp MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D51526 (cherry picked from commit 96b29c7f0cffd377a757ad8ccc0cdd8fcb96d0dd)
* if_ovpn: Support multihomed server configurationsMark Johnston2025-08-051-6/+46
| | | | | | | | | | | | | | | | | | | | | | | | | In UDP server mode, openvpn implements the "multihome" option, which makes it avoid binding to an address. Instead, the server socket is bound to INADDR_ANY. Today, when configuring a new peer and setting the source address, sockaddr() returns the wildcard address, so the source address is implicitly determined by the output interface. This doesn't work as one would want if the WAN interface has multiple addresses and clients connect to non-primary addresses. Make multihome mode work properly: use the local address supplied by openvpn in preference to that of the socket. We still fetch the port number out of the socket. PR: 273664 Reviewed by: kp MFC after: 1 month Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D51498 (cherry picked from commit 05b5d56c540335ed17acf843810901338bf862d5)
* if_ovpn: Assert that udp_set_kernel_tunneling() succeedsMark Johnston2025-08-051-0/+1
| | | | | | | | | | | | We do this elsewhere, so copy the pattern here. Reviewed by: kp MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D51496 (cherry picked from commit a7dfc570f2747668b2fdd8fde6e1954fcedb2378)
* if_ovpn: Destroy the datapath lock when destroying a cloneMark Johnston2025-08-051-0/+1
| | | | | | | | | | Reviewed by: kp MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D51495 (cherry picked from commit 9bc6980bdf57432ee8519a3707423f410c5ec639)
* if_ovpn: Sprinkle const over some helper functionsMark Johnston2025-08-051-5/+6
| | | | | | | | | | | | No functional change intended. Reviewed by: kp MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D51494 (cherry picked from commit 2ff1587e3803e76a9726e1734181a5170079ddbe)
* if_ovpn: Remove an unused field from struct ovpn_kkey_dirMark Johnston2025-08-051-1/+0
| | | | | | | | | | | | No functional change intended. Reviewed by: kp MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D51493 (cherry picked from commit 3d3add7d43adb891ec054ec3f1c3d6d20b78dca8)
* Internal scheduling priorities: Always use symbolic onesOlivier Certner2025-07-281-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Replace priorities specified by a base priority and some hardcoded offset value by symbolic constants. Hardcoded offsets prevent changing the difference between priorities without changing their relative ordering, and is generally a dangerous practice since the resulting priority may inadvertently belong to a different selection policy's range. Since RQ_PPQ is 4, differences of less than 4 are insignificant, so just remove them. These small differences have not been changed for years, so it is likely they have no real meaning (besides having no practical effect). One can still consult the changes history to recover them if ever needed. No functional change (intended). MFC after: 1 month Event: Kitchener-Waterloo Hackathon 202506 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D45390 (cherry picked from commit 8ecc41918066422d6788a67251b22d11a6efeddf)
* lagg: Fix if_hw_tsomax_update() not being calledAndrew Gallatin2025-07-261-0/+1
| | | | | | | | | | | | In a mixed lagg, its likely that ifcaps or hwassist may not match between members. If this is true, the logical OR will be short-circuited and if_hw_tsomax_update() will not be called. Fix this by calling it inside the body of the if as well Sponsored by: Netflix (cherry picked from commit 78bdaa57cfbac759a6d79ecad2fae570e294a4b3)
* if_vlan: Fix up if_type before attaching the interfaceZhenlei Huang2025-07-071-1/+1
| | | | | | | | | | | | | | | | | | | | ether_ifattach() does not touch if_type, so it is not mandatory to fix the if_type after ether_ifattach(). Without this change, the event listeners, e.g. netlink, will see wrong interface type IFT_ETHER rather than the correct one IFT_L2VLAN. There is also a potential race that other threads see inconsistent interface type, i.e. initially IFT_ETHER and eventually IFT_L2VLAN. As a nice effect, this change eliminates the memory allocation for if_hw_addr, as vlan(4) interfaces do not support setting or retrieving the hardware MAC address yet [1]. [1] ddae57504b79 Persistently store NIC's hardware MAC address, and add a way to retrive it MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D50914 (cherry picked from commit a19b353d354d4ef808965c53253103cb6e7e6708)
* ifnet: Eliminate unnecessary synchronization of the interface index in the ↵Zhenlei Huang2025-07-071-15/+0
| | | | | | | | | | | | | | | | | | link layer address Change 80e60e236d85 made the if_index global, and for the whole lifecycle of an interface its index never changes, then there is no need to synchronize the interface index in the link layer address when moving interfaces from one vnet to another. No functional change intended. Reviewed by: glebius Fixes: 80e60e236d85 ifnet: make if_index global MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D50975 (cherry picked from commit 0b4c4833ee3eab0ce46b3bdbf054bca4b6bb7429)
* ethernet: Set maximum Ethernet header length based on the capability ↵Zhenlei Huang2025-07-071-1/+2
| | | | | | | | | | | | | | IFCAP_VLAN_MTU Lots of Ethernet drivers fix the header length after ether_ifattach(). Well since the net stack can conclude it based on the capability IFCAP_VLAN_MTU, let the net stack do it rather than individual drivers. Reviewed by: markj, glebius MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D50846 (cherry picked from commit 6ce8fd1978a9526ff0dc02ed98ef797f9154ec1f)
* bridge: Remove a redundant assignment of if_typeZhenlei Huang2025-07-071-1/+0
| | | | | | | | | | | | | ether_ifattach() no longer sets if_type to IFT_ETHER and keeps it as is since the change [1]. [1] fc74a9f93a5f Stop embedding struct ifnet at the top of driver softcs No functional change intended. MFC after: 1 week (cherry picked from commit a07604e6264b88222941fa61c6f989bad5490765)
* iflib: Some style(9) tweaksZhenlei Huang2025-07-071-104/+104
| | | | | | | | | Prefer tab over eight whitespaces for indentation, and four spaces as second level idents. MFC after: 3 days (cherry picked from commit 721e783a2a3316826f92fb44c931e28163118b3f)
* if_firewire: Make firewire_broadcastaddr static constZhenlei Huang2025-07-071-2/+2
| | | | | | | | | | | This global variable is used only in this file. While here, constify it since it is only used to read. No functional change intended. MFC after: 1 week (cherry picked from commit 517eb20e54e59173b9dbede0bb3356f6197b5aa9)
* ifnet: Initialize the address family dependent data region earlierZhenlei Huang2025-07-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | if_link_ifnet() adds the interface to the global network interface list, and it is a natural synchronization point. With this change, any threads that obtain the reference of the interface via ifunit(), ifunit_ref() etc., will be guaranteed to see the address family dependent data rightly. The issue [1] reported by Mike Belanger also hints the potential race. MFC note: this change depends on e64fe5ad3a23, as calculating the max IPv6 MTU through all the interfaces requires the current interface to be added to the global network interface list firstly. [1] https://lists.freebsd.org/archives/freebsd-net/2025-May/006817.html Reviewed by: glebius MFC after: 1 month MFC with: e64fe5ad3a23 netinet6: Remove a set but not used global variable in6_maxmtu Differential Revision: https://reviews.freebsd.org/D49358 (cherry picked from commit 098b5d4dc744283a90b2d80c11395ecc18a84084)
* if_vlan_var.h: fix value of DOT1Q_VID_MAXLexi Winter2025-06-291-1/+1
| | | | | | | | | | | | | This should be 4094 (0xFFE), not 4095 (0xFFF), since 0xFFF is not a valid VID. Fixes: c59492025073 ("sys/net: add DOT1Q_VID_{MIN,MAX}") MFC after: 3 days Reviewed by: kevans, kp, adrian Approved by: kevans (mentor) Differential Revision: https://reviews.freebsd.org/D50576 (cherry picked from commit d9b6b10e5ebbb517a079e89ac0de99be3b815c8d)
* bridge: fix vlan(4) on a bridge memberLexi Winter2025-06-181-13/+10
| | | | | | | | | | | | | | | | | | | | | | | | If an interface is a bridge member, and a vlan(4) is also created on that interface, and net.link.bridge.member_ifaddrs=0, then vlan(4) will never see any incoming frames because bridge doesn't pass them to the host for processing. Work around this by checking for locally-addressed frames using the MAC address of the interface we received the frame on, but only if the frame has a .1q tag and there's a vlan trunk on the interface. This behaviour is almost certainly "wrong" and it's not clear if we really want to support this, but it did work in the past and the member_ifaddrs change was not supposed to break it, so this restores the previous behaviour. PR: 287150 MFC after: 1 week Reviewed by: kevans, des Approved by: kevans (mentor), des (mentor) Differential Revision: https://reviews.freebsd.org/D50623 (cherry picked from commit a5fe142e08447c7116b89159c110d02e860ac6a1)
* net: bandaid for plugging a fw_com leak in fwip_detach()Tai-hwa Liang2025-06-121-0/+1
| | | | | | | | | | | | | | | | | | | | | Adding a temporary workaround for plugging a fw_com upon if_fwip unloading. Steps to reproduce(needs two hosts connected with firewire): while true; do ifconfig fwip0 10.0.0.5 up fwcontrol -r ping -c 10.0.0.3 kldunload if_fwip done There's a chance that the unloading of if_fwip.ko triggers following warning: Warning: memory type fw_com leaked memory on destroy (1 allocations, 64 bytes leaked). commit d79b6b8ec267e7eef6e07cf4245159705e24acd5 (origin/main, origin/HEAD) (cherry picked from commit 25a5bb7318052322190a2880e0e7ef18e06d54bd)
* pf: fix panic in pf_return()Kristof Provost2025-06-061-2/+4
| | | | | | | | | | | | | | | We (correctly) NULL out sk and nk before calling pf_return(), but that function still tried to use them to undo NAT transformations. Store the old port numbers and use those rather than sk/nk. This is a partial import of e11dacbf8484adc7bbb61b20fee3ab8385745925 (osport/odport), and the missing parts of bdea9cbcf2decafeb4da5a0280313efccc09e1b3. Direct commit to stable/14. PR: 287254
* ifnet: Integrate if_unroute() into if_down()Zhenlei Huang2025-06-011-21/+8
| | | | | | | | | | | | | | | if_unroute() is static since 2004 and is not used anywhere except for if_down(). This also makes it easier to grep by the pattern `if_flags &= ~IFF_UP`. No functional change intended. Reviewed by: glebius MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D49356 (cherry picked from commit 0693c3f7cb3d9e5389863a0c131ddef799c77091)
* ifnet: Fix a typo in a source code commentZhenlei Huang2025-06-011-1/+1
| | | | | | | | - s/possiable/possible MFC after: 3 days (cherry picked from commit ad2d7e594f6d519be6e9674c8048a406a453fef9)
generated by cgit v1.3 (git 2.53.0) at 2026-04-18 08:07:51 +0000