Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On Tue, Jun 4, 2024 at 5:18 PM Alan Somers wrote: > > CAUTION: This email originated from outside of the University of Guelph. Do > not click links or open attachments unless you recognize the sender and know > the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca. > > > On Tue, Jun 4, 2024 at 3:52 PM John Hixson wrote: > > > > On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote: > > > On 16/06/2022 15:56, Rick Macklem wrote: > > > > Miroslav Lachman <000.f...@quip.cz> wrote: > > > > > On 24/01/2022 16:13, Rick Macklem wrote: > > > > > > > > > [...] > > > > > > > > > > > So, I think Mark and Yuri are correct and looking at up to date > > > > > > Illumos sources is the next step. > > > > > > (As I mentioned, porting the Apple sources is beyond what I am > > > > > >willing to attempt.) > > > > > > > > > > > > rick > > > > > > > > > > Hello Rick, > > > > > I would like to ask you I there is some progress with porting newer > > > > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a > > > > > possibility where to start porting? > > > > Yes. I have the stuff off Illumos-gate, which I think is pretty > > > > up-to-date > > > > and I agree that it should be easier than the Apple stuff to port into > > > > FreeBSD. I don't think it is "straightforward" as someone involved > > > > with Illumos said, due to the big differences in VFS/locking, but... > > > > > > > > Having said the above, I have not done much yet. I've been cleaning up > > > > NFS stuff, although I am nearly done with that now. > > > > I do plan on starting to work on it soon, but have no idea if/when I > > > > will have something that might be useful for others. > > > > > > I'm glad to hear that. > > > > > > > > We have more and more problems with current state of mount_smbfs. I > > > > > would be really glad if "somebody" can do the heroic work of > > > > > implementing SMBv2 in FreeBSD. > > > > > Maybe it's time to start some fundraising for sponsoring this work? > > > > Well, funding isn't an issue for me (I'm just a retired guy who does > > > > this > > > > stuff as a hobby). However, if there is someone else who is capable of > > > > doing it if they are funded, I have no problem with that. > > > > I could either help them, or simply stick with working on NFS and leave > > > > SMBv23 to them. > > > > > > > > Sorry, but I cannot report real progress on this as yet, rick > > > > > > No need to sorry. I really appreciate your endless work on NFS and that > > > you > > > still have kind of interest to try porting SMBv2/3. > > > Unfortunately I don't know anybody else trying to do this tremendous work. > > > > > > > I am working on a from scratch implementation of smbfs. I do not have > > any kind of time estimate since it is in my spare time. I chose this > > route after spending considerable time looking at Apple and Solaris > > implementations and wanting something without all of the legacy 1.0 > > crap. I do have a very minimal working FUSE version at this point, but > > there is much to do, and even more to abide by the various > > specifications. > > > > I just thought I'd share in case anyone is interested. Best of luck with it. I never got far into porting the Illumos code. rick > > > > - John > > I am indeed interested. smbfs is an important feature to have. Let > me know if you need help with the fuse parts. > -Alan
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On Tue, Jun 4, 2024 at 3:52 PM John Hixson wrote: > > On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote: > > On 16/06/2022 15:56, Rick Macklem wrote: > > > Miroslav Lachman <000.f...@quip.cz> wrote: > > > > On 24/01/2022 16:13, Rick Macklem wrote: > > > > > > > [...] > > > > > > > > > So, I think Mark and Yuri are correct and looking at up to date > > > > > Illumos sources is the next step. > > > > > (As I mentioned, porting the Apple sources is beyond what I am > > > > >willing to attempt.) > > > > > > > > > > rick > > > > > > > > Hello Rick, > > > > I would like to ask you I there is some progress with porting newer > > > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a > > > > possibility where to start porting? > > > Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date > > > and I agree that it should be easier than the Apple stuff to port into > > > FreeBSD. I don't think it is "straightforward" as someone involved > > > with Illumos said, due to the big differences in VFS/locking, but... > > > > > > Having said the above, I have not done much yet. I've been cleaning up > > > NFS stuff, although I am nearly done with that now. > > > I do plan on starting to work on it soon, but have no idea if/when I > > > will have something that might be useful for others. > > > > I'm glad to hear that. > > > > > > We have more and more problems with current state of mount_smbfs. I > > > > would be really glad if "somebody" can do the heroic work of > > > > implementing SMBv2 in FreeBSD. > > > > Maybe it's time to start some fundraising for sponsoring this work? > > > Well, funding isn't an issue for me (I'm just a retired guy who does this > > > stuff as a hobby). However, if there is someone else who is capable of > > > doing it if they are funded, I have no problem with that. > > > I could either help them, or simply stick with working on NFS and leave > > > SMBv23 to them. > > > > > > Sorry, but I cannot report real progress on this as yet, rick > > > > No need to sorry. I really appreciate your endless work on NFS and that you > > still have kind of interest to try porting SMBv2/3. > > Unfortunately I don't know anybody else trying to do this tremendous work. > > > > I am working on a from scratch implementation of smbfs. I do not have > any kind of time estimate since it is in my spare time. I chose this > route after spending considerable time looking at Apple and Solaris > implementations and wanting something without all of the legacy 1.0 > crap. I do have a very minimal working FUSE version at this point, but > there is much to do, and even more to abide by the various > specifications. > > I just thought I'd share in case anyone is interested. > > - John I am indeed interested. smbfs is an important feature to have. Let me know if you need help with the fuse parts. -Alan
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
> > Thank you for the message. I'm glad someone has the courage to take the > plunge. Smbfs is still very important to me. In a heterogeneous environment > it is still the most common way to share data between systems. > Are you planning the final version as a kernel module, or will the final > version be via FUSE? I have had bad experiences with FUSE in the past with > stability and performance. The final version will be a kernel module. It will also be BSD licensed. I am not an expert at the VFS layer so I want to get the stack ironed out in FUSE before moving it into kernel space. - John signature.asc Description: PGP signature
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On 04/06/2024 23:52, John Hixson wrote: On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote: On 16/06/2022 15:56, Rick Macklem wrote: Miroslav Lachman <000.f...@quip.cz> wrote: On 24/01/2022 16:13, Rick Macklem wrote: [...] So, I think Mark and Yuri are correct and looking at up to date Illumos sources is the next step. (As I mentioned, porting the Apple sources is beyond what I am willing to attempt.) rick Hello Rick, I would like to ask you I there is some progress with porting newer SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a possibility where to start porting? Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date and I agree that it should be easier than the Apple stuff to port into FreeBSD. I don't think it is "straightforward" as someone involved with Illumos said, due to the big differences in VFS/locking, but... Having said the above, I have not done much yet. I've been cleaning up NFS stuff, although I am nearly done with that now. I do plan on starting to work on it soon, but have no idea if/when I will have something that might be useful for others. I'm glad to hear that. We have more and more problems with current state of mount_smbfs. I would be really glad if "somebody" can do the heroic work of implementing SMBv2 in FreeBSD. Maybe it's time to start some fundraising for sponsoring this work? Well, funding isn't an issue for me (I'm just a retired guy who does this stuff as a hobby). However, if there is someone else who is capable of doing it if they are funded, I have no problem with that. I could either help them, or simply stick with working on NFS and leave SMBv23 to them. Sorry, but I cannot report real progress on this as yet, rick No need to sorry. I really appreciate your endless work on NFS and that you still have kind of interest to try porting SMBv2/3. Unfortunately I don't know anybody else trying to do this tremendous work. I am working on a from scratch implementation of smbfs. I do not have any kind of time estimate since it is in my spare time. I chose this route after spending considerable time looking at Apple and Solaris implementations and wanting something without all of the legacy 1.0 crap. I do have a very minimal working FUSE version at this point, but there is much to do, and even more to abide by the various specifications. I just thought I'd share in case anyone is interested. Thank you for the message. I'm glad someone has the courage to take the plunge. Smbfs is still very important to me. In a heterogeneous environment it is still the most common way to share data between systems. Are you planning the final version as a kernel module, or will the final version be via FUSE? I have had bad experiences with FUSE in the past with stability and performance. Best regards Miroslav Lachman
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote: > On 16/06/2022 15:56, Rick Macklem wrote: > > Miroslav Lachman <000.f...@quip.cz> wrote: > > > On 24/01/2022 16:13, Rick Macklem wrote: > > > > > [...] > > > > > > > So, I think Mark and Yuri are correct and looking at up to date > > > > Illumos sources is the next step. > > > > (As I mentioned, porting the Apple sources is beyond what I am > > > >willing to attempt.) > > > > > > > > rick > > > > > > Hello Rick, > > > I would like to ask you I there is some progress with porting newer > > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a > > > possibility where to start porting? > > Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date > > and I agree that it should be easier than the Apple stuff to port into > > FreeBSD. I don't think it is "straightforward" as someone involved > > with Illumos said, due to the big differences in VFS/locking, but... > > > > Having said the above, I have not done much yet. I've been cleaning up > > NFS stuff, although I am nearly done with that now. > > I do plan on starting to work on it soon, but have no idea if/when I > > will have something that might be useful for others. > > I'm glad to hear that. > > > > We have more and more problems with current state of mount_smbfs. I > > > would be really glad if "somebody" can do the heroic work of > > > implementing SMBv2 in FreeBSD. > > > Maybe it's time to start some fundraising for sponsoring this work? > > Well, funding isn't an issue for me (I'm just a retired guy who does this > > stuff as a hobby). However, if there is someone else who is capable of > > doing it if they are funded, I have no problem with that. > > I could either help them, or simply stick with working on NFS and leave > > SMBv23 to them. > > > > Sorry, but I cannot report real progress on this as yet, rick > > No need to sorry. I really appreciate your endless work on NFS and that you > still have kind of interest to try porting SMBv2/3. > Unfortunately I don't know anybody else trying to do this tremendous work. > I am working on a from scratch implementation of smbfs. I do not have any kind of time estimate since it is in my spare time. I chose this route after spending considerable time looking at Apple and Solaris implementations and wanting something without all of the legacy 1.0 crap. I do have a very minimal working FUSE version at this point, but there is much to do, and even more to abide by the various specifications. I just thought I'd share in case anyone is interested. - John signature.asc Description: PGP signature
Re: gcc behavior of init priority of .ctors and .dtors section
On 5/16/24 4:05 PM, Lorenzo Salvadore wrote: On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov wrote: gcc13 from ports `# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3 fini 4 fini 5 fini 2 fini 1` The above order is not expected. I think clang's one is correct. Further hacking with readelf shows that clang produces the right order of section .rela.ctors but gcc does not. ``` # clang -fno-use-init-array -c ctors.c && readelf -r ctors.o | grep 'Relocation section with addend (.rela.ctors)' -A5 > clang.txt # gcc -c ctors.c && readelf -r ctors.o | grep 'Relocation section with addend (.rela.ctors)' -A5 > gcc.txt # diff clang.txt gcc.txt 3,5c3,5 < 00080001 R_X86_64_64 0060 init_65535_2 + 0 < 0008 00070001 R_X86_64_64 0040 init + 0 < 0010 00060001 R_X86_64_64 0020 init_65535 + 0 --- 00060001 R_X86_64_64 0011 init_65535 + 0 0008 00070001 R_X86_64_64 0022 init + 0 0010 00080001 R_X86_64_64 0033 init_65535_2 + 0 ``` The above show clearly gcc produces the wrong order of section `.rela.ctors`. Is that expected behavior ? I have not tried Linux version of gcc. Note that init array vs. init function behavior is encoded by a note added by crt1.o. I suspect that the problem is that gcc port is built without --enable-initfini-array configure option. Indeed, support for .init_array and .fini_array has been added to the GCC ports but is present in the *-devel ports only for now. I will soon proceed to enable it for the GCC standard ports too. lang/gcc14 is soon to be added to the ports tree and will have it since the beginning. If this is indeed the issue, switching to a -devel GCC port should fix it. FWIW, the devel/freebsd-gcc* ports have passed this flag to GCC's configure for a long time (since we made the switch in clang). -- John Baldwin
Re: bridge: no traffic with vnet (epair) beyond bridge device
Am Tue, 04 Jun 2024 09:36:38 +0200 Alexander Leidinger schrieb: > Am 2024-06-03 21:02, schrieb FreeBSD User: > > Hello, > > > > I'm running a dual socket NUMA CURRENT host (Fujitsu RX host) running > > several jails. Jails are > > attached to a bridge device (bridge1), the physical device on that > > bridge is igb1 (i350 based > > NIC). The bridge is created via host's rc scripts, adding and/or > > deleting epair members of the > > bridge is performed by the jail.conf script. > > > > I do not know how long the setup worked, but out of the blue, last week > > after a longish > > poudriere run after updating the host to most recent CURRENT (as of > > today, latest update > > kernel and world) and performing "etcupdate" on both the host and all > > jails, traffic beyond > > the bridge is not seen on the network! All jails can communicate with > > each other. Traffic from > > the host itself is routed via igb0 to network and back via igb1 onto > > the bridge. > > > > I check all setups for net.link.bridge: > > > > net.link.bridge.ipfw: 0 > > net.link.bridge.log_mac_flap: 1 > > net.link.bridge.allow_llz_overlap: 0 > > net.link.bridge.inherit_mac: 0 > > net.link.bridge.log_stp: 0 > > net.link.bridge.pfil_local_phys: 0 > > net.link.bridge.pfil_member: 0 > > net.link.bridge.ipfw_arp: 0 > > net.link.bridge.pfil_bridge: 0 > > net.link.bridge.pfil_onlyip: 0 > > > > I did not change anything (knowingly). > > > > I also have an oldish box running single socket processor, also driven > > by the very same > > CURRENT and similar, but not identical setup. The box is running very > > well and the bridge is > > working as expected. > > > > I was wondering if something in detail has changed in the handling of > > jails, epair and > > bridges. I followed the setup "after the book", nothing suspicious. > > "after the book" = the IP of the host itself is not on igb1 but on a > different interface or on the bridge? > > Is there a firewall active on the box itself? Which one? > > What does wireshark / a traffic dump at the physical interface level > tell compared to a traffic dump at the switch interface? Did you replace > the cable / SFP / move to a different switch port as a test? > > I suggest to provide the output of ifconfig -a and netstat -rn (feel > free to mangle the IPs, as long as the mangling is a consistent > replacement and not a cut-off). > > Bye, > Alexander. > Hello Alexander and everybody brave enough reading my post. Somehow I managed it to let "ifconfig_igb1="up" disappear - I guess by accident when sneaking through the rc.conf file. igb1 is the physical device connecting to the network. The bridge is layer 2 only, no IP, only the vnet-portions pointing towards the jail do have IPv6 and IPv4. The bridge has around 20 members, the last entry is igb1 - I never checked whether it is up ... Sorry! Kind regards, oh -- O. Hartmann pgpEjETT1Jdg5.pgp Description: OpenPGP digital signature
Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error
On Tue, Jun 4, 2024 at 8:17 AM Gerrit Kühn wrote: > Am Tue, 28 May 2024 11:19:42 +0200 > schrieb Gerrit Kühn : > > > > Not sure if it will break your setup, but this already happened with > > > 13.2 (I cant recall the exact release). > > > I have two machines with onboard NICs (Supermicro H12SSL-CT mainboards) > > running just fine. One is 13.3, the other is 14.0. > > I have updated one system to 14.1 now, and it still works happily > (transferring lots of data in the background while typing this). So > whatever causes the issues you have seen with the BCM chipset, not all of > them appear to be affected. Maybe the firmware is making the difference > here? > I merged the next version of the driver from Broadcom to stable/14, but not 14.1 (it was too late by the time I got around to this). If there's still issues, maybe try stable/14? Warner > cu > Gerrit >
Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error
Am Tue, 28 May 2024 11:19:42 +0200 schrieb Gerrit Kühn : > > Not sure if it will break your setup, but this already happened with > > 13.2 (I cant recall the exact release). > I have two machines with onboard NICs (Supermicro H12SSL-CT mainboards) > running just fine. One is 13.3, the other is 14.0. I have updated one system to 14.1 now, and it still works happily (transferring lots of data in the background while typing this). So whatever causes the issues you have seen with the BCM chipset, not all of them appear to be affected. Maybe the firmware is making the difference here? cu Gerrit smime.p7s Description: S/MIME cryptographic signature
Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error
Hi everyone, just to follow up. I have found something interesting, at the moment I'm focusing on the issue related to the creation and deletion of sub-interfaces that trigger ALLOC/MASK errors and bricks the NIC ( not completely as the other port keeps working, this card has 2x10G). I have found the following: - If a port is down (let's say bnxt1) and sub-interfaces are created ( bnxt1.1100) then the port is activated (ifconfig bnxt1 up). this will trigger the issues of the filters and the card will not be able to be "programmed" again until the next reboot (not sure if there is any way to reset it, the devctl reset did not work). echo "Creating Interfaces and brick the card" ifconfig bnxt1.1011 create up fib 10 192.168.11.43/24 ifconfig bnxt1.1001 create up fib 11 192.168.12.43/24 ifconfig bnxt1.1002 create up fib 12 192.168.13.43/24 ifconfig bnxt1.1003 create up fib 13 192.168.14.43/24 ifconfig bnxt1.1004 create up fib 14 192.168.15.43/24 ifconfig bnxt1.1005 create up fib 15 192.168.16.43/24 ifconfig bnxt1 up --- ( at this point is bricked) --- --- then destroy and shutdown bnxt1 --- - If I do the same, but just make sure that the port is "admin up" before creating and deleting the sub-interfaces, everything works like charm. No errors are seen. echo "Creating Interfaces and bricks the card" ifconfig bnxt1 up ifconfig bnxt1.1011 create up fib 10 192.168.11.43/24 ifconfig bnxt1.1001 create up fib 11 192.168.12.43/24 ifconfig bnxt1.1002 create up fib 12 192.168.13.43/24 ifconfig bnxt1.1003 create up fib 13 192.168.14.43/24 ifconfig bnxt1.1004 create up fib 14 192.168.15.43/24 ifconfig bnxt1.1005 create up fib 15 192.168.16.43/24 --- then destroy and shutdown bnxt1 --- This is tested against main from yesterday. Best regards. Santi On 5/28/24 11:30, Gerrit Kühn wrote: Am Tue, 28 May 2024 11:25:09 +0200 schrieb Santiago Martinez : *"The latest I have is 214.0.286.18"* Indeed, the firmware on my box is older, I cannot upgrade it right now, but it is on my to-do list. Same here, I guess (pkgver). It says dev.bnxt.0.ver.fw_ver: 214.4.9.10/pkg 214.0.286.18 on both systems. Also, I don't think I can upgrade the firmware separately, it comes with the mainboard's bios (which is the latest available). cu Gerrit
Re: bridge: no traffic with vnet (epair) beyond bridge device
Am 2024-06-03 21:02, schrieb FreeBSD User: Hello, I'm running a dual socket NUMA CURRENT host (Fujitsu RX host) running several jails. Jails are attached to a bridge device (bridge1), the physical device on that bridge is igb1 (i350 based NIC). The bridge is created via host's rc scripts, adding and/or deleting epair members of the bridge is performed by the jail.conf script. I do not know how long the setup worked, but out of the blue, last week after a longish poudriere run after updating the host to most recent CURRENT (as of today, latest update kernel and world) and performing "etcupdate" on both the host and all jails, traffic beyond the bridge is not seen on the network! All jails can communicate with each other. Traffic from the host itself is routed via igb0 to network and back via igb1 onto the bridge. I check all setups for net.link.bridge: net.link.bridge.ipfw: 0 net.link.bridge.log_mac_flap: 1 net.link.bridge.allow_llz_overlap: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 0 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_bridge: 0 net.link.bridge.pfil_onlyip: 0 I did not change anything (knowingly). I also have an oldish box running single socket processor, also driven by the very same CURRENT and similar, but not identical setup. The box is running very well and the bridge is working as expected. I was wondering if something in detail has changed in the handling of jails, epair and bridges. I followed the setup "after the book", nothing suspicious. "after the book" = the IP of the host itself is not on igb1 but on a different interface or on the bridge? Is there a firewall active on the box itself? Which one? What does wireshark / a traffic dump at the physical interface level tell compared to a traffic dump at the switch interface? Did you replace the cable / SFP / move to a different switch port as a test? I suggest to provide the output of ifconfig -a and netstat -rn (feel free to mangle the IPs, as long as the mangling is a consistent replacement and not a cut-off). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
