[Bug 247853] Port OpenBSD Wireguard kernel module to FreeBSD kernel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247853 --- Comment #8 from Peter Libassi --- I can confirm issue 2) in comment 6. I set up if_wg peer to a freebsd wireguard-go peer. ping both directions ok. ssh no contact in any direction, even tried ssh -b. Then I created a remote host (jail with epair interfaces) from there i can access the wireguard-host local services. so it seems that the traffic coming from the freeBSD wireguard peer does not pass up the stack, if the traffic is from a remote host it is passed up the stack. Then i set up if_wg peer to a void linux peer. Now ssh works in both directions! -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 248324] qlxge: stability issues (unusable) with QLogic QLE8142 NIC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248324 Bug ID: 248324 Summary: qlxge: stability issues (unusable) with QLogic QLE8142 NIC Product: Base System Version: 12.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: nyako...@gmail.com Short: QLogic QLE8142 Convergent network adapters do not work properly on FreeBSD (10.2 and 12.1 tested). Low speeds and connection dropouts. But they work perfectly with Linux (qlge driver) I was suggested that this can be related to mismatched mtu size somewhere. I also suspect that this somehow can be related to flowcontrol and media detection. Long: I have two 10G Qlogic converged network cards. QLogic QLE8142-IBMX (42C1802) QLogic QLE8142-SR-IBM (46K8088) They are basically the same(looks and works same), both flashed with latest firmware (from Qlogic support) (other firmware versions have no effects on unstable behavior) They are transceiver specific and I use them with Qlogic FLTX8571D3BCL-QL optical transceivers (it seems they support only fiber) I am testing them with iperf3. I setup direct fiber link between two NICs on different PCs with different OS Like this (ifconfig ql0 inet 192.168.10.1/24) and (192.168.10.2/24) for second PC. On FreeBSD this card got identified as: ql0: port 0xe300-0xe3ff mem 0xfea0c000-0xfea0,0xfe80-0xfe8f at device 0.0 on pci1 ql0: qls_pci_attach: ha 0xfe696000 pci_func 0x0 msix_count 0x1 pci_reg 0xf80003720700 pci_reg1 0xf80003720600 ql0: Ethernet address: 00:c0:dd:26:25:80 On Linux: qlge :01:00.0: QLogic 10 Gigabit PCI-E Ethernet Driver qlge :01:00.0: Driver name: qlge, Version: 1.00.00.35. qlge :01:00.0 eth1: Link is down. qlge :01:00.0 eth1: Clearing MAC address qlge :01:00.0 eth1: Function #0, Port 0, NIC Roll 0, NIC Rev = 1, XG Roll = 0, XG R> qlge :01:00.0 eth1: MAC address 00:c0:dd:26:25:80 What works: OS Linux (Arch and Debian tested) qlge (https://cateee.net/lkddb/web-lkddb/QLGE.html) kernel module. QLE8142 -> fiber -> any transceiver(including Qlogic one) + any 10G card at any os(except QLE8142 card on FreeBSD) mtu 9000 and mtu 1500 All great, I see channel saturation and no errors. Different offload settings have small effect on anything. What does not work: QLE8142 card on FreeBSD with any card in other end (including QLE8142 on Linux) OS FreeBSD qlxge (https://www.freebsd.org/cgi/man.cgi?query=qlxge) kernel module, FreeBSD10.2 and FreeBSD12.1 tested. I get unstable behavior. Low link speed, or dropout of link when test start. It is unstable, so, it is hard to describe whats going on. One example: iperf3 connecting from Linux box to FreeBSD12.1 with QLE8142 - all seems fine. iperf3 connecting from FreeBSD12.1 with QLE8142 to Linux box - low unstable speed (2Gb/s - 5Gb/s) then dropout to zero. Link seems to stay active but no new connection can pass at all(for some time) This somehow gets affected by -tso setting, but unstable behavior just become different. On FreeBSD10.2 with -tso setting and mtu 1500 - card can work stable for some time, but sometimes it is not. With mtu 9000 - unstable, drop of connections. Another example: Testing two direct connected QLE8142 cards, one on Linux other on FreeBSD12.1 All default. mtu 1500. I get 8.2Gb/s from Linux to BSD, 1Gb/s from BSD to Linux. When on FreeBSD I disable TSO, I get 5Gb/s From BSD to Linux. And 4Gb/s in both directions simultaneously. Then. I set mtu 9000 on both ends. >From Linux to BSD - drop of connection. >From BSD to Linux 2Gb/s mtu 9000 and disable TSO on FreeBSD end >From Linux to BSD - drop of connection. >From BSD to Linux 9,5Gb/s FreeBSD show messages in log such as: ql0: qls_mbx_get_link_status 0x4000 0x1051 0x 0x0037 0x00f9 0x05050504 ql0: qls_hw_send: tx_free[0] = 2 ql0: qls_mbx_get_link_status 0x4000 0x1051 0x 0x0037 0x00fd 0x05050504 ql0: qls_mbx_isr: AEN [0x8012 0x0060 0x0037 0x 0x 0x 0x 0x 0x] ql0: qls_rx_comp: DS bit not set ql0: qls_rx_comp: (rxb->paddr != cq_e->b_paddr)[0x5527, 0x5527c800] ql0: qls_rx_comp: (rxb->paddr != cq_e->b_paddr)[0x5527, 0x35b3cc000] ql0: qls_rx_comp: (rxb->paddr != cq_e->b_paddr)[0x5527, 0x53fe4000] FreeBSD ifconfig -m ql0 output: ql0: flags=8843 metric 0 mtu 1500 options=c013b capabilities=c013b ether 00:c0:dd:26:25:80 inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 media: Ethernet autoselect (10Gbase-SR ) status: active supported media: media autoselect media autoselect mediaopt full-duplex nd6 options=29 >From Linux: sudo ethtool enp1s0f0 netlink error: No such file
[Bug 248334] Typo in iovctl.conf.5
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248334 Bug ID: 248334 Summary: Typo in iovctl.conf.5 Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Manual Pages Assignee: b...@freebsd.org Reporter: ch...@tuffli.net CC: d...@freebsd.org The URL for the "official UCL website:" mistakenly includes the period at the end of the sentence which leads to a 404 error. To reproduce, click on the link after "official UCL website:" Note that removing the trailing period in the browser's address field leads to the correct website. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 248335] O_BENEATH leaks information about parent directories
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248335
Bug ID: 248335
Summary: O_BENEATH leaks information about parent directories
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: sunf...@mozilla.com
The behaviour of `O_BENEATH` in code like this:
```c
int dirfd = open("/foo", O_RDONLY);
int bar = openat(dirfd, "/foo/bar", O_RDONLY|O_BENEATH);
```
on FreeBSD-CURRENT, if I read the man page [0] correctly, is to attempt to open
the absolute path "/foo/bar", since "/foo" is a prefix that "ends up at the
topping directory". `openat` with `O_BENEATH` also resolves ".." paths which
temporarily escape the topping directory if the final path is within the
topping directory. These means that information about the path above the
topping directory leaks through the result of the `openat`. This is undesirable
for sandboxing applications which wish to avoid leaking information about the
host filesystem outside the sandbox.
One way to avoid this is to enable Capsicum capability mode, however since that
affects process-wide state, it isn't suitable for lightweight sandboxing use
cases which just want to sandbox paths in selected `openat` calls. And, it
appears to have the side effect of disallowing ".." entirely.
Another way to avoid this is for these use cases to check for absolute paths
and ".." manually, however this wouldn't protect against symlinks to absolute
paths or symlinks containing "..", which can't always be prevented. It may also
have the side effect of disallowing ".." entirely--there are techniques for
emulating sandboxed ".." resolution [4], however they incur significant
overhead.
FreeBSD's `O_BENEATH` was modified to have its current behaviour in D17714 [3].
It's unclear from the discussion what the motivating use cases are. For the use
case of sandboxing untrusted paths, it would be desirable to have a way to
avoid leaking information about the host filesystem above the topping
directory.
FreeBSD's current `O_BENEATH` also appears to differ from Linux's new
`openat2`'s `RESOLVE_BENEATH` flag, or any of its other flags [1]. Linux's
`openat2` with `RESOLVE_BENEATH` fails with `EACCES` on any absolute path, or
any path that escapes even temporarily in an intermediate component. As an
additional data point, this is the behaviour of CloudABI's `libemulator` as
well [2].
I'm not very familiar with FreeBSD, so corrections if I've misunderstood or
missed anything are most welcome!
[0]
https://svnweb.freebsd.org/base/head/lib/libc/sys/open.2?revision=340347&view=markup&pathrev=340347
[1] https://man7.org/linux/man-pages/man2/openat2.2.html
[2]
https://github.com/NuxiNL/cloudabi-utils/blob/master/src/libemulator/posix.c#L1271
[3] https://reviews.freebsd.org/D17714
[4]
https://github.com/NuxiNL/cloudabi-utils/blob/master/src/libemulator/posix.c#L1205
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
