Re: question in tcp_do_segment()

2012-07-15 Thread Sepherosa Ziehau 
On Sat, Jul 14, 2012 at 1:54 AM, Reese Faucette  wrote:
> Hi, freebsd-net-
>
> I don't have a testcase for this at the moment, but there's a test
> in tcp_do_segment that looks backwards to me...
>
> http://svnweb.freebsd.org/base/release/9.0.0/sys/netinet/tcp_input.c?view=markup
>
> line 2398 -
> if (!tcp_timer_active(tp, TT_REXMT) ||
> th->th_ack != tp->snd_una)
>tp->t_dupacks = 0;
>
> says "If we get a DUP ack and the retransmit timer is NOT
> fired, then ignore it and reset DUP ACK count."
>
> Isn't that exactly backwards?  I could see ignoring the DUP ACK if we
> know the retransmit timer HAS fired, and we don't want to interfere with
> its retransmission efforts.  The way the code is written now, as far as
> I can see, completely defeats retransmission based on DUP acks.  I
> accidentally ran across this by breaking the timer, so that the
> retransmit timer never fires, and my streams get stuck, even with plenty of
> DUP ACKs.
>
> Am I missing something, or should that "!" go ?

!tcp_timer_active() means that the connection's retransmit timer is
not _set_ yet (please note, it is _not_ "has fired").  As far as I
understand this code, it in turn means that this connection doesn't
have any segments that were sent but not yet ACKed.

Best Regards,
sephe

-- 
Tomorrow Will Never Die
___
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"

IPv6 toolkit v1.2

2012-07-15 Thread Fernando Gont 
Folks,

FYI, we've released "IPv6 toolkit v1.2": a set of IPv6 security
assessment tools that were produced as part of a project I carried out
on behalf of the UK CPNI.

The tarball for version 1.2 of the tool is available at:
http://www.si6networks.com/research/ipv6-toolkit-v1.2.tar.gz>

Additionally, we have a git repository for the tool:


This toolkit can be employed to perform local IPv6 scans, assess a
number of security aspects of IPv6 implementations, such as
predictability of Fragment ID values, etc. It can also be employed to
play with IPv6 address resolution, SLAAC, etc.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




___
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"

Re: IPv6 toolkit v1.2

2012-07-15 Thread Hiroki Sato 
Hi,

Fernando Gont  wrote
  in <5002e024.4090...@gont.com.ar>:

fe> Folks,
fe>
fe> FYI, we've released "IPv6 toolkit v1.2": a set of IPv6 security
fe> assessment tools that were produced as part of a project I carried out
fe> on behalf of the UK CPNI.
fe>
fe> The tarball for version 1.2 of the tool is available at:
fe> http://www.si6networks.com/research/ipv6-toolkit-v1.2.tar.gz>
fe>
fe> Additionally, we have a git repository for the tool:
fe> 
fe>
fe> This toolkit can be employed to perform local IPv6 scans, assess a
fe> number of security aspects of IPv6 implementations, such as
fe> predictability of Fragment ID values, etc. It can also be employed to
fe> play with IPv6 address resolution, SLAAC, etc.

 FYI, I am working on creating a port of your toolkit and will commit
 it into the ports collection.

-- Hiroki


pgpPNDliu6Gnl.pgp
Description: PGP signature

Re: IPv6 toolkit v1.2

2012-07-15 Thread Fernando Gont 
On 07/15/2012 04:38 PM, Hiroki Sato wrote:
> 
> FYI, I am working on creating a port of your toolkit and will
> commit it into the ports collection.

Great! -- Please make sure to use this version of the tool (v1.2),
rather than the one that had been announced a couple of weeks ago,
since it contains a number of fixes.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





___
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"

Re: question in tcp_do_segment()

2012-07-15 Thread Reese Faucette 

On 7/15/2012 3:26 AM, Sepherosa Ziehau wrote:


!tcp_timer_active() means that the connection's retransmit timer is
not _set_ yet (please note, it is _not_ "has fired").  As far as I
understand this code, it in turn means that this connection doesn't
have any segments that were sent but not yet ACKed.


You'd think that was the case from the name, but tcp_timer_active() 
calls callout_active() which checks for fired.  If you want to check for 
"timer set" you need to use callout_pending().

-reese


___
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"

Re: mpd5/Netgraph issues after upgrading to 7.4

2012-07-15 Thread Mike Tancsa 
On 7/10/2012 2:24 AM, Przemyslaw Frasunek wrote:
>> It seems, Przemyslaw Frasunek uses proxyarp?
>> I have no such problems but I do not use proxyarp.
>> Could you get rid of it, Przemyslaw?
> 
> No, I don't use proxy ARP. I have about 300 PPPoE ng interfaces and 10 VLANs
> with plain IP traffic. ARP table has only < 50 entries, all of them are 
> dynamic.

