Re: IPv6 not responding on some aliases (recent 8-stable)
On Fri, Dec 23, 2011 at 09:17:09AM +, Bjoern A. Zeeb wrote: > > On 22. Dec 2011, at 20:39 , Marcin Cieslak wrote: > > >>> Bjoern A. Zeeb wrote: > >>> I initially thought it's a transport layer issue, since previously (before > >>> I changed configuration) 30%-50% SSH connection attempts succeeded > >>> (but prefix was wrong on the "primary" IPv6 address :1000). > >>> Now I get no packets on receiving side at all for those "broken" IPv6 > >>> addresses. > >> > >> Talk to ywhomever is providing in front of you to > >> 1) either relax nd6 table limits or > >> 2) to route a /64 to your host to only have 1 entry in the neighbour table. > >> > >> That's most likely the problem given my crystal ball and experience. > > > > Thank you for insightful analysis! > > Seems like this provider has some significant IPv6 takeup, which is > > good news - sorry for hassle, but problems started after upgrade. > > > > I'll talk to my upstream then, thanks! > > Please let us know of the results, especially if my crystal ball was wrong. > I have seen this behavior before when one of the addresses on an interface is in a DMZ while the others are not. But this was with IPv4. I would assume IPv6 would have acted the same way but left it untested as it was not critical. Take this as informational only and double check your switches, firewalls, etc... -- ;s =; pgpnUtwZzzkKk.pgp Description: PGP signature
Re: Panic in the udp_input() under heavy load
On 11/24/2011 11:24 PM, Robert N. M. Watson wrote: There was recently a commit to fix a race condition in 10-CURRENT which >> I think is not slated to be merged for 9.0. You might check the commit >> logs there and see if that fixes the problems you have -- if so, we >> might want to reconsider the plan not to merge for 9.0. >> >> (It relates to a race condition on closing sockets..) > > Thank you for the tip. I will give it a try and see what happens. So far, after installing that trap we have not seen any panics yet. I have not checked logs yet if my trap actually has catch anything or not. Do we know if this fix has been merged to stable/9 and releng/9.0? Given multiple reports of instability without it, I think we would be well-served to merge it at this point. Hey Robert, sorry to bother you again, but can you at least point me towards specific SVN revisions that I need to get merged? I tried to google it and also browsed my svn history for the last 4 months using keyword "sockets", but nothing came up. This fix is critical for any system that does lot of fault-ctitical networking, and FreeBSD has always been 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"
Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node
Sami, On Tue, Dec 27, 2011 at 11:08:47PM +0200, Sami Halabi wrote: S> Thanks for your patch, i applied it and its production already. S> i had to stop mpd, and once started it i saw that all home routers S> connected immediatly. S> most of them don't use mppc, so I wonder why this problem happend in the S> first place. S> whats surprising i had few hours ago the same problem: S> Dec 27 14:11:29 mpd2 kernel: ng_mppc_decompress: too many (4092) packets S> dropped, disabling node 0xff000ba12700! S> Dec 27 14:11:29 mpd2 kernel: S> Dec 27 19:19:10 mpd2 kernel: ng_mppc_decompress: too many (4092) packets S> dropped, disabling node 0xff0006307400! S> Dec 27 19:19:10 mpd2 kernel: S> S> i hope the patch will solve the problem for good now, i'll let it work for S> the coming few days andif something will go wrong i'll paste you. How is the patched kernel running? Do you use L2TP or PPPoE? /me uses PPTP mostly, which handles any reordering problems correctly, so I can't even test my patch. If I produce a reordering event artifically, the ng_pptpgre filters bogus packet out. -- Totus tuus, Glebius. ___ 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: Panic in the udp_input() under heavy load
On 30 Dec 2011, at 19:48, Maxim Sobolev wrote: > On 11/24/2011 11:24 PM, Robert N. M. Watson wrote: There was recently a commit to fix a race condition in 10-CURRENT which >> I think is not slated to be merged for 9.0. You might check the commit >> logs there and see if that fixes the problems you have -- if so, we >> might want to reconsider the plan not to merge for 9.0. >> >> (It relates to a race condition on closing sockets..) >>> > >>> > Thank you for the tip. I will give it a try and see what happens. So >>> > far, after installing that trap we have not seen any panics yet. I have >>> > not checked logs yet if my trap actually has catch anything or not. >> Do we know if this fix has been merged to stable/9 and releng/9.0? Given >> multiple reports of instability without it, I think we would be well-served >> to merge it at this point. > > Hey Robert, sorry to bother you again, but can you at least point me towards > specific SVN revisions that I need to get merged? I tried to google it and > also browsed my svn history for the last 4 months using keyword "sockets", > but nothing came up. This fix is critical for any system that does lot of > fault-ctitical networking, and FreeBSD has always been solid in this regard. > It saved us at least 10-15 crashes across 5 machines in the last month. Hi Maxim: Looking back at a recent post from you, it appears that you are on 8.x and not 9.x, as I had assumed form your original e-mail. The patch I was referring to in 9-CURRENT has long since been merged for 9.0 and will appear in that release. However, it does not apply to 8.x, as the bug it fixed was introduced during the 9.x cycle. We'll need to do a from-scratch diagnosis here rather than assume it's the same problem. Could I ask you to follow up to this post with version information, stack traces from relevant threads, etc? I am not aware of any other reports of UDP-related crashes along the lines of what you've described in 8.x, so it may be being triggered by some unusual aspect of your workload (or just bad luck). Sorry that there's no instant "merge a patch" fix for this one. Thanks, Robert___ 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 not responding on some aliases (recent 8-stable)
> I have seen this behavior before when one of the addresses on an interface = > is in a DMZ while the others are not. But this was with IPv4. I would assum= > e IPv6 would have acted the same way but left it untested as it was not cri= > tical. Take this as informational only and double check your switches, fire= > walls, etc... Unfortunately, this is a hosting provider. I have rebooted the box to use their custom rescue netboot image (based on FreeBSD 8.0 running on QEMU) and ... still one of the addresses didn't work in this setup. However, two reboots later situation returned to normal, and all IPv6 addresses respond. NDP table theory sounds plausible to me, except... connection establishment to the IPv6 address port 22/tcp takes sometimes noticeably too long (other TCP ports are usually fine). But this is probably another story... //Marcin ___ 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: Panic in the udp_input() under heavy load
On 12/30/2011 3:31 PM, Robert N. M. Watson wrote: Looking back at a recent post from you, it appears that you are on 8.x and not 9.x, as I had assumed form your original e-mail. The patch I was referring to in 9-CURRENT has long since been merged for 9.0 and will appear in that release. However, it does not apply to 8.x, as the bug it fixed was introduced during the 9.x cycle. We'll need to do a from-scratch diagnosis here rather than assume it's the same problem. Could I ask you to follow up to this post with version information, stack traces from relevant threads, etc? I am not aware of any other reports of UDP-related crashes along the lines of what you've described in 8.x, so it may be being triggered by some unusual aspect of your workload (or just bad luck). Sorry that there's no instant "merge a patch" fix for this one. 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? As far as I can tell, the most harm it can do is some memory being leaked. And this condition happens just few times a day, so it's not 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 instead of plainly crashing. -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"
Re: Panic in the udp_input() under heavy load
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. And encourage people to report to it once they see this warning on their system. Then it would provide more information about the exposure. It is definitely looks like locking issue somewhere, not just bad luck or flaky hardware, as we see it happening consistently on top 4 most UDP-loaded systems here, and it correlates well with the load. With my small NULL catch the machines have been running happily for a month now, so there is no visible side-effects. -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"
RE: kern/161908: [netgraph] [patch] ng_vlan update for QinQ support
Who can commit? > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > n...@freebsd.org] On Behalf Of ead...@freebsd.org > Sent: Monday, October 24, 2011 7:35 AM > To: ead...@freebsd.org; freebsd-b...@freebsd.org; freebsd- > n...@freebsd.org > Subject: Re: kern/161908: [netgraph] [patch] ng_vlan update for QinQ > support > > Old Synopsis: ng_vlan update for QinQ support New Synopsis: [netgraph] > [patch] ng_vlan update for QinQ support > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: eadler > Responsible-Changed-When: Sun Oct 23 22:34:17 UTC 2011 > Responsible-Changed-Why: > assign and add tags > > http://www.freebsd.org/cgi/query-pr.cgi?pr=161908 > ___ > 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" ng_vlan.patch Description: Binary data ___ 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 not responding on some aliases (recent 8-stable)
On Sat, Dec 31, 2011 at 12:35:00AM +, Marcin Cieslak wrote: > > I have seen this behavior before when one of the addresses on an interface = > > is in a DMZ while the others are not. But this was with IPv4. I would assum= > > e IPv6 would have acted the same way but left it untested as it was not cri= > > tical. Take this as informational only and double check your switches, fire= > > walls, etc... > > Unfortunately, this is a hosting provider. I have rebooted the box > to use their custom rescue netboot image (based on FreeBSD 8.0 running > on QEMU) and ... still one of the addresses didn't work in this setup. > However, two reboots later situation returned to normal, and all > IPv6 addresses respond. NDP table theory sounds plausible to me, > except... connection establishment to the IPv6 address port 22/tcp > takes sometimes noticeably too long (other TCP ports are usually fine). > > But this is probably another story... > Speaking just in the terms of too long of a connection wait on port 22. Firewall off port 113 in and out. block drop in log quick proto tcp to any port = auth block out quick proto tcp to any port = auth That should help in terms of the speed at which you connect. Good luck with the OP though. Happy Holiday... -- ;s =; pgpco2n0N9ykB.pgp Description: PGP signature
Re: kern/161908: [netgraph] [patch] ng_vlan update for QinQ support
On 30 December 2011 21:48, wrote: > > Who can commit? > Bug me after January 3rd. :) Adrian ___ 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"
