#
97d55ad4 |
|
17-Apr-2023 |
Augustin Cavalier <waddlesplash@gmail.com> |
freebsd_network: Add missing LOCKGIANT to the close() hook. Should fix #18363.
|
#
78eb4676 |
|
30-Jan-2023 |
Augustin Cavalier <waddlesplash@gmail.com> |
freebsd_network: NULL-check if_init before calling. All FreeBSD drivers set it; not all OpenBSD drivers do.
|
#
44fa45df |
|
13-Jun-2022 |
Augustin Cavalier <waddlesplash@gmail.com> |
net/if: Drop ifmediareq and just use the regular ifreq for SIOCGIFMEDIA. This was introduced into the main API in 2010 (d72ede75fb252c24c8a5fcc39395f9ae1c202322), but was actually only fully used for the past month (c2a9a890f3ac7795602d11c0edaa20ac2db48202) when SIOCGIFMEDIA was supported for all *BSD drivers and not just WiFi. Most userland consumers of this structure did not use it correctly, as was the case in #17770, and only worked because in the fallback case the network stack just treated it as if it were an ifreq. Nothing actually used the ifm_count/ifm_ulist (though tentative APIs were exposed for it) as noted by previous commits; and the fact that Haiku's IFM_* declarations are so spartan makes most of the returned values unintelligible to userland without using FreeBSD compat headers. If, in the future, we decide to implement ifmedia listing and selection properly, that should likely be done with separate ioctls instead of having multi-function ones like this. This is technically an ABI break, but in practice it should not matter: ifmediareq::ifm_current aligns with ifreq::ifr_media, so the things that used this structure like our in-tree code did will continue to work. Until this past May, the only other field that was usually set was ifm_active, but in the absence of setting ifm_status all non-Haiku consumers should ignore it completely. The only consumer of this ioctl that I know of out of the tree, wpa_supplicant, still works after these changes.
|
#
ecf18ba4 |
|
13-Jun-2022 |
Augustin Cavalier <waddlesplash@gmail.com> |
freebsd_network: Cleanup around ifmedia handling. * Remove unused variable. * Use original value for IFM_AVALID, we do not need to remap this one. (Actually we do not need to remap IFM_ACTIVE here either, but it makes some things slightly easier to work with rather than remapping it in a different location.)
|
#
8548a4ad |
|
12-May-2022 |
Augustin Cavalier <waddlesplash@gmail.com> |
freebsd_network: Adaptations in preparation for the OpenBSD layer. Most of these changes however add things that FreeBSD has (with a few exceptions noted in comments) which the OpenBSD shim layer merely needs to make use of. (FreeBSD used to have support for IFF_NEEDSGIANT but removed it. The support instated here is very similar to what FreeBSD used to have.)
|
#
44d08ffc |
|
07-Jun-2022 |
Augustin Cavalier <waddlesplash@gmail.com> |
freebsd_network: Add another MTU to attempt to set devices to. IEEE 802.11 has its own maximum MTU which is smaller than PAGESIZE but larger than the ETHERMTU default. So we now attempt to set this as well. In doing so, refactor the set into a loop based off an array of possible MTUs.
|
#
d765574f |
|
07-Jun-2022 |
Augustin Cavalier <waddlesplash@gmail.com> |
freebsd_network: Adjust too-large packet handling in read(). Before ca6a44c1333c467706a7ceae2842d0de380139cb, this function returned whatever amount of the buffer it could and silently discarded the rest. After that change and before this one, it would refuse to return anything, which meant that as soon as we got one packet too large to handle, we would never receive any more packets (and the errors displayed in e.g. ifconfig would go up forever.) Now, we discard too-large packets so RX will not stall completely and still return E2BIG (so error counts will go up), but we also print an error to syslog, so that precisely what has gone wrong will be easily known.
|
#
44604448 |
|
27-May-2022 |
Augustin Cavalier <waddlesplash@gmail.com> |
freebsd_network: Automatically switch to jumbo-sized MTUs if possible. Unfortunately there is no way to ask if a device supports jumbo MTUs besides actually activating it. But that's fine, because for now, Haiku's own network stack does not actually support changing MTUs at the device level! Probably that should be fixed, too, but that is a problem for another day. With preceding commits, this fixes #17728, and all BSD network drivers will use jumbo frames if possible by default.
|
#
ca6a44c1 |
|
27-May-2022 |
Augustin Cavalier <waddlesplash@gmail.com> |
freebsd_network: Overhaul device read/write functions. * In read, check that we actually have enough buffer capacity to read the next buffer on the queue. Otherwise return E2BIG. (This fixes data being silently discarded if the mbuf was larger than the passed read buffer, but that should not usually happen anyway based on MTU buffer sizing.) * In write, use m_get2 to get an appropriately sized mbuf (which may be up to 16K) instead of clamping all writes to the cluster size. These changes are needed for jumbo-frames to be actually read and written as one unit. However, they are not yet enabled, as more changes are needed above this point both in ioctl() here and in the stack.
|
#
c2a9a890 |
|
05-May-2022 |
Alexander von Gluck IV <kallisti5@unixzen.com> |
compat/freebsd_network: Catch BSD socket ioctl and act on within stack Change-Id: Iaf7e645836ffee58b3a8a8e5352048412035ab32 Reviewed-on: https://review.haiku-os.org/c/haiku/+/5296 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
b943b993 |
|
30-Nov-2020 |
Jérôme Duval <jerome.duval@gmail.com> |
freebsd_network: Use user_memcpy() for ETHER_ADDMULTI/ETHER_REMMULTI Change-Id: Id0a7e50f9ae38bff42faf1d6c4a62f702347bda3 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3446 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
a3dc96a3 |
|
23-Nov-2019 |
Augustin Cavalier <waddlesplash@gmail.com> |
freebsd_network: Use ifmedia_baudrate to compute the link speed. This is much more accurate than testing only 2 IFM_* types.
|
#
56cb682b |
|
22-Nov-2019 |
Augustin Cavalier <waddlesplash@gmail.com> |
freebsd_network: Moderate reorganization. * Rename device.c to device_hooks.c, as this is what it really contains. * Rename compat.c to device.c, as it implements the generic "device" related functions, both for compat layer internals and FreeBSD public ones. * Move malloc and related operations out of the now-device.c, and place them in a new "malloc.cpp", which also incorporates compat_cpp.cpp. No functional change intended.
|