I had a new one. Unfortunately, it did not generate a coredump file for
some reason.  Kernel was from ~ mid Feb

Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 02
instruction pointer = 0x20:0x80496e59
stack pointer   = 0x28:0xff8863b0
frame pointer   = 0x28:0xff8863c0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13 (ng_queue1)
trap number = 9
panic: general protection fault
cpuid = 1
KDB: stack backtrace:
#0 0x803f922e at kdb_backtrace+0x5e
#1 0x803c6437 at panic+0x187
#2 0x80646e30 at trap_fatal+0x290
#3 0x8064736a at trap+0x10a
#4 0x8062eb94 at calltrap+0x8
#5 0x8049835b at ng_l2tp_rcvdata_lower+0x42b
#6 0x8048f380 at ng_apply_item+0x420
#7 0x80491790 at ng_snd_item+0x3f0
#8 0x804962ba at ng_ksocket_incoming2+0x24a
#9 0x8048f50d at ng_apply_item+0x5ad
#10 0x804912be at ngthread+0x22e
#11 0x8039b08f at fork_exit+0x11f
#12 0x8062f0de at fork_trampoline+0xe
Uptime: 151d12h10m10s
ipfw: 11 Deny TCP 192.168.1.99:33822 208.47.254.32:80 in via ng471
Dumping 883 out of 8145 MB:ipfw: 13 Deny UDP 64.7.157.21:512
192.168.254.46:137 in via ng21
panic: bufwrite: buffer is not busy???
cpuid = 1
Uptime: 151d12h10m10s





-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

Re: Major performance hit with ToS setting

2012-07-15 Thread Kevin Oberman 
On Sun, Jun 3, 2012 at 5:22 PM, Lawrence Stewart  wrote:
> On 06/03/12 15:18, Kevin Oberman wrote:
>>
>> On Fri, Jun 1, 2012 at 2:48 AM, Lawrence Stewart
>>  wrote:
>>>
>>> On 05/31/12 13:33, Kevin Oberman wrote:
>>> [snip]


 I used SIFTR at the suggestion of Lawrence Stewart who headed the

 project to bring plugable congestion algorithms to FreeBSD and found
 really odd congestion behavior. First, I do see a triple ACK, but the
 congestion window suddenly drops from 73K to 8K. If I understand
 CUBIC, it should half the congestion window, not what is happening..
 It then increases slowly (in slow start) to 82K. while the slow-start
 bytes are INCREASING, the congestion window again goes to 8K while the
 SS size moves from 36K up to 52K. It just continues to bound wildly
 between 8K (always the low point) and between 64k and 82K. The swings
 start at 83K and, over the first few seconds the peaks drop to about
 64K.
>>>
>>>
>>>
>>> Oh, and a comment about this behaviour. Dropping back to 8k (1MSS) is
>>> only
>>> nasty if the TF_{CONG|FAST}RECOVERY flags are *not* set i.e. if you see
>>> cwnd
>>> grow, drop to 8k with those flags set, and then when the flags are unset,
>>> cwnd starts at the value of ssthresh, then that is perfectly normal
>>> recovery
>>> behaviour. What *is* nasty is if an RTO fires, which will reset cwnd to
>>> 8k,
>>> ssthresh to 2*MSS and make the connection effectively start from scratch
>>> again.
>>>
>>> There is evidence of RTOs in your siftr output, which is bad news e.g
>>> here's
>>> one example of 2 side-by-side log lines from your trace:
>>>
>>> # Direction,time,ssthresh,cwnd,flags
>>> i,1338319593.574706,27044,27044,1630544864
>>> o,1338319593.831482,16384,8192,1092625377
>>>
>>> Note the 300ms gap, and how cwnd resets to 1MSS and flags go from
>>> 1630544864
>>> (TF_WASCRECOVERY|TF_CONGRECOVERY|TF_WASFRECOVERY|TF_FASTRECOVERY) to
>>> 1092625377 (TF_WASCRECOVERY|TF_WASFRECOVERY).
>>
>>
>> What can I say but that you are right. When I looked at the interface
>> stats I found that the link overflow drops were through the roof! This
>> confuses me a bit since the traffic is outbound and I woudl assume
>> from the description on hte Myricom web page that these are input
>> drops. A problem a problem with that card?  On systems that are
>> working "normally", I still see a sharp drop with the ToS bits set,
>> but nothing nearly as drastic. Now it is a drop from 4.5G to 728M on a
>> cross-country (US) circuit.
>>
>> I am now looking for issues on the route that might explain the
>> performance, but the question of why the drop-of only shows up in
>> FreeBSD 8 means something odd is still going on. It is even possible
>> that the problem is with 7 and the losses are due to the policy for
>> ToS 32 on the path. ToS 32 is less than best effort in our network.
>> Maybe the marking was getting lost on 7. Not likely, but possible.
>
>
> The receiver is FreeBSD 7? If so, have you tuned your reassembly queue on
> that machine? If not, that could explain the RTOs you're seeing. Send
> through the output of "sysctl net.inet.tcp.reass" and "netstat -sp tcp"
> obtained from the receiver immediately before and after running a short
> ToS=32 test.

