Synopsis: [ixgbe] [patch] ixgbe driver compiled in kernel has no Flow Director
support although loaded as a module has one
State-Changed-From-To: open->patched
State-Changed-By: maxim
State-Changed-When: Sat Jun 2 13:19:59 UTC 2012
State-Changed-Why:
jfv@ has committed the patch, see r235
Synopsis: [lagg][patch] Take lagg rlock before checking flags
State-Changed-From-To: open->patched
State-Changed-By: maxim
State-Changed-When: Tue Jul 26 14:52:18 UTC 2011
State-Changed-Why:
thompsa@ has committed the patch to HEAD in r223846.
http://www.freebsd.org/cgi/query-pr.cgi?pr=156
Synopsis: [lagg][patch] Take lagg rlock before checking flags
State-Changed-From-To: patched->closed
State-Changed-By: maxim
State-Changed-When: Wed Jul 27 07:02:47 UTC 2011
State-Changed-Why:
Merged to RELENG_8.
http://www.freebsd.org/cgi/query-pr.cgi?pr=156
Synopsis: [pppd] [panic] Multiple panics kernel ppp suspected [regression]
State-Changed-From-To: open->closed
State-Changed-By: maxim
State-Changed-When: Fri Jul 29 08:07:19 UTC 2011
State-Changed-Why:
pppd(8) and its kernel code was removed from the base
long time ago.
http://www.freebsd.
The following reply was made to PR kern/179299; it has been noted by GNATS.
From: Maxim Bourmistrov
To: bug-follo...@freebsd.org,
sy...@prisjakt.nu
Cc:
Subject: Re: kern/179299: [igb] Intel X540-T2 - unstable driver
Date: Wed, 5 Jun 2013 13:18:10 +0200
Switch is STABLE.
Offload for rx
a patch for all the macros so that it
> actually gets committed to HEAD and MFC'd to /9 and /8?
Gleb already committed a fix for this 16 months ago
(unfortunately, correct patch description was lost in transit):
http://svnweb.freebsd.org/base?view=revision&revision=230584
Probably it
Hello!
On Fri, Jun 07, 2013 at 08:08:37AM +0200, Matthias Andree wrote:
> Am 07.06.2013 01:29, schrieb Maxim Dounin:
>
> > [...]
> >
> >> try.c:9:5: warning: dereferencing type-punned pointer will break
> >> strict-aliasing rules [-Wstrict-aliasing]
&g
The following reply was made to PR kern/179299; it has been noted by GNATS.
From: Maxim Bourmistrov
To: bug-follo...@freebsd.org,
sy...@prisjakt.nu
Cc:
Subject: Re: kern/179299: [igb] Intel X540-T2 - unstable driver
Date: Mon, 10 Jun 2013 13:32:32 +0200
I was able to reproduce this issue on
The following reply was made to PR kern/179299; it has been noted by GNATS.
From: Maxim Bourmistrov
To: bug-follo...@freebsd.org,
sy...@prisjakt.nu
Cc:
Subject: Re: kern/179299: [igb] Intel X540-T2 - unstable driver
Date: Tue, 11 Jun 2013 10:36:56 +0200
The card was new, but hardware was
On 11/7/2011 6:41 PM, Robert Watson wrote:
On Mon, 7 Nov 2011, Maxim Sobolev wrote:
On 11/7/2011 3:25 PM, Bjoern A. Zeeb wrote:
Now if you are clever you'd also log the inp there as the above will
only prove the case that something is wrong but still not help us in
anything to figur
to
ask if you could provide me with the patch that applies to the latest
8-STABLE for a test? I'd give it a spin on 2-3 production boxes. And
yes, those servers do a lot of socket ops per second, I'd say in the
order of hundreds if not thousands per second.
-Maxim
On 11/7/2011 3:2
to
ask if you could provide me with the patch that applies to the latest
8-STABLE for a test? I'd give it a spin on 2-3 production boxes. And
yes, those servers do a lot of socket ops per second, I'd say in the
order of hundreds if not thousands per second.
-Maxim
On 11/7/2011 3:2
solid in this regard. It saved us at least 10-15 crashes
across 5 machines in the last month.
Thanks!
-Maxim
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
a biggie.
By the way it would be interesting project to put libexecinfo interface
into the FreeBSD kernel. It would provide interesting new aspect of
debugging such rare non-critical conditions by dumping stack traces and
possibly doing some damage control in
On 12/30/2011 4:46 PM, Maxim Sobolev wrote:
I see. Would you guys mind if I put that NULL pointer check into the
code for the time being and turn it into some kind of big nasty warning
in 8-stable branch only?
I could also open a ticket, put all debug information collected to date
in there
Dear -net,
Today I want to present new packet filter for FreeBSD: userfw. It's
main design goal - to be easily extensible.
Source code is here: http://git.userfw.net/ https://github.com/gelraen/userfw/
Dedicated website: http://userfw.net/
userfw's packet processing is, much like ipfw's, based on
2012/2/13 Andrey V. Elsukov :
> On 13.02.2012 14:31, Maxim Ignatenko wrote:
>> Dear -net,
>>
>> Today I want to present new packet filter for FreeBSD: userfw. It's
>> main design goal - to be easily extensible.
>> Source code is here: http://git.userfw.net/
On пн, 13 лют 2012 19:25:42 Sami Halabi wrote:
> Hi Maxim,
> what are the other advantages on ipfw/pf ? like did you make speed
> measures? does packet leave the firewall faster?
There was no performance testing yet, I want to implement more functionality
first, to compare perfo
The following reply was made to PR kern/164490; it has been noted by GNATS.
From: Maxim Ignatenko
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/164490: [pfil] Incorrect IP checksum on pfil pass from
ip_output()
Date: Sat, 7 Apr 2012 10:17:20 +0300
Method described in http
s one
> of the solutions.
>
> http://dl.acm.org/citation.cfm?id=1592641
Is this article available for those without ACM subscription?
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
T
p->inp_cred)) {
> /*
> @@ -504,6 +504,9 @@
> if (ip->ip_id == 0)
> ip->ip_id = ip_newid();
>
> + ip->ip_len = htons(ip->ip_len);
> + ip->ip_off = htons(ip->ip_off);
> +
So t
t; - ip->ip_len += off;
> + ip->ip_len = ntohs(ip->ip_len) + off;
So, you've moved a switch to host byteorder into rip_input().
What about ip->ip_off then?
Note that this may also need some adjustments for protocols which use
rip_outp
recycle=1
net.inet.tcp.finwait2_timeout=30000
Maxim Dounin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Hello!
On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote:
> On 27.09.2010 10:12, Maxim Dounin wrote:
> >Hello!
> >
> >On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote:
> >
> >[...]
> >
> >>Andre, could you please take
ce Stewart wrote:
> >>>> On 11/07/10 17:32, Lawrence Stewart wrote:
> >>>>> On 11/03/10 09:30, Andre Oppermann wrote:
> >>>>>> On 02.11.2010 01:11, Maxim Dounin wrote:
> >>>>>>> Hello!
> >>>>>>>
>
by accident have some statefull
firewall between nginx and backend. E.g. pf(4) known to drop
some packets when it aproaches limit on state table size. Check
"pfctl -s info" and friends if you are using pf.
Maxim Dounin
___
freebsd-net@fre
may also want to check if you by accident have some statefull
> MD> firewall between nginx and backend.
> I have only ipfw rules, and the first rule is accepting local
> traffic: 5 8211184509 4547370329265 allow ip from me to me
>
> can this be
The following reply was made to PR bin/121359; it has been noted by GNATS.
From: Maxim Konovalov
To: bug-follo...@freebsd.org
Cc:
Subject: bin/121359
Date: Fri, 29 Jul 2011 12:53:19 +0400 (MSD)
Try the following patch (ported from OpenBSD):
Index: systems.c
---
The screenshot of the panic message is attached. This is pretty recent
8.2-STABLE. Any help is greatly appreciated. This particular bug has
haunted us for at least 4-5 months now.
Thanks!
-Maxim
___
freebsd-net@freebsd.org mailing list
http:
Panic screenshot is here:
http://sobomax.sippysoft.com/ScreenShot859.png
-Maxim
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote:
Unlikely; the inp is properly locked there and the udp info attach
better still be valid there; your problem is most likely elsewhere;
try to see if you have other threads and see what they do at the same
time, etc. You would need to race with udp_det
On 11/7/2011 2:57 PM, Maxim Sobolev wrote:
On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote:
Unlikely; the inp is properly locked there and the udp info attach
better still be valid there; your problem is most likely elsewhere;
try to see if you have other threads and see what they do at the same
mething is terribly wrong, up == NULL! inp = %p\n", inp);
Do you think of any other useful piece of information that I can log at
this point?
-Maxim
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
Giant r = 0 (0xc0910630) locked @
/usr/src/sys/kern/kern_intr.c:1125
Process 19 (swi4: clock sio) thread 0xc6ca (100011)
shared rw PFil hook read/write mutex r = 0 (0xc0965e58) locked @
/usr/src/sys/net/pfil.c:73
exclusive sleep mutex tcp_sc_head r = 0 (0xc6fd7ac0) locked @
/usr/src/sys/kern/ke
Hi,
My em0 interface repeatedly hangs up with watchdog timeout when
communicating to the windows host at MTU 9K.
[sobo...@pioneer ~]$ grep em0 /var/run/dmesg.boot
em0: port 0xecc0-0xecdf mem
0xfe6e-0xfe6f,0xfe6d9000-0xfe6d9fff irq 21 at device 25.0 on pci0
em0: Using MSI interrupt
e
The following reply was made to PR kern/140326; it has been noted by GNATS.
From: Maxim Sobolev
To: Jack Vogel
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/140326: em0: watchdog timeout when communicating to windows
using 9K MTU
Date: Fri, 06 Nov 2009 00:30:33 -0800
Jack
The following reply was made to PR kern/140326; it has been noted by GNATS.
From: Maxim Sobolev
To: Jack Vogel
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/140326: em0: watchdog timeout when communicating to windows
using 9K MTU
Date: Fri, 06 Nov 2009 01:58:52 -0800
Jack
+
+.include
Index: netgraph/ng_patch.c
===
--- netgraph/ng_patch.c (revision 0)
+++ netgraph
2010/1/12 Julian Elischer :
> Maxim Ignatenko wrote:
>>
>> Hi,
>> I've written netgraph node able to modify arbitrary (8|16|32)-bit
>> unsigned integer in passing packets. Node applies one of =,+,-,&,| and
>> ^ operations to number at given offset.
>&
Hi,
Our company have a FreeBSD based product that consists of the numerous
interconnected processes and it does some high-PPS UDP processing
(30-50K PPS is not uncommon). We are seeing some strange periodic
failures under the load in several such systems, which usually evidences
itself in IPC
Sergey Babkin wrote:
Maxim Sobolev wrote:
Hi,
Our company have a FreeBSD based product that consists of the numerous
interconnected processes and it does some high-PPS UDP processing
(30-50K PPS is not uncommon). We are seeing some strange periodic
failures under the load in several such
load level.
-Maxim
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
OK, here is some new data that I think rules out any issues with the
applications. Following Alfred's suggestion I have made a script to run
every second and output some system statistics:
date
netstat -m
vmstat -i
ps -axl
pstat -T
vmstat -z
sysctl -a
The problem had hit us again today several
Folks,
Indeed, it looks like igb(4) issue. Replacing the card with the
desktop-grade em(4)-supported card has fixed the problem for us. The
system has been happily pushing 110mbps worth of RTP traffic and 2000
concurrent calls without any problems for two days now.
e...@pci0:7:0:0: class=0x0
Jack Vogel wrote:
This thread is confusing, first he says its an igb problem, then you
offer an em patch :)
I suspect it could be patch for the kern/140326.
-Maxim
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
applications under the load. The following patch makes IFQ_MAXLEN a
tunable. I am also tempted to bump the default value for IFQ_MAXLEN
10-fold, but would like to hear what do people think about it first.
http://sobomax.sippysoft.com/IFQ_MAXLEN.diff
-Maxim
Julian Elischer wrote:
On 4/30/10 1:23 PM, Maxim Sobolev wrote:
Hi,
Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to
set length of the outgoing packets queue. The default value for that
parameter is only 50, which is pretty low especially for the cases when
the system
Gary Jennejohn wrote:
On Fri, 30 Apr 2010 13:23:13 -0700
Maxim Sobolev wrote:
Hi,
Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to
set length of the outgoing packets queue. The default value for that
parameter is only 50, which is pretty low especially for the cases
Extended and improved version of ng_patch node:
1) added new operations ('*', '/', unary '-', '<<', '>>')
2) single node now able to apply arbitrary number of changes
3) m_pullup replaced with m_copydata/m_copyback
4) ntoh/hton used to apply changes correctly
5) checksum handling
6) added some stat
you please take a look at the patch and
commit it if found appropriate?
# HG changeset patch
# User Maxim Dounin
# Date 1279028684 -14400
# Node ID 93699203f408fa8e22c971769bde9c26bd14d410
# Parent e2cf8c51a6294a0d09d5628d96c6ab3ab626957e
Fix cwnd resetting problem introduced in r171639.
Sc_rxm
Hello!
On Fri, Aug 06, 2010 at 10:56:40AM +0200, Andre Oppermann wrote:
> On 13.07.2010 16:01, Maxim Dounin wrote:
> >On Wed, May 12, 2010 at 04:47:02PM +0400, Igor Sysoev wrote:
> >
> >>It seems that net.inet.tcp.slowstart_flightsize does not work in 8-STABLE.
&g
ps this is one of the causes of "my loopback is slow vs linux".
>
> FWIW, I couldn't find a way to turn off dealyed_ack on just loopback
> interface.
AFAIK in linux delayed ack behaves a bit more gently and doesn't
delay firs
Hello!
On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote:
[...]
> Andre, could you please take a look at one more patch as well?
>
> Igor reported that it still sees 100ms delays with rfc3465 turned
> on, and it turns out to be similar issue (setting cwnd to 1*MSS)
The following reply was made to PR kern/132715; it has been noted by GNATS.
From: Maxim Ignatenko
To: bug-follo...@freebsd.org, g...@wp.pl
Cc:
Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg
interface
Date: Mon, 20 Apr 2009 18:46:32 +0300
This panic
Hi,
I have next dummynet configuration:
ipfw pipe 3 bw 3Mbit/s
ipfw queue 10 config pipe 3 weight 10 mask src-ip 0x
ipfw queue 11 config pipe 3 weight 10 mask dst-ip 0x
Two queues for different traffic directions connected to one pipe.
After update to r191410 my /var/
2009/4/27 Luigi Rizzo :
>
> could you give us a few more details on the branch you
> are using (HEAD or RELENG_7 ?) and what svn revision did
> you use before the update (which did not show the error) ?
>
Sorry, I've forgot to mention that...
I use HEAD, and before update it was r191201, if I'm no
2009/4/27 Luigi Rizzo :
> On Mon, Apr 27, 2009 at 01:12:55AM +0300, Maxim Ignatenko wrote:
>> 2009/4/27 Luigi Rizzo :
>> >
>> > could you give us a few more details on the branch you
>> > are using (HEAD or RELENG_7 ?) and what svn revision did
>> >
2009/4/27 Luigi Rizzo :
>
> ok there seems to be no change related to dummynet between these
> two versions so I am not sure where to look.
> Could you double check what is the last working version ?
>
Yes, r191201 have this problems too (it seems, i didn't updated for a
long time).
Now I updated
2009/4/27 Luigi Rizzo :
> On Mon, Apr 27, 2009 at 04:51:18PM +0300, Maxim Ignatenko wrote:
>> 2009/4/27 Luigi Rizzo :
>> >
>> > ok there seems to be no change related to dummynet between these
>> > two versions so I am not sure where to look.
>> > Co
2009/4/27 Oleg Bulyzhin :
>
> Perhaps you stepped on this:
>
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=879027+0+archive/2009/svn-src-all/20090419.svn-src-all
>
> You can try to change type of dn_pipe.numbytes to int64_t (instead of dn_key).
> (ip_dummynet.h:341)
>
This is exactly what is done
The following reply was made to PR kern/132715; it has been noted by GNATS.
From: Maxim Ignatenko
To: bug-follo...@freebsd.org, g...@wp.pl
Cc: freebsd-curr...@freebsd.org
Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg
interface
Date: Tue, 28 Apr 2009
The following reply was made to PR kern/132715; it has been noted by GNATS.
From: Maxim Ignatenko
To: bug-follo...@freebsd.org, g...@wp.pl
Cc: freebsd-curr...@freebsd.org
Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg
interface
Date: Tue, 28 Apr 2009
The following reply was made to PR kern/132715; it has been noted by GNATS.
From: Maxim Ignatenko
To: bug-follo...@freebsd.org, g...@wp.pl
Cc: freebsd-curr...@freebsd.org
Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg
interface
Date: Tue, 28 Apr 2009
Hi folks,
We've trying to migrate some of our high-PPS systems to a new hardware that
has four X540-AT2 10G NICs and observed that interrupt time goes through
roof after we cross around 200K PPS in and 200K out (two ports in LACP).
The previous hardware was stable up to about 350K PPS in and 350K
below lagg.
-Maxim
On Tue, Aug 11, 2015 at 3:22 PM, hiren panchasara <
hi...@strugglingcoder.info> wrote:
> On 08/11/15 at 03:16P, hiren panchasara wrote:
> >
> > There were some lagg/hashing related changes recently so let us know if
> > that is hurting you.
>
> Ah
build with IXGBE_FDIR by default on 10 so I assume
> it's off.
>
> There were some lagg/hashing related changes recently so let us know if
> that is hurting you.
>
> Cheers,
> Hiren
> >
> >
> >
> > -adrian
> >
> >
> > On 11 August 20
ochard-Labbé
wrote:
> On Tue, Aug 11, 2015 at 11:18 PM, Maxim Sobolev
> wrote:
>
>> Hi folks,
>>
>> Hi,
>
>
>
>> We've trying to migrate some of our high-PPS systems to a new hardware
>> that
>> has four X540-AT2 10G NICs and observed that
.
>
> BC
>
>
>
> On Tuesday, August 11, 2015 7:15 PM, Olivier Cochard-Labbé <
> oliv...@cochard.me> wrote:
>
>
> On Tue, Aug 11, 2015 at 11:18 PM, Maxim Sobolev
> wrote:
>
> > Hi folks,
> >
> > Hi,
>
>
>
> > We've tr
omewhat puzzling
why something that worked with old-gen hardware/driver almost out of the
box now needs some extra tuning. Thanks everyone for useful suggestions in
any case!
On Tue, Aug 11, 2015 at 4:04 PM, Luigi Rizzo wrote:
> On Wed, Aug 12, 2015 at 12:46 AM, Maxim Sobolev
> wrote:
> >
.enable_aim: 0
hw.ix.num_queues:6
We also happen to have I210-based system with only 4 hardware queues, it
would be interesting to see how it stacks up.
On Wed, Aug 12, 2015 at 5:23 AM, Luigi Rizzo wrote:
> As I was telling to maxim, you should disable aim because it only matches
> t
15d9 chip=0x15338086
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'I210 Gigabit Network Connection'
class = network
subclass = ethernet
On Wed, Aug 12, 2015 at 8:03 AM, Maxim Sobolev
wrote:
> Ok, so my current settings are:
>
orporation'
device = 'Ethernet Controller 10-Gigabit X540-AT2'
class = network
subclass = ethernet
On Wed, Aug 12, 2015 at 8:23 AM, Adrian Chadd
wrote:
> Right, and for the ixgbe hardware?
>
>
>
> -a
>
>
> On 12 August 2015 at 08:05,
Thanks, we'll try that as well. We have not got as much traffic in the past
2 days, so we were running at about 140Kpps, well below the level that used
to cause issues before. I'll try to redistribute traffic tomorrow so that
we get it tested.
-Max
On Wed, Aug 12, 2015 at 11:47 PM, Adrian Chadd
ppysoft.com/ScreenShot394.png <- cpu/net monitoring, first
two spikes are with max_interrupt_rate = 2, the third one
max_interrupt_rate
= 1
-Max
On Wed, Aug 12, 2015 at 5:23 AM, Luigi Rizzo wrote:
> As I was telling to maxim, you should disable aim because it only matches
> the max i
t.com/ScreenShot395.png
On Fri, Aug 14, 2015 at 10:29 AM, Maxim Sobolev wrote:
> Hi guys, unfortunately no, neither reduction of the number of queues from
> 8 to 6 nor pinning interrupt rate at 2 per queue have not made any
> difference. The card still goes kaboom at about 200Kpps no matter w
I think we are getting a better performance today with the IXGBE_FDIR
switched off. It's not 100% decisive though, since we've only pushed it to
little bit below 200kpps. We'll push more traffic tomorrow and see how it
goes.
-Maxim
On Fri, Aug 14, 2015 at 10:29 AM, Maxim Sobole
Yes, we've confirmed it's IXGBE_FDIR. That's good it comes disabled in 10.2.
Thanks everyone for constructive input!
-Max
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "f
Hi John & others,
We've came across a weird MSI routing issue on one of our newest dual
E5-2690v3 (haswell) Supermicro X10DRL-i boxes running latest 10.2-p4. It is
fitted with dual port Intel I350 card, in addition to the built-in I210
chip that is not used. The hw.igb.num_queues is set to 4, and
1 0-23
11 100142 intr swi0: uart uart01 0-23
On Mon, Oct 19, 2015 at 2:03 PM, John Baldwin wrote:
> On Thursday, October 08, 2015 07:33:27 AM Maxim Sobolev wrote:
> > Hi John & others,
> >
> > We've came across a weird MSI routing issue on
wrote:
> On Tuesday, October 20, 2015 06:31:47 PM Maxim Sobolev wrote:
> > Here you go:
> >
> > $ sudo procstat -S 11
> > PIDTID COMM TDNAME CPU CSID CPU MASK
> >11 100082 intr irq269: igb1:que 41 4
> >11 1
upstream switch is not doing proper load
balancing between two ports. We'll take it to the DC to fix.
Thanks John, for helping to drill that down!
On Wed, Oct 21, 2015 at 11:31 AM, John Baldwin wrote:
> On Wednesday, October 21, 2015 11:29:17 AM Maxim Sobolev wrote:
> > Yes, I do. H
Synopsis: [netinet] potentially a bug for inet_aton in
sys/netinet/libalias/alias_proxy.c
State-Changed-From-To: open->patched
State-Changed-By: maxim
State-Changed-When: Mon Apr 30 20:22:26 UTC 2007
State-Changed-Why:
Fixed in HEAD. Thanks!
Responsible-Changed-From-To: freebsd-net->
Synopsis: [ipv6] deadlock occurs if a tunnel goes down while there are tcp6
connections opened
State-Changed-From-To: open->closed
State-Changed-By: maxim
State-Changed-When: Sun Jun 10 10:04:13 UTC 2007
State-Changed-Why:
The submitter reports he can't reproduce the problem any mor
5 or 6 weeks ago doesn't seem to be bothered by this issue.
>
> Has anybody else seen it? Is there a fix being tested? I can trigger
> it trivially here...
>
Try to turn net.inet.tcp.rfc1323 off.
--
Maxim Konovalov
___
freebsd
y.
>
> Given all that, I'm not sure which of the above to try.
>
There are several obvious sysctls can affect:
net.inet.ip.portrange.randomized, net.inet.ip.portrange.*.
We definitly need more debug info: vmstat -zm, netstat -anp tcp,
netstat -m, sysctl net.inet from his system. It would be nice if he
gives a shell to the problem box.
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
f(8) just parses net.inet.tcp.pcblist OID. You could look
at struct xtcpcb definition and extract xtcpcb.xt_socket.so_options
from the above sysctl.
HTH.
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/
ooked sources and found that in early versions the sent counter
> was simply not incremented at all. The patch attached.
>
[...]
The patch has beed committed to RELENG_6. Thanks!
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists
-sp tcp | grep cook
51588 cookies sent
25 cookies received
$ uname -r
6.2-STABLE
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nding out more about the socket thats been created and what its
> clashing with might help. I'd do it myself but I'm not sure how to
> duplicate the issue.
>
Have you tried to turn net.inet.ip.portrange.randomized off?
--
Maxim Konovalov
tem he cites that were
> unable to connect correctly send timestamps and do not stop after
> the SYN phase. So there must be something else at play here. Have
> you received or heart of any *other* reports that may be related to
> the timestamp check?
>
I saw this with my adsl router
On Thu, 24 Jan 2008, 13:52+0100, Andre Oppermann wrote:
> Maxim Konovalov wrote:
> > [...]
> > > > I'm not generally opposed to security improvements that only affect edge
> > > > cases... but being unable to connect is not an edge case!
> > > Fully
> > The latter. Turning rfc1323 off solved the problem.
> >
> > It takes some time to obtain the dump -- I need to downgrade the
> > system.
>
> That is not necessary. A tcpdump from current is fine.
>
OK, later this even
On Thu, 24 Jan 2008, 17:20+0300, Maxim Konovalov wrote:
> > > The latter. Turning rfc1323 off solved the problem.
> > >
> > > It takes some time to obtain the dump -- I need to downgrade the
> > > system.
> >
> > That is not necessary. A tc
o new
dumps now:
http://maxim.int.ru/stuff/adsl.failed.dmp.gz
The adsl router displays login page but never returns the second page.
http://maxim.int.ru/stuff/adsl.rfc1323=0.dmp.gz
This one works.
--
Maxim Konovalov
___
freebsd-net@freebsd.org ma
e adsl modem.
> It's really broken and in complete disregard of even the basic
> standards. The vendor should fix it, not us work around it.
>
It used to work for years and works now. I see no point to make
FreeBSD to not work with countless devic
much a WIP at the moment. I want
> to get this into the tree in before 5.3 code freeze.
In fact, our real world tests shown the current -CURRENT comparing to
RELENG_5_2 is in a very bad shape. Is it really worth to commit that
mostly cleanup code before say 6-CURRE
On Tue, 22 Jun 2004, 11:23+0200, Dag-Erling Sm?rgrav wrote:
> Maxim Konovalov <[EMAIL PROTECTED]> writes:
> > In fact, our real world tests shown the current -CURRENT comparing to
> > RELENG_5_2 is in a very bad shape.
>
> You'll have to substantiate that. All
On Tue, 22 Jun 2004, 02:06-0700, Luigi Rizzo wrote:
> On Tue, Jun 22, 2004 at 12:15:21PM +0400, Maxim Konovalov wrote:
> ...
> > > Consider this a FYI. It is very much a WIP at the moment. I want
> > > to get this into the tree in before 5.3 code freeze.
> >
>
On Tue, 22 Jun 2004, 11:49+0200, Dag-Erling Sm?rgrav wrote:
> Maxim Konovalov <[EMAIL PROTECTED]> writes:
> > Yesterday -CURRENT leaks kernel memory very quickly and panics after
> > 10 - 15 mins up.
>
> Nope. That bug was introduced on June 9th, almost two weeks ago,
On Tue, 22 Jun 2004, 13:38+0200, Andre Oppermann wrote:
> Maxim Konovalov wrote:
> >
> > Hi Andre,
> >
> > On Mon, 21 Jun 2004, 23:36+0200, Andre Oppermann wrote:
> >
> > > Here is the next preview patch for the ipfw to pfil_hooks conversion:
>
1 - 100 of 214 matches
Mail list logo
