dns/bind911 depending on bind-tools?

Hi, I think that making dns/bind911, dns/bind912, etc, depend on bind-tools which depends on dns/bind914 is a really bad idea. Bind versions ship with their own bind tools and it’s a POLA violation to mix release versions. It’s understandable to make bind-tools depend on the latest stable

Setting MSS with setsockopt TCP_MAXSEG

Hi, I was trying changing the MSS for outgoing TCP connections and I’ve found out that it doesn’t work. There is an old bug report marked as “fixed” but it seems that the bug is still there or it resurfaced. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144000 Moreover, I have found

Re: RFC: ethctl

> On 20 Jan 2017, at 19:36, Garrett Wollman > wrote: > > In article you write: >> Eg, I don't see why we need another tool for some of this missing >> "ethtool" functionality; it seems like most of it would

Re: NFS on 10G interfaces still painfully slow

> On 02 Aug 2016, at 10:49, Gerrit Kühn wrote: > > Is there anyone around here who can confirm that nfs can go faster over > 10G links? > Any hints for further tuning/debugging are greatly appreciated. Can you show us ifconfig output, please? Borja.

Problem with ixgbe and lagg

Hello, I am unable to set up a LACP based interface with lagg and a two ports Intel 10 GbE card. When not using lagg, the interfaces work. However, an ifconfig shows that media is not properly detected. ix2: flags=8843 metric 0 mtu 1500

Re: oce(4) promiscous mode bug(?)

On Jun 17, 2015, at 11:48 AM, Sergey Akhmatov wrote: Hi, I’ve got problems with HP NC550SFP NIC (http://www.emulex.com/products/ethernet-networking-storage-connectivity/ethernet-networking-adapters/hp-branded/nc550sfp/overview/ ) Beware The driver was unusable until fixes were applied

Re: oce(4) promiscous mode bug(?)

On Jun 17, 2015, at 2:58 PM, Sergey Akhmatov wrote: I've tried 10.1-RELEASE, then 10-STABLE and finaly 11-CURRENT with the same result. Sorry, in that case I don't know what it might be. Have you tried disabling adapter intelligence? rxcsum, txcsum, lro, etc? Borja.

Re: Horrendous upload network performance with VLAN (download seems OK)

On Dec 3, 2014, at 5:05 PM, Patrick Proniewski wrote: I did and it failed, but maybe I've not used the right syntax: # ifconfig bxe0 -vlanmtu ifconfig: -vlanmtu: Invalid argument man bxe makes me think that this driver won't allow this kind of changes. Although there's no

Re: Horrendous upload network performance with VLAN (download seems OK)

On Dec 3, 2014, at 5:21 PM, Patrick Proniewski wrote: On 3 déc. 2014, at 17:09, Borja Marcos bor...@sarenet.es wrote: On Dec 3, 2014, at 5:05 PM, Patrick Proniewski wrote: I did and it failed, but maybe I've not used the right syntax: # ifconfig bxe0 -vlanmtu ifconfig

Oce driver fixes

Hello, Back in July there was a discussion on -current about serious problems with the oce driver for Emulex 10 GbE cards. Stefano Garzarella supplied a patch that fixed the problems (at least for me). Is this patch planned to go to -current and -stable, ideally before 10.1? At least for me,

Re: Fix Emulex oce driver in CURRENT

On Jul 15, 2014, at 10:22 AM, Stefano Garzarella wrote: Hi, I found other problems in the oce driver during some experiments with netmap in emulation mode. What about driver version 10.0.747.0? At least in my configuration it works perfectly, no crashes despite keeping it running for

Re: Fix Emulex oce driver in CURRENT

On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote: I used the oce driver in CURRENT. I think that this patch in combination with the previous one should work in 10-STABLE. I have only tested if it works with CURRENT, but now I try if it works with 10-STABLE and I'll send you some

Re: Fix Emulex oce driver in CURRENT

On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote: I used the oce driver in CURRENT. I think that this patch in combination with the previous one should work in 10-STABLE. I have only tested if it works with CURRENT, but now I try if it works with 10-STABLE and I'll send you some

Re: Fix Emulex oce driver in CURRENT

On Jul 15, 2014, at 11:45 AM, Stefano Garzarella wrote: I just tried to run iperf3 with this patch and STABLE-10 and it seems to work. Do you have a panic? Still compiling :) Anyway, you didn't suffer panics before, right? Borja. ___

Re: Fix Emulex oce driver in CURRENT

On Jul 15, 2014, at 11:45 AM, Stefano Garzarella wrote: I just tried to run iperf3 with this patch and STABLE-10 and it seems to work. Do you have a panic? So far, so good. I've ran a couple of iperf3 tests (60 seconds, trying both directions) and it doesn't crash. Without the fixes I

Re: Fix Emulex oce driver in CURRENT

On Jul 15, 2014, at 1:36 PM, Stefano Garzarella wrote: So, asking for spiritual counsel now. Would you use this driver in a production environment instead of the 747 version downloaded from Emulex? I think the latter is giving slightly better performance but, anyway, I disable LRO and

Re: Fix Emulex oce driver in CURRENT

On Jul 1, 2014, at 10:24 PM, Luigi Rizzo wrote: On Tue, Jul 1, 2014 at 8:58 PM, bor...@sarenet.es wrote: El 30.06.2014 18:36, Stefano Garzarella escribió: Hello, I had problems during some experiments with Emulex and oce driver in CURRENT. I found several bugs in the oce driver and