I just wanted to let those kind enough to help with this that I have
analyzed the problem and pretty much understand what is happening.

I've done a lot of testing fully understand what is going on. First,
the problem is clearly tied to FreeBSD 8, but it is not anything wrong
with FreeBSD. Instead it is a real fluke problem with the handing of
the DSCP and TOS bits by a single Juniper router when TSO is used. V7
did not support TOS, so v7 does not show the problem.

I have done packet capture on both ends and something really strange
happens with the TSO. I see a couple of large segments move normally.
Then things start getting weird. As soon as slow-start allows things
to speed up just a bit, the second segment of a transfer is discarded
and  TCP tries to recover, but with the long pipe (RTT is around 50
ms. at 10G, there is a lot of data in the pipe when the problem is
detected and the NAK is sent. Actually, 7 or 8 are sent before the
transmitting system receives one and can start to recover. Then, it
just happens again and again.

the root problem is a router that seems to be re-marking the ToS bits
from 0x20 to 0x24 which is adding the "loss priority" bit. Even though
the circuit is not busy, TSO results in all segments being sent
"back-to-back" and, with the change in the IP Precedence bits, the
second packet gets dropped if ANY other traffic is present.

We have a ticket open with the router vendor and I hope that we can
get this resolved quickly, but I would not bet on it. In nay case, it
is not a FreeBSD issue, though some  what I see makes me suspect that
our stack may not be responding well to this situation of massive loss
in large segments. But the losses are so severe that I am far

Re: mpd5/Netgraph issues after upgrading to 7.4

2012-07-15 Thread Bjoern A. Zeeb 

On 15. Jul 2012, at 20:54 , Mike Tancsa wrote:

> On 7/10/2012 2:24 AM, Przemyslaw Frasunek wrote:
>>> It seems, Przemyslaw Frasunek uses proxyarp?
>>> I have no such problems but I do not use proxyarp.
>>> Could you get rid of it, Przemyslaw?
>> 
>> No, I don't use proxy ARP. I have about 300 PPPoE ng interfaces and 10 VLANs
>> with plain IP traffic. ARP table has only < 50 entries, all of them are 
>> dynamic.
> 
> I had a new one. Unfortunately, it did not generate a coredump file for
> some reason.  Kernel was from ~ mid Feb
> 
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 1; apic id = 02
...
> Uptime: 151d12h10m10s
> ipfw: 11 Deny TCP 192.168.1.99:33822 208.47.254.32:80 in via ng471
> Dumping 883 out of 8145 MB:ipfw: 13 Deny UDP 64.7.157.21:512
> 192.168.254.46:137 in via ng21
> panic: bufwrite: buffer is not busy???
> cpuid = 1
> Uptime: 151d12h10m10s

Hmm this one means we didn't stop all CPUs properly on panic;  I think that
was fixed since?  At least it's the reason you didn't have a chance to get
the core dump.

However of course the initial problem leading to the panic of course
is its own issue still.

-- 
Bjoern A. Zeeb You have to have visions!
   It does not matter how good you are. It matters what good you do!

___
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"

Re: question in tcp_do_segment()

2012-07-15 Thread Sepherosa Ziehau 
On Sun, Jul 15, 2012 at 11:47 PM, Reese Faucette  wrote:
> On 7/15/2012 3:26 AM, Sepherosa Ziehau wrote:
>
>> !tcp_timer_active() means that the connection's retransmit timer is
>> not _set_ yet (please note, it is _not_ "has fired").  As far as I
>> understand this code, it in turn means that this connection doesn't
>> have any segments that were sent but not yet ACKed.
>
>
> You'd think that was the case from the name, but tcp_timer_active() calls
> callout_active() which checks for fired.  If you want to check for "timer

Hmm, callout_active() is not used to check for whether the callout is
fired or not; it is used to check whether callout_reset() has been
called but callout_stop() is not yet been called.  IMO,
callout_reset() is "set" the callout, callout_stop() is "unset" the
callout.

AFAIR, callout_pending() is kinda check for whether the callback
function of the callout "is being executed" or not (PENDING bit is
probably cleared immediately before running the callback function).

Best Regards,
sephe

> set" you need to use callout_pending().
> -reese
>
>



-- 
Tomorrow Will Never Die
___
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"

Re: Interface MTU question...

2012-07-15 Thread Jason Hellenthal 

Filed as,

http://www.freebsd.org/cgi/query-pr.cgi?pr=169898


Thanks for looking into this when you get time.


On Thu, Jul 12, 2012 at 04:49:23PM -0400, George Neville-Neil wrote:
> 
> On Jul 12, 2012, at 12:55 , Jason Hellenthal wrote:
> 
> > 
> > 
> > On Thu, Jul 12, 2012 at 10:55:16AM -0400, George Neville-Neil wrote:
> >> 
> >> On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote:
> >> 
> >>> On 07/11/12 14:30, g...@freebsd.org wrote:
>  Howdy,
>  
>  Does anyone know the reason for this particular check in
>  ip_output.c?
>  
>   if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) {
>   /*
>    * This case can happen if the user changed the MTU
>    * of an interface after enabling IP on it.  Because
>    * most netifs don't keep track of routes pointing to
>    * them, there is no way for one to update all its
>    * routes when the MTU is changed.
>    */
>   if (rte->rt_rmx.rmx_mtu > ifp->if_mtu)
>   rte->rt_rmx.rmx_mtu = ifp->if_mtu;
>   mtu = rte->rt_rmx.rmx_mtu;
>   } else {
>   mtu = ifp->if_mtu;
>   }
>  
>  To my mind the > ought to be != so that any change, up or down, of the
>  interface MTU is eventually reflected in the route.  Also, this code
>  does not check if it is both a HOST route and UP, but only if it is
>  one other the other, so don't be fooled by that, this check happens
>  for any route we have if it's up.
> >>> 
> >>> I believe rmx_mtu could be low due to some intermediate node between this 
> >>> host and the final destination.  An increase in the MTU of the local 
> >>> interface should not increase the path MTU if the limit was due to 
> >>> someone else along the route.
> >> 
> >> Yes, it turns out to be complex.  We have several places that store the 
> >> MTU.  There is the interface,
> >> which knows the MTU of the directly connected link, a route, and the host 
> >> cache.  All three of these
> >> are used to determine the maximum segment size (MSS) of a TCP packet.  The 
> >> route and the interface
> >> determine the maximum MTU that the MSS can have, but, if there is an entry 
> >> in the host cache
> >> then it is preferred over either of the first two.  See tcp_update_mss() 
> >> in tcp_input.c to
> >> see what I'm talking about.
> >> 
> >> I believe that the quoted code above has been wrong from the day it was 
> >> written, in that what it
> >> really says is "if the route is up" and not "if the route is up and is a 
> >> host route" which is
> >> what I believe people to read that as.  If the belief is that this code is 
> >> really only there for
> >> hosts routes, then the proper fix is to make the sense of the first if 
> >> match that belief
> >> and, again, to change the > to != so that when the administrator of the 
> >> box bumps the MTU in
> >> either direction that the route reflects this.  It is not possible for 
> >> PMTU on a single link
> >> to a host route to bump the number down if the interface says it's not to 
> >> be bumped.  And,
> >> even so, any host cache entry will override and avoid this code.
> >> 
> > 
> > Something else to look into ... 
> > 
> > # ifconfig lagg0 mtu 1492
> > ifconfig: ioctl (set mtu): Invalid argument
> > 
> > This is on stable/8 r238264 when the interface was up/up and down/down
> > 
> > Also attempted on the member interfaces dc0 and dc1
> > 
> 
> Can you file a bug on that one?
> 
> Best,
> George
> 

