Currently source address selection for raw packets under jails
uses prison_get_ip4 in the INADDR_ANY case.
This can cause an invalid source address to be used, including
using addresses which are unusable e.g. down interfaces
un-routable addresses etc.
I suspect this is a hang over from when
- Original Message -
From: C. L. Martinez carlopm...@gmail.com
e1000.
igb? There are some fixes to handle out of order packets on transmit that
could break new connections in some cases. That is probably worth
testing. I
think you can just grab the sys/dev/e1000 from 9-stable and
- Original Message -
From: Karl Denninger k...@denninger.net
...
My ordinary NAT entry is simply nat 1 ip from any to any via em1,
which works fine for ordinary on the client traffic; no problems with
that.
...
Just a stab in the dark, as I vaguely remember something similar, do you
- Original Message -
From: Outback Dingo outbackdi...@gmail.com
To: Lawrence Stewart lstew...@freebsd.org
Cc: n...@freebsd.org
Sent: Thursday, July 04, 2013 12:06 AM
Subject: Re: Terrible ix performance
On Wed, Jul 3, 2013 at 9:39 AM, Lawrence Stewart lstew...@freebsd.orgwrote:
On
- Original Message -
On Wed, Jul 3, 2013 at 10:01 PM, Lawrence Stewart
On 07/04/13 10:18, Kevin Oberman wrote:
On Wed, Jul 3, 2013 at 4:21 PM, Steven Hartland
Out of interest have you tried limiting the number of queues?
If not give it a try see
Have you tried a more recent version e.g. 9.2-PRERELEASE or 9/stable?
Regards
Steve
- Original Message -
From: Sébastien RICCIO s...@swisscenter.com
To: freebsd-net@freebsd.org
Sent: Tuesday, July 23, 2013 12:28 PM
Subject: FreeBSD 9.1 and BCM57711 issues (broadcom 10ge ethernet
- Original Message -
From: Sean Bruno sean_br...@yahoo.com
As a guess its likely the interrupt handler is triggering
while the watchdog timeout handler is re-initialising the
card so you inconsitent state resulting in the crash.
In from /var/crash should help determine the cause and
- Original Message -
From: Robert Blacquiere freebsd-...@blacquiere.nl
Hi Marek,
On Fri, Apr 25, 2014 at 09:48:36AM +0200, Marek Salwerowicz wrote:
Hi list,
snip
Both boxes are connected to the same switch (HP 1910-48G)
I need to transfer around 10 TB of data from storage1 to
- Original Message -
From: Marek Salwerowicz marek_...@wp.pl
W dniu 2014-04-25 14:01, Gerrit Kühn pisze:
Thanks for your input. As far as I understood so far, there should be one
igb queue created per cpu core in the system by default (and this is what
I see on my system). But my irq
- Original Message -
From: Marek Salwerowicz marek_...@wp.pl
To: Steven Hartland kill...@multiplay.co.uk; Gerrit Kühn
gerrit.ku...@aei.mpg.de
Cc: freebsd-net@freebsd.org
Sent: Friday, April 25, 2014 2:06 PM
Subject: Re: NFS over LAGG / lacp poor performance
W dniu 2014-04-25 14:55
- Original Message -
From: Marek Salwerowicz marek_...@wp.pl
To: Steven Hartland kill...@multiplay.co.uk; Gerrit Kühn
gerrit.ku...@aei.mpg.de
Cc: freebsd-net@freebsd.org
Sent: Friday, April 25, 2014 2:57 PM
Subject: Re: NFS over LAGG / lacp poor performance
W dniu 2014-04-25 15:27
- Original Message -
From: Gerrit Kühn gerrit.ku...@aei.mpg.de
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-net@freebsd.org
Sent: Friday, April 25, 2014 3:13 PM
Subject: Re: NFS over LAGG / lacp poor performance
On Fri, 25 Apr 2014 15:02:15 +0100 Steven Hartland
kill
- Original Message -
From: Gerrit Kühn gerrit.ku...@aei.mpg.de
On Fri, 25 Apr 2014 15:25:04 +0100 Steven Hartland
kill...@multiplay.co.uk wrote about Re: NFS over LAGG / lacp poor
performance:
SH We saw the issue with 10-RELEASE last weekend on a machine with 6 x
SH igb's where
- Original Message -
From: Gerrit Kühn gerrit.ku...@aei.mpg.de
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-net@freebsd.org
Sent: Friday, April 25, 2014 4:52 PM
Subject: Re: NFS over LAGG / lacp poor performance
On Fri, 25 Apr 2014 15:55:29 +0100 Steven Hartland
kill
Have a look at the man page using:
man lagg
It gives you all the details including examples.
Regards
Steve
- Original Message -
From: Sridhar Iyer sridhar.v.i...@gmail.com
Hi all,
I have been looking at apis in sys/net/if_lagg.c and usage in
ifconfig/iflagg.c. They both
Not sure what you mean by API examples?
The usual use of this would be to configure it at startup in
/etc/rc.conf
Regards
Steve
- Original Message -
From: Sridhar Iyer sridhar.v.i...@gmail.com
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-net freebsd-net@freebsd.org
- Original Message -
From: John-Mark Gurney j...@funkthat.com
Niu Zhixiong wrote this message on Sun, Aug 10, 2014 at 10:50 +0800:
I am sorry that I upload a WRONG SCTP capture. But, the throughput is
same.
SCTP is double than TCP, about 18Mbps.
???
sctp_2.pcapng.gz
When you say you've bumped mbclusters and mbufs, was that in
/boot/loader.conf or /etc/sysctl.conf. If the latter then thats
too late for driver init so try the former.
- Original Message -
From: Eggert, Lars l...@netapp.com
Hi,
no matter what value I bump kern.ipc.nmbclusters and
- Original Message -
From: Marcin Markowski mmarkow...@leon.pl
I tried to compile the kernel with NETMAP on FreeBSD 8 and 9, but I get
warnings and
the compilation ends.
cc1: warnings being treated as errors
../../../dev/netmap/netmap.c: In function 'netmap_memory_init':
The following reply was made to PR kern/161899; it has been noted by GNATS.
From: Steven Hartland kill...@multiplay.co.uk
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/161899: [route] ntpd(8): Repeating RTM_MISS packets causing
high CPU load for ntpd
Date: Tue, 7 Feb 2012 09:24:47 -
- Original Message -
From: Eugene Grosbein egrosb...@rdtc.ru
This is known problem. You should remove options FLOWTABLE
from your kernel configuration, as it was removed from GENERIC
for such misbehaviours. That had fixed same problem for me.
We already have this removed due to the
The following reply was made to PR kern/161899; it has been noted by GNATS.
From: Steven Hartland kill...@multiplay.co.uk
To: Eugene Grosbein egrosb...@rdtc.ru
Cc: freebsd-net@freebsd.org,
bug-follo...@freebsd.org
Subject: Re: kern/161899: [route] ntpd(8): Repeating RTM_MISS packets
- Original Message -
From: Gleb Smirnoff gleb...@freebsd.org
Any update on this, would have been nice to see a fix hit before
9.0. If you need any more information please let me know.
AFAIK, this is no longer a problem in 9.0-RELEASE or in HEAD.
The cause for this number of misses is
- Original Message -
From: Gary Palmer gpal...@freebsd.org
Running the following commands does indeed stop this
route add -inet6 :::0.0.0.0 -prefixlen 96 ::1 -reject
route add -inet6 ::0.0.0.0 -prefixlen 96 ::1 -reject
I found these in /etc/rc.d/network_ipv6 but I can't see why
- Original Message -
From: Li, Qing qing...@bluecoat.com
Hmm... I don't see this problem until multiple FIBs are enabled.
I have a bog standard box here one default route and one
active nic, which exhibits this issue so there shouldn't be
multiple FIB's unless the fact that IPv6 is
We've got a machine where with an ix interface on 8.2-RELEASE
which is seeing intermittent slow responses. It shows as stalls
on the console and is visible as high pings on an mtr
from a local machine e.g.
Packets Pings
Host Loss% Snt Last
As a quick update see below, still stumped on what's causing this
but does explain at least two of the other suspect behaviours.
- Original Message -
From: Steven Hartland
We are seeing RX Descriptors exceed system mbuf max, using
default instead! on boot with the latest driver
- Original Message -
From: Коньков Евгений kes-...@yandex.ru
Apparently not:-
can you show netstat -Q ?
netstat -Q
netstat: illegal option -- Q
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or
- Original Message -
From: Коньков Евгений kes-...@yandex.ru
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-net@freebsd.org
Sent: Monday, March 12, 2012 6:21 PM
Subject: Re[2]: ixgbe interface micro stalls / slow responses
can you show netstat -Q ?
netstat -Q
SH netstat
If your referring to driver code, as mentioned in my initial post, already
tried that, no change :(
- Original Message -
From: Jack Vogel
To: Steven Hartland
Cc: Коньков Евгений ; freebsd-net@freebsd.org
Sent: Monday, March 12, 2012 7:14 PM
Subject: Re: Re[2]: ixgbe
you recon?
Regards
Steve
- Original Message -
From: Jack Vogel
To: Steven Hartland
Cc: Коньков Евгений ; freebsd-net@freebsd.org
Sent: Monday, March 12, 2012 8:11 PM
Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses
Have you gotten rid of the rx
Will give that a go tomorrow morning thanks :)
Regards
Steve
- Original Message -
From: Jack Vogel
To: Steven Hartland
Cc: Коньков Евгений ; freebsd-net@freebsd.org
Sent: Monday, March 12, 2012 8:32 PM
Subject: Re: Re[2]: ixgbe interface micro stalls / slow
could do with
updating the docs so it lists /boot/loader.conf instead of /etc/sysctl.conf
kern.ipc.nmbjumbop=262144
kern.ipc.nmbclusters=524288
Regards
Steve
- Original Message -
From: Jack Vogel
To: Steven Hartland
Cc: Коньков Евгений ; freebsd-net@freebsd.org
Sent
i350 nic is definitely supported on 9.0-RELEASE and 8.3-RELEASE as well
as the -STABLE branches :)
Regards
Steve
- Original Message -
From: Eugene Grosbein egrosb...@rdtc.ru
To: n...@freebsd.org; Jack Vogel jfvo...@gmail.com
Sent: Wednesday, May 09, 2012 8:07 AM
Subject: I350
Link detect in ix is indeed odd even when not virtualised :(
- Original Message -
From: Sami Halabi sodyn...@gmail.com
did you try explicit ifconfig ix0 up instead of rebooting?
This e.mail is private and confidential between
I've been having issues getting a ixgbe (ix) device to link
reliably in a decent amount of time at boot to 1Gbps switch
connected on cat 5, even netwait was timing out.
Having a dig in the code there's advertise_speed which
seemed like it was just what I was looking for but
unfortunately
The following reply was made to PR kern/173201; it has been noted by GNATS.
From: Steven Hartland kill...@multiplay.co.uk
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/173201: [ixgbe] [patch] Missing / broken ixgbe sysctl#39;s
and tunables (patch included)
Date: Wed, 7 Nov 2012 23:34:39
We've got a lovely shiny new carp thanks to glebius in head
but unfortunately its not going to get MFC'ed so for the time
being those users on -RELEASE / -STABLE need to use the current
implementation which has a nasty issue where by it doesn't
cleanup when IP's are removed hence gets into an
Out of interest what change was that?
- Original Message -
From: Vogel, Jack jack.vo...@intel.com
To: TAKAHASHI Yoshihiro n...@freebsd.org; jfvo...@gmail.com
Cc: freebsd-net@freebsd.org; freebsd-sta...@freebsd.org
Sent: Monday, January 10, 2011 9:17 PM
Subject: RE: Supermicro
I've been trying to debug an issue where a call to getpeername
on a connected tcp socket returns ENOTCONN with no prior errors
being reported by previous socket calls.
At first I thought this was perl / perl module bug but I've now
reproduced the behaviour with a small native c client.
The flow
- Original Message -
From: John Baldwin j...@freebsd.org
Waiting for the default route to be pingable actually fixed a few other
problems for us on 7 though as well (often ntpdate would not work on boot and
now it works reliably, etc.) so we went with that route.
Also fixed quite a
Just updated a box to the 8.2-PREREL as of friday and now when we do any
serious amounts of network traffice we see:-
bge0: watchdog timeout -- resetting
bge0: link state changed to DOWN
bge0: link state changed to UP
The interface never recovers, we have to use remote console to down, wait
30
This may be totally unrelated to bge, investigating a potential failing stick
of ram in the machine in question so until we've ruled this out as the cause
don't want to waste anyone's time.
I did however notice the logic between the two fixes for DMA on 5704's on PCIX
in svn differ so wondering
Silly question but have you checked your ram for issues, we had a machine
with seemingly unexplained problems and hangs and it turned out to be
a duff stick of ram which wasn't being chip killed.
- Original Message -
From: Lev Serebryakov l...@serebryakov.spb.ru
To: Brandon Gooch
Seems there's an issue with the intel ix driver which causes
it to bin connections when you manipulate ip aliases.
This causes issues on boot when jails start as it bins other
active sessions.
Is this a know issue?
Running 8.2-RELEASE amd64 here.
Regards
Steve
Hi Jack do you have any idea what's going on here as it very disruptive
for every IP change to cause total outage on the machine?
- Original Message -
From: Steven Hartland kill...@multiplay.co.uk
To: freebsd-net@freebsd.org
Sent: Wednesday, April 20, 2011 2:37 PM
Subject: Intel ix
)'
class = display
subclass = VGA
- Original Message -
From: Jack Vogel
To: Steven Hartland
Cc: freebsd-net@freebsd.org ; Vogel, Jack
Sent: Friday, April 22, 2011 5:45 PM
Subject: Re: Intel ix (X520) disconnects when manipulating ips?
Please give me the exact
.
Regards
Steve
- Original Message -
From: Jack Vogel
To: Steven Hartland
Cc: freebsd-net@freebsd.org ; Vogel, Jack
Sent: Friday, April 22, 2011 11:13 PM
Subject: Re: Intel ix (X520) disconnects when manipulating ips?
I see you have igb devices, if you do
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-net@freebsd.org; Vogel, Jack jack.vo...@intel.com
Sent: Friday, April 22, 2011 11:35 PM
Subject: Re: Intel ix (X520) disconnects when manipulating ips?
OK, did some testing, this re-init with link transition will happen on both
the 1G
Thanks Jack / Andrew that would be awesome :)
- Original Message -
From: Jack Vogel jfvo...@gmail.com
Whoops, I see what you're talking about Andrew, OK, I get it, Steve I have
another
set of changes to get into ixgbe soon anyway, I'll roll this change up with
that and
then let you
Running em's here we regularly see them hitting pretty much line rate
although there are a lot of different em's
Here we have the following under 8.0+
em0@pci0:6:0:0: class=0x02 card=0x15d9 chip=0x10968086 rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel
* What's your traffic like? e.g. http, large tcp files, tiny udp etc...
* Is it all on a local switch, if so what switch?
* Is flow control enabled?
* Are you seeing high interrupts?
* Are you disk bound?
* Are you memory bound?
* Are you cpu bound?
Some basic settings we have here:-
tried without tso, rxcsum, txcsum lro disabled?
- Original Message -
From: Adam Stylinski kungfujesu...@gmail.com
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-net@freebsd.org
Sent: Thursday, April 28, 2011 3:45 PM
Subject: Re: em0 performance subpar
I was using the default
- Original Message -
From: Vlad Galu d...@dudu.ro
Hello Michael,
net.inet.tcp.finwait2_timeout and net.inet.tcp.fast_finwait2_recycle are
your friends.
You should only need this if the connection isn't being closed down cleanly
from both ends.
Regards
Steve
I would recommend moving to 8.2 with the additional fixes in stable to
which prevents adding IP's from disconnecting the network.
In the machine what PCIe speed does it state its using? What CPU's do
you have as to push closer to 10Gbps your going to need a quick machine.
Regards
Steve
- Original Message -
From: Mario Spinthiras spinthiras.ma...@gmail.com
I've been looking at issues regarding performance with the igb issue from a
few years back at this thread :
http://lists.freebsd.org/pipermail/freebsd-doc/2009-June/015983.html. These
are very similar problems to
IIRC it needs to be in sysctl.conf, so try that.
- Original Message -
From: Mario Spinthiras spinthiras.ma...@gmail.com
To: freebsd-net@freebsd.org
Cc: Jack Vogel jfvo...@gmail.com
Sent: Wednesday, June 15, 2011 9:56 AM
Subject: Re: strange igb interface performance problems
Hi,
To
We're trying to get our machines IPv6 enabled but in doing so this
seems to break java apps using openjdk6 for UDP sends.
The server seems quite happy to send and receive TCP packets on
IPv6 socket that are bound to IPv4 addresses, but the same is not
true for UDP.
The socket bind works fine
- Original Message -
From: Matthias Andree matthias.and...@gmx.de
I'm adding back in -java as based on you comments it may well be
something in the jdk passing invalid values down to the kernel
syscall.
The socket bind works fine and the packets sent to the server arrive
and are
- Original Message -
From: Bjoern A. Zeeb b...@freebsd.org
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-net@freebsd.org
Sent: Saturday, June 25, 2011 10:27 AM
Subject: Re: IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send
On Jun 24, 2011, at 9:11 PM, Steven
- Original Message -
From: Bjoern A. Zeeb b...@freebsd.org
Sigh, I'll need to look at that then.
I think you are hitting:
http://svnweb.freebsd.org/base?view=revisionrevision=220463
Can you apply that to your kernel, and see if that helps?
Had to modify the patch slightly for
- Original Message -
From: Matthias Andree matthias.and...@gmx.de
No I'm not its replying to the sender.
Yes you are, check your trace: The sendto address and port are the same
as the bound address.
This is a bug in truss it seems, Bjoern said he's gonna have a look at
it. Doesn't
Pretty sure this is already in the source tree as it sounds like the same
as the alias fix:-
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ixgbe/ixgbe.c?rev=1.51;content-type=text%2Fplain
There's also some additional fixes in the latest head version:-
When trying to clear down an interface in this case igb1 I usually
just use:-
ifconfig if down delete
This seems to fail when ipv6 is enabled on 8.2-RELEASE where I get
ifconfig igb1 down delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
This a bug?
Regards
Steve
Been trying to identify an strange network stalling issue while using
scp or rsync between two machines, initially at remote locations.
The behaviour has proved quite difficult to track as it seems to require a
number or factors combined before the stalls occur. These seem to be:
1. This
- Original Message -
From: Kevin Oberman kob6...@gmail.com
Use tcpdump -s0 -w file.pcap host remote-system to see how it fails. You
may want to capture on both ends. Then use wireshark (in ports) to analyze
the data.
There are other tools to provide other types of analysis, depending
- Original Message -
From: Jack Vogel jfvo...@gmail.com
I have no idea... but as a matter of principle I would see if updating to
later code,
both OS and especially the driver, reproduces the issue. Our validation
group often has Linux as a link partner in testing, which can be good
Ok making some progress now, disabling msix by setting hw.igb.enable_msix=0
in /boot/loader.conf fixes the stalls, so I'm guessing this indicates a
driver issue?
My current test case is a repeating scp of the freebsd iso from 3 local
machines + 1 remote to the target machine, which seems to be
We're seeing tcp stalls under igb under 8.2-RELEASE and 8-STABLE (which shares
some code with em) and the workaround for use is currently adding the following
to /boot/loader.conf
hw.igb.enable_msix=0
Might be worth trying that.
Regards
Steve
- Original Message -
From: Michael
of
load.
Not wishing to hijack this thread, but any advise on what else to try to
diagnose this stalling issue would be gratefully received.
Regards
Steve
- Original Message -
From: Jack Vogel
To: Steven Hartland
Cc: Michael W. Lucas ; freebsd-net@freebsd.org
Sent
Yep, it stalls 8.2 partners as well :(
- Original Message -
From: Jack Vogel
To: Steven Hartland
Cc: Michael W. Lucas ; freebsd-net@freebsd.org
Sent: Wednesday, July 20, 2011 6:03 PM
Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE
Did you eliminate
- Original Message -
From: Jack Vogel jfvo...@gmail.com
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-net@freebsd.org; Michael W. Lucas mwlu...@blackhelicopters.org
Sent: Wednesday, July 20, 2011 6:18 PM
Subject: Re: kern/152828: [em] poor performance on 8.1, 8.2-PRE
Can you
We've been investiging an ongoing issue with some machines
we have in Amsterdam, when receiving files via scp from our
London DC.
Initially we suspected a igb driver issue but after continued
diagnosis including disabling hardware tso and cksums on
both end we're currently investigating the
- Original Message -
What I believe we're seeing from the tcpdump trace is the
packet loss on the network results in an unrecoverable tcp
session.
From my very limited knowledge of tcp, I would expect to see
the session to recover after receiving the lost packet by
either a fast
- Original Message -
From: Andre Oppermann an...@freebsd.org
...
I believe this is tcps_rcvmemdrop in tcp_reass.c to which there's the
following comment:-
* XXXLAS: Using sbspace(so-so_rcv) instead of so-so_rcv.sb_hiwat
* should work but causes packets to be dropped when they
- Original Message -
From: Steven Hartland
- Original Message -
From: Andre Oppermann
...
I believe this is tcps_rcvmemdrop in tcp_reass.c to which there's the
following comment:-
* XXXLAS: Using sbspace(so-so_rcv) instead of so-so_rcv.sb_hiwat
* should work but causes
- Original Message -
From: Steven Hartland
Setting net.inet.tcp.reass.maxsegments=8148 and rerunning the
tests appears to result in a solid 14MB/s, its still running a
full soak test but looking very promising :)
Ok so full test has completed with over 134GB of data transferred
- Original Message -
From: Steven Hartland
I look forward to hearing peoples thoughts on what the actual fix
should be: increased default nmbclusters, decreased nmbclusters =
maxsegments divisor, or something else?
Another useful piece of information is that even though maxsegments
Wanted to update this thread to confirm, as Jack suspected, the issue
we where seeing was something much more ingrained that a driver issue.
It turned out this problem in the tcp reassembly code which is likely
due to insufficient size of net.inet.tcp.reass.maxsegments.
The result is even with
- Original Message -
From: Andre Oppermann an...@freebsd.org
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-net@freebsd.org; lstew...@freebsd.org
Sent: Tuesday, August 02, 2011 10:25 PM
Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE?
On 02.08.2011
- Original Message -
From: Lawrence Stewart lstew...@freebsd.org
Thanks for bringing me in directly, I haven't been keeping up with the
mailing lists at all recently.
No problem
So I suppose the question is should maxsegments be larger by
default due to the recent changes e.g.
-
- Original Message -
From: Lawrence Stewart lstew...@freebsd.org
To: Steven Hartland kill...@multiplay.co.uk
Cc: Andre Oppermann an...@freebsd.org; freebsd-net@freebsd.org;
s...@zxy.spb.ru
Sent: Thursday, August 11, 2011 2:13 AM
Subject: Re: tcp failing to recover from a packet loss
- Original Message -
From: Lawrence Stewart lstew...@freebsd.org
Here's my tweaked version of Andre's patch:
http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass.c-logdebug%2bmissingsegment-20110811-lstewart.diff
Still testing this and just noticed that the patch fails to
After a HD failure we moved an IP of one of our DNS
servers to some new hardware.
Now we are seeing some very strange behaviour on a number
of machines when talking to the ip which was moved.
Specifically it seems both icmp and tcp work just fine
but udp doesn't.
I've just done a trace from
net.inet.flowtable.syn_expire: 300
net.inet.flowtable.enable: 1
net.inet.flowtable.debug: 0
This mean yes?
- Original Message -
From: Li, Qing qing...@bluecoat.com
To: Steven Hartland kill...@multiplay.co.uk; freebsd-net@freebsd.org
Sent: Saturday, October 22, 2011 1:10 AM
Subject: RE: very
- Original Message -
From: Mike Tancsa m...@sentex.net
Seems like the flow table is pretty broken then with respect
changing arp entries, at least in 8.2-RELEASE :(
Its been removed from the default kernel back in April
Author: bz
Date: Sat Apr 9 12:04:35 2011
New Revision: 220486
What did netstat -m show?
Regards
Steve
- Original Message -
From: Lev Serebryakov l...@freebsd.org
To: Mike Tancsa m...@sentex.net
Cc: freebsd-net@freebsd.org
Sent: Thursday, October 27, 2011 10:26 AM
Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when
Does this really warrant a high priority flag?
- Original Message -
From: [EMAIL PROTECTED]
Sure! Here you are!
GBRT2# pciconf -lv | grep -A 3 bge
[EMAIL PROTECTED]:1:0: class=0x02 card=0x100410b7 chip=0x164514e4 rev=0x15
hdr=0x00
vendor = 'Broadcom Corporation'
Erm copying via putty works just fine!
- Original Message -
From: Fuchs, Martin [EMAIL PROTECTED]
Since there's no possibility to copy via putty i'm copying by hand... hopefully
there are not too many errors :-)
This e.mail is
Date: Thu, 12 Jun 2008 23:11:13 -0400 (EDT)
In article [EMAIL PROTECTED], Brooks
Am I the only one who would be happier if openssh were not in the base
system at all? I always have to install the port anyway; having it in
the base just gives me more files I need to delete after an install.
Even on PCI-e devices this has some nasty side effects i.e. on a PFSence
firewall box based on 7.0-RELEASE-p3 with TSO enabled, access via the
public network to the web interface is almost impossible. Simply disabling
TSO and all was good.
This may not be strictly down to the HW or driver but is
We run a large about of supermicro servers here and I've got two just about
to be commissioned which I could use for testing. What sort of thing should
we be looking for and what's the nature of the patch?
Regards
Steve
- Original Message -
From: Jack Vogel [EMAIL PROTECTED]
To:
Silly question but something else on the network isn't doing a arp spoof
attack is it?
Regards
Steve
- Original Message -
From: Chris Buechler free...@chrisbuechler.com
To: n...@freebsd.org
Sent: Sunday, May 17, 2009 9:08 PM
Subject: multi-homed systems stop answering ARP on
Anyone point me in the right direction on how to add the phy to support
these machine?
Seems like its just a matter of adding the PHY details to miidevs but how
do I find out the specifics of that?
Regards
Steve
- Original Message -
From: DutchDaemon free...@bengrimm.net
The
This already appears to be in the 8.0 BETA2 source that we are running,
no go :(
Regards
Steve
- Original Message -
From: Xin LI delp...@delphij.net
To: Steven Hartland kill...@multiplay.co.uk
Cc: DutchDaemon free...@bengrimm.net; freebsd-net@FreeBSD.org
Sent: Thursday, July 30
Thanks for the update David, if there is anything we can do
to help let us know.
Regards
Steve
- Original Message -
From: David Christensen davi...@broadcom.com
Anyone point me in the right direction on how to add the phy
to support these machine?
Seems like its just a
Any news on the driver update for 5709S yet Dave?
Regards
Steve
- Original Message -
From: Steven Hartland kill...@multiplay.co.uk
Thanks for the update David, if there is anything we can do
to help let us know.
Regards
Steve
- Original Message -
From: David
M610 is also broken due to unsupported bge revision :(
Regards
Steve
- Original Message -
From: Tom Judge t...@tomjudge.com
To: n...@freebsd.org
Cc: pyu...@gmail.com; Xin LI delp...@delphij.net; David Christensen davi...@broadcom.com; rwilli...@borderware.com;
Stanislav Sedov
Sorry I typo'ed there, should have said bce, is that still relevant?.
We haven't been able to install any version yet, so can't just
try a kernel, no way of getting data on to the machine without
a working netcard ;-)
Did this update include any updated PHY support for bce? As the
the precise
On Tue, 27 Oct 2009 23:02:09 -
Steven Hartland kill...@multiplay.co.uk mentioned:
If I understand the PR comments right, the code to support this PHY
should be present in 8.0. So you can start by trying out 8.0-RC1
ISO image (or USB stick image, fwiw).
Just tried 8.0RC2 no go, PHY still
1 - 100 of 163 matches
Mail list logo
