Current problem reports assigned to you

2007-01-01 Thread FreeBSD bugmaster
Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description a kern/38554 netchanging interface ipaddress doesn't seem to work s kern/39937 netipstealth

Re: kern/107358: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression)

2007-01-01 Thread Mark Linimon
Old Synopsis: IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 New Synopsis: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 1 13:28:53 UTC 2007 Responsible-Changed-W

Re: Diagnose co-location networking problem

2007-01-01 Thread .
> On Wed, Dec 27, 2006 at 10:08:25PM -0800, Stephan Wehner wrote: ... > Oh, also, going back to the 198.168 address seen in the client dumps, > it's clear that you're going through a NAT firewall or VPN or something > on the way to your server. Thus are you able to reproduce this problem > from a

wpi results

2007-01-01 Thread Rene Ladan
Hi, I build the wpi driver (version 20061109) on 7.0 CURRENT (20061229). It works fine, but it hangs my laptop after 'a while'. The only thing that keeps working is escaping to ddb. The laptop has the 4222 version of the wpi chipset. Loading it # kldload ./wpi_ucode.ko # kldload ./if_wpi.ko gi

Re: wpi results

2007-01-01 Thread Gavin Atkinson
On Mon, 1 Jan 2007, Rene Ladan wrote: I build the wpi driver (version 20061109) on 7.0 CURRENT (20061229). It works fine, but it hangs my laptop after 'a while'. The only thing that keeps working is escaping to ddb. The laptop has the 4222 version of the wpi chipset. I'm working on the driv

Re: Diagnose co-location networking problem

2007-01-01 Thread Stephan Wehner
Hello again, to give a short summary; I contacted this list to ask for help with diagnosing a problem with a co-located server (accessible at http://stbgo.org) running FreeBSD 6.1. When I swamp it with requests (simply, lynx -dump http://stbgo.org > /dev/null in a loop) some responses take 90 sec