-- 

 - (2^(N-1))


pgpxJ9QsRxtJ2.pgp
Description: PGP signature

Re: kern/169620: [ng] [pf] ng_l2tp incoming packet bypass pf firewall

2012-07-15 Thread linimon 
Old Synopsis: ng_l2tp incomming packet bypass pf firewall
New Synopsis: [ng] [pf] ng_l2tp incoming packet bypass pf firewall

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jul 16 02:54:51 UTC 2012
Responsible-Changed-Why: 
reclassify.

http://www.freebsd.org/cgi/query-pr.cgi?pr=169620
___
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"

Re: kern/169634: [bge] Network unavailable when booting directly to FreeBSD

2012-07-15 Thread linimon 
Old Synopsis: bge: Network unavailable when booting directly to FreeBSD
New Synopsis: [bge] Network unavailable when booting directly to FreeBSD

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jul 16 02:58:21 UTC 2012
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=169634
___
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"

Re: kern/169664: [bgp] Wrongful replacement of interface connected net route

2012-07-15 Thread linimon 
Old Synopsis: Wrongful replacement of interface connected net route
New Synopsis: [bgp] Wrongful replacement of interface connected net route

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jul 16 03:03:35 UTC 2012
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=169664
___
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"

Re: kern/169676: [bge] [hang] system hangs, fully or partially after receiving watchdog timeouts on bge

