qlnxe(4) not loaded during installation
Is there any reason to not have qlnxe(4) available during installation? I can of course load it from the shell, but what is the reason to not have it available like others drivers? Is this maintained? Benoît
Problem reports for n...@freebsd.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- In Progress |221146 | [ixgbe] Problem with second laggport New |204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New |213410 | [carp] service netif restart causes hang only whe Open| 7556 | ppp: sl_compress_init() will fail if called anyth Open|193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open|202510 | [CARP] advertisements sourced from CARP IP cause Open|207261 | netmap: Doesn't do TX sync with kqueue Open|73 | igb(4): Kernel panic (fatal trap 12) due to netwo Open|225438 | panic in6_unlink_ifa() due to race Open|227720 | Kernel panic in ppp server Open|236888 | ppp daemon: Allow MTU to be overridden for PPPoE Open|237072 | netgraph(4): performance issue [on HardenedBSD]? Open|237840 | Removed dummynet dependency on ipfw Open|237973 | pf: implement egress keyword to simplify rules ac Open|238324 | Add XG-C100C/AQtion AQC107 10GbE NIC driver Open|238707 | Lock order reversal: rtentry vs "nd6 list" Open|240944 | em(4): Crash with Intel 82571EB NIC with AMD Pile Open|241106 | tun/ppp: panic: vm_fault: fault on nofault entry Open|241162 | Panic in closefp() triggered by nginx (uwsgi with Open|241191 | route flush panic with RADIX_MPATH Open|243463 | ix0: Watchdog timeout Open|247111 | pxeboot very slow with i219LM Open|257709 | netinet6: Set net.inet6.icmp6.nodeinfo default to Open|118111 | rc: network.subr Add MAC address based interface 24 problems total for which you should take action.
Re: Import dhcpcd(8) into FreeBSD base
On Wed, 10 Aug 2022, at 8:46 AM, Ben Woods wrote: > > I agree with the plan also - Import dhcpcd with its dedicated rc.d > script (build enabled with runtime off by default, but manually enabled > by dhcpcd_enable=“YES”). > > No need to change the rc or network.subr system for now, as dhclient > and rtsold are already off by default (or if enabled by default will be > possible to disable in rc.conf). > > No need to have plans to remove dhclient/rtsold now - let’s give people > the option for now, with no plan to necessarily remove dhclient/rtsold. > > Hiroki - I’ll update my phabricator review to align with the above. > > Regards, > Ben > > -- > From: Ben Woods > woods...@freebsd.org Ok, I believe I now have this in a state which is ready to land in FreeBSD, and would welcome any comments before doing so. Also, as previously mentioned, I have a ports commit bit, so would need a src committer to approve me committing or commit on my behalf. I have 2 differential reviews for this: https://reviews.freebsd.org/D36196 - Create vendor branch vendor/dhcpcd https://reviews.freebsd.org/D22012 - Import dhcpcd into FreeBSD base The first review is new, and I’m not sure if it is normal to review vendor branch creations, but at a minimum I need approval to do so. The second review has now been updated to remove any changes to rc scripts other than adding the new /etc/rc.d/dhcpcd. It is built/installed by default, but not run by default. Do people think there should be a WITH_DHCPCD build knob (on by default) to allow it to not be built (e.g. save space on embedded systems)? Regards, Ben -- From: Ben Woods woods...@freebsd.org
Re: Import dhcpcd(8) into FreeBSD base
Hi Roy, I appreciate your answers. More inline below. > On 8. Aug 2022, at 12:42, Roy Marples wrote: > > Both dhclient and rtsold are only activated manually. > For dhclient there is an exponential backoff after each message is sent. If > the messages go nowhere (ie LINK_STATE_DOWN) then this delays the > configuration aquisition and can slow down the boot process. > For rtsold this is actually quite tricky as it requires a working LL address > before it can work. > This leads to sleep commands in rc which results in a slower than optimal > boot time. While there are true they do pertain to RC integration in FreeBSD. I know because other projects have improved the situation with the tools at hand. > dhcpcd reacts to state changes - however FreeBSD does not announce all state > changes needed for this. For example here is a changeset I made 6 years ago > for FreeBSD which allows this IPv6 addresses to announce state transitions > from TENTATIVE to non TENTATIVE/DUPLICATED here: > https://reviews.freebsd.org/D5469 Yes, this would be nice to have user space access to. :) > Any DHCPv6 client also needs either a sleep or the above state changes to be > made available. I agree there is no canonical way to watch for changes, especially for scripting duty around SLAAC. > There is a swathe of DHCP related RFC's that dhclient does not support, > although none are necessary to actually get a working configuration for most > users. That could be. 6RD through DHCP is tricky for example. But on the other hand we do have a lot of people using routers and direct ISP connectivity and do encounter the most visible issues here which in my opinion you cannot see from a home lab or traditional "network server" FreeBSD use case. > rtsold (in FreeBSD-13 at least) has no mechanism to get RDNSS and DNSSL > options from RA messages into the local nameserver. I may be mistaken, but the -R option should take care of this and seems to be enabled by default invoking resolvconf(8). I think this has been the case for a number of major iterations before FreeBSD 13. > dhclient and FreeBSD kernel RA handling do not support a predictable > configuration for multi-homed boxes. It operates on a first come, first > served basis. That's due to dhclient-script handling, sort of like the RC integration issue mentioned before. > dhcpcd supports a predictable configuration allowing a "better" interface to > take over the default route, preferred nameservers, etc. That does sound nice for integration. Thanks for confirming. > There's no proposal to remove dhclient or rtsold yet. To be fair, that was the original proposal. If dhclient and rtosold are not removed and made second class citizens in FreeBSD that amounts to the same bitrot and neglect that we would see if it would be taken out of the base system. Just my concerns here. I'm sure people will find a way. :) Cheers, Franco
Tunnel interfaces and vnet boundary crossing
Hi, some time ago I managed to design and implement multi-tenant OpenVPN server using vnet jails. This way I am able to use more OpenVPN instances on single public IP. This is made possible using tun/tap interface property allowing to cross vnet boundary - here is part of my initialisation command sequence for one instance: jail -c name=ov1 vnet persist jexec ov1 hostname -s ov1 jexec ov1 ifconfig lo0 127.0.0.1/8 jexec ov1 sysctl net.inet.ip.forwarding=1 ifconfig tun1 create vnet ov1 /usr/local/sbin/openvpn --cd /usr/local/etc/openvpn --daemon ov1 --config ov1.cfg --writepid /var/run/ov1.pid In ov1.cfg, relevant bits are port 1001 management localhost 2001 dev tun1 (Actual numbers are different, but important thing is how they relate together.) This way, OpenVPN process runs in base vnet, using one side of pre-created tun/tap interface, while networking uses the other side of this interface in child vnet, isolated from base vnet (and other OpenVPN instances as well). Presently, I am using vlan interfaces on one ethernet interface to connect individual instances to their respective local network. I'd like to replace this with some tunnel interface (gif, gre, ideally ipsec secured). The best way to illustrate is using Cisco config snippet: interface Tunnel1 vrf forwarding vrf1 ip address 192.168.0.1 255.255.255.252 tunnel source Loopback0 tunnel destination 172.16.0.1 This means outer layer uses base route table for tunnel creation, while inner layer, packets/datagrams transferred over tunnel, use other vrf. I tried to mimic this in FreeBSD with following commands: ifconfig gre1 create tunnel 172.16.1.1 172.16.0.1 vnet ov1 jexec ov1 ifconfig gre1 10.1.0.2/30 10.1.0.1 This does not work. I found some older post which made me believing this is caused by clearing whole tunnel configuration after moving interface into different vnet. My (failed) tests indicate this is most probably the cause. So, my question is, does anybody use tunnel interface similar way? Is it possible to achieve what I am trying with netgraph? I am able to create some inter-vnet link using epair interface, but this is something different. Or ideally, is somebody using IPSEC with VNET jails, processing encapsulating packets in base and raw content in some child vnet? Regards, Milan