Re: Fix Emulex oce driver in CURRENT

On Jul 7, 2014, at 1:23 PM, Luigi Rizzo wrote: On Mon, Jul 7, 2014 at 1:03 PM, Borja Marcos bor...@sarenet.es wrote: we'll try to investigate, can you tell us more about the environment you use ? (FreeBSD version, card model (PCI id perhaps), iperf3 invocation line, interface configuration

Re: Unusable Emulex oce driver version in -STABLE, 9.3 and CURRENT

On Jun 17, 2014, at 6:07 PM, Borja Marcos wrote: Hello, This should be fixed before the release of 9.3, and of course as soon as possible for the rest of the branches. At least under 10-STABLE the oce driver can cause a panic when there's a lot of network traffic. I have been able

Re: Unusable Emulex oce driver version in -STABLE, 9.3 and CURRENT

On Jun 18, 2014, at 9:35 AM, Borja Marcos wrote: In my case, the problem manifests itself running 10. Emulex provides a more recent driver which compiles perfectly and works perfectly (if we can safely assume that a weekend saturating a couple of interfaces runnning benchmarks

Re: Unusable Emulex oce driver version in -STABLE, 9.3 and CURRENT

On Jun 18, 2014, at 2:20 PM, Borja Marcos wrote: Just a follow-up. I ran the tests on 9.3-BETA3. It doesn't panic, but the interface freezes and it's unable to transmit packets. So, it's still unusable. Now I'm installing the new driver and trying again. Will take time, I have

Unusable Emulex oce driver version in -STABLE, 9.3 and CURRENT

Hello, This should be fixed before the release of 9.3, and of course as soon as possible for the rest of the branches. At least under 10-STABLE the oce driver can cause a panic when there's a lot of network traffic. I have been able to reproduce it using iperf. Sometimes the panic can be

Re: openbgpds not talking each other since 8.2-STABLE upgrade

On Jan 10, 2012, at 12:01 AM, Claudio Jeker wrote: Since it is possible to add MD5 for neighbors on config reload and the listening sockets are normaly not closed and reopened on config reload it was the easiest to set the MD5 option on all listening sockets no matter what (especially since

Re: openbgpds not talking each other since 8.2-STABLE upgrade

On Jan 4, 2012, at 10:28 AM, Claudio Jeker wrote: On Wed, Jan 04, 2012 at 09:27:28AM +0100, Borja Marcos wrote: Behavior on FreeBSD: The setsockopt(TCP_MD5SIG) *enables* TCP_MD5. According to my packet captures, in case there's no properly set key with setkey(8) it will use whatever key

Re: openbgpds not talking each other since 8.2-STABLE upgrade

On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: Thanks for the link Nikolay. Borja, I assume it's the PR submission form that gave you trouble - sorry for that. Based on your report it sounds to me like the bug is in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option though

Re: openbgpds not talking each other since 8.2-STABLE upgrade

On Jan 3, 2012, at 8:07 AM, Nikolay Denev wrote: On Jan 3, 2012, at 5:53 AM, Doug Barton wrote: We have a pair of physical FreeBSD systems configured as routers designed to operate in an active/standby CARP configuration. Everything used to work fine, but since an upgrade to 8.2-STABLE

Re: openbgpds not talking each other since 8.2-STABLE upgrade

On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: On Tue, Jan 03, 2012 at 09:07:56AM +0200, Nikolay Denev wrote: Since I've had similar problem with Quagga after updating to 8.2-STABLE I'd suggest you to try setting net.inet.tcp.signature_verify_input=0 and see if that would help. Here is

Re: openbgpds not talking each other since 8.2-STABLE upgrade

On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: Thanks for the link Nikolay. Borja, I assume it's the PR submission form that gave you trouble - sorry for that. Based on your report it sounds to me like the bug is in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option though

Re: Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration

On Nov 23, 2011, at 9:30 AM, Nikolay Denev wrote: the RFC states : Upon receiving a signed segment, the receiver must validate it by calculating its own digest from the same data (using its own key) and comparing the two digest. A failing comparison must result in the segment

Re: Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration

On Nov 23, 2011, at 9:30 AM, Nikolay Denev wrote: I'm seeing exactly the same problem with Quagga. Quagga's bgpd also seem to always set the TCP_MD5 socket option, and newer freebsd 8.2 machines don't seem to be able to establish bgp sessions, probably due to the recent TCP_MD5 fixes that

Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration

(Sent to freebsd-bugs as well, copied here for discussion, if needed) Sorry for the brief report and the scarce details. The fing form insists on rejecting the captcha after one hour writing a report. So, in short: If TCP_MD5 is available on the system, options IPSEC

Re: FreeBSD 9-RC1, openbgpd, tcp md5

On Nov 4, 2011, at 1:41 PM, Patrick Lamaiziere wrote: Isn't a new option to build openbgpd with tcp-md5 (and without pf_key)? I've used TCP-MD5 signature for bgp between a FreeBSD 8.x and OpenBSD, using setkey(8) to enforce the signature between the peers. That worked (of course,

FreeBSD 9-RC1, openbgpd, tcp md5

Hi I'm testing a set up for OpenBGPd with FreeBSD 9-RC1 (amd64). For now I'm trying on two virtual machines. Using the stock GENERIC kernel it works, although of course it doesn't have TCP MD5 support, which I require. I've compiled new kernels with the TCP MD5 support (options IPSEC, device