2012-07-15 Thread linimon 
Old Synopsis: system hangs, fully or partially after receiving watchdog 
timeouts on bge
New Synopsis: [bge] [hang] system hangs, fully or partially after receiving 
watchdog timeouts on bge

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jul 16 03:05:30 UTC 2012
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=169676
___
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"

Re: kern/169826: [re] if_re no longer working in 9.x [regression]

2012-07-15 Thread linimon 
Old Synopsis: if_re no longer working in 9.x
New Synopsis: [re] if_re no longer working in 9.x [regression]

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jul 16 03:15:41 UTC 2012
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=169826
___
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"

Re: question in tcp_do_segment()

2012-07-15 Thread Reese Faucette 

On 7/15/2012 6:53 PM, Sepherosa Ziehau wrote:

On 7/15/2012 3:26 AM, Sepherosa Ziehau wrote:

Hmm, callout_active() is not used to check for whether the callout is
fired or not; it is used to check whether callout_reset() has been
called but callout_stop() is not yet been called.  IMO,
callout_reset() is "set" the callout, callout_stop() is "unset" the
callout.


OK, sorry, I was going by the callout implementation in 8.0 - I compared 
sources and the tcp_input code was roughly the same, tcp_timer_*() was 
roughly the same, but since all that was the same, I did not dig all the 
way to the bottom of callout_reset() implementation, and I see that the 
semantics of callout_active() have changed to be as you describe.  My 
callout_active() from 8.0 is:

#define callout_active(c)   ((c)->c_flags & CALLOUT_FIRED)
hence, my lame claims about the behavior.
Sorry for the noise...
-reese


___
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"

Re: kern/169898: ifconfig(8) fails to set MTU on multiple interfaces.

2012-07-15 Thread linimon 
Synopsis: ifconfig(8) fails to set MTU on multiple interfaces.

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jul 16 03:16:57 UTC 2012
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=169898
___
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"

Re: mpd5/Netgraph issues after upgrading to 7.4

2012-07-15 Thread Eugene Grosbein 
16.07.2012 07:13, Bjoern A. Zeeb пишет:
> 
> On 15. Jul 2012, at 20:54 , Mike Tancsa wrote:
> 
>> On 7/10/2012 2:24 AM, Przemyslaw Frasunek wrote:
 It seems, Przemyslaw Frasunek uses proxyarp?
 I have no such problems but I do not use proxyarp.
 Could you get rid of it, Przemyslaw?
>>>
>>> No, I don't use proxy ARP. I have about 300 PPPoE ng interfaces and 10 VLANs
>>> with plain IP traffic. ARP table has only < 50 entries, all of them are 
>>> dynamic.
>>
>> I had a new one. Unfortunately, it did not generate a coredump file for
>> some reason.  Kernel was from ~ mid Feb
>>
>> Fatal trap 9: general protection fault while in kernel mode
>> cpuid = 1; apic id = 02
> ...
>> Uptime: 151d12h10m10s
>> ipfw: 11 Deny TCP 192.168.1.99:33822 208.47.254.32:80 in via ng471
>> Dumping 883 out of 8145 MB:ipfw: 13 Deny UDP 64.7.157.21:512
>> 192.168.254.46:137 in via ng21
>> panic: bufwrite: buffer is not busy???
>> cpuid = 1
>> Uptime: 151d12h10m10s
> 
> Hmm this one means we didn't stop all CPUs properly on panic;  I think that
> was fixed since?  At least it's the reason you didn't have a chance to get
> the core dump.

RELENG_8 (and others, perhaps) still needs additional patch
(by Andry Gapon) in case of USB keyboard to write crashdump properly.

I've sent its URL recently:
http://www.grosbein.net/freebsd/patches/stop_scheduler_on_panic.usb.diff

> 
> However of course the initial problem leading to the panic of course
> is its own issue still.


___
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"