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 bin
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 tha
> 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 naturally fit
>> into ifconfig.
>
> From the end-user perspective, I agree with Drew.
> 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.
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
options=e407bb
ether 0c:c4:7a:bd:70:26
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.
___
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 appl
On Dec 3, 2014, at 5:21 PM, Patrick Proniewski wrote:
> On 3 déc. 2014, at 17:09, Borja Marcos 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:
>>>
>>
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
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
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
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 ob
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.
___
freebsd-n
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 s
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 yo
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 s
On Jul 7, 2014, at 1:23 PM, Luigi Rizzo wrote:
> On Mon, Jul 7, 2014 at 1:03 PM, Borja Marcos 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 configurati
On Jul 1, 2014, at 10:24 PM, Luigi Rizzo wrote:
>
>
>
> On Tue, Jul 1, 2014 at 8:58 PM, 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 thi
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 an
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
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
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 t
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 sin
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
>
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
> th
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
> th
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.
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-
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
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
> segmen
(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
o
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 cours
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
33 matches
Mail list logo
