ase let me know if there's any more information I can provide and/or
whether I should get this into a PR.
Thanks,
--
Chris Cowart
Lead Network Engineer
BitGravity, Inc.
A subsidiary of Tata Communications, Ltd.
pgp9b5iL9YlaI.pgp
Description: PGP signature
s looking like some kind
of bug related to IPSec. Maybe related to long messages? High volume of
messages?
We would love to get this hammered out, so please let me know if there's
any debugging we can perform or patches we can try.
Thanks,
--
Chris Cowart
Network Technical Lead
Network &
George Neville-Neil wrote:
> On Sep 4, 2009, at 18:31 , Chris Cowart wrote:
> > Starting about a week ago, our primary webserver (then running FreeBSD
> > 7.0) began crashing several times a day, typically during our
> > higher-load times of day. We have since u
e past couple
of days. I can't tell if the mbuf is being corrupted as it's passing
through the crypto system or if it's happening in ip_fragment. I'm in a
bit over my head in terms of trying to isolate and patch the bug. If
anyone has the time to squash it or at least give me som
VANHULLEBUS Yvan wrote:
> On Thu, Sep 10, 2009 at 12:37:39AM -0700, Chris Cowart wrote:
>> I have been using i386 and amd64 virtual machines as well as an amd64
>> physical machine; this problem can be reproduced fairly reliably on all
>> of them for 7.0 and 7.1 (and we'r
n for this. If this is a regression, it would be great if it
could get committed before the 8.0 release.
Thanks,
--
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
pgpV1lj9tfiRW.pgp
Description: PGP signature
the hope that this
makes it into the 8.0-RELEASE. Otherwise, the regression would seriously
complicate our upgrade path.
Thanks,
--
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
pgp1k6Fwz2JMf.pgp
Description: PGP signature
g the in-kernel implementation.
--
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
pgpdp9WWBGVze.pgp
Description: PGP signature
fconfig down/up did not help things. At the time, I
hadn't discovered the physical down/up workaround, so I can't speak to
whether that would have helped (and this error condition hasn't
recurred (knock on wood)). I don't know if the issues are related or
separate, but if yo
Pyun YongHyeon wrote:
> On Sun, Dec 06, 2009 at 06:17:46PM -0800, Chris Cowart wrote:
>> Having read the PR, I copied sys/dev/{msk,e1000} from HEAD into the
>
> I think the PR has nothing to do with this issue.
You're right. I found it when I was hunting for an explanation
Pyun YongHyeon wrote:
> On Mon, Dec 07, 2009 at 11:43:50AM -0800, Chris Cowart wrote:
>> Pyun YongHyeon wrote:
>>> On Sun, Dec 06, 2009 at 06:17:46PM -0800, Chris Cowart wrote:
>>>> On a related note, last night, when the system did boot, I would
>>>> a
he
implementation can highlight.
Here's my configuration from rc.conf:
ipv6_ifconfig_bridge0="2001:470:8337:10::1/64"
ipv6_ifconfig_bridge0_alias0="fe80::2%bridge0 prefixlen 64"
Once you're doing that, rtadvd will start doing the right thing.
--
Chris Cowart
http://www.timesinks.net/
pgpGzOj87z71m.pgp
Description: PGP signature
l assign link-local addresses to these interfaces? Should
this address be based on the ethernet address of the bridge interface?
I'm not sure I really understood the challenges with the implementation.
--
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
pgp7il6F6D7lF.pgp
Description: PGP signature
ny luck. Running GENERIC kernconf.
>
>>> Some info:
>>> net.inet.ip.forwarding: 1
>>> net.inet.ip.fastforwarding: 0 (enableing this does not help)
>>> net.inet.tcp.recvspace=1048576
>>> net.inet.tcp.sendspace=1048576
>>> kern.ipc.maxsockbuf=16777216
>&g
all from table() to any in recv
instead of tablearg?
If that's the case, it sounds like ipfw is parsing the rule incorrectly.
If tablearg isn't supported by setfib, I would expect a syntax error to
be thrown and not a different rule being inserted into your ruleset. If
this is the
For example:
| ccowart dev-aux etc $ cat /etc/start_if.vlan81
| ifconfig vlan81 vlan 81 vlandev em0
| ifconfig vlan81 inet 10.81.1.1/16
I don't know that two files per interface is any cleaner than a really
long /etc/rc.conf (I usually prefer the latter, but I generally am not
dealing
16 matches
Mail list logo