Can someone please help dave out with the mini dump script stuff that's in 9?
That way he can get a crash dump and back trace, all happily wrapped
up in a text file?
That's likely going to help the relevant developers :-)
Adrian
___
freebsd-net@freebs
On Tue, Sep 27, 2011 at 9:24 AM, Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Sep 26, 2011 at 8:51 PM, dave jones wrote:
>> On Mon, Sep 26, 2011 at 1:41 PM, Arnaud Lacombe wrote:
>>> Hi,
>>>
>>> On Mon, Sep 26, 2011 at 1:12 AM, Arnaud Lacombe wrote:
Hi,
On Mon, Sep 26, 2011 at 12:43 AM,
Hi,
On Mon, Sep 26, 2011 at 8:51 PM, dave jones wrote:
> On Mon, Sep 26, 2011 at 1:41 PM, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Mon, Sep 26, 2011 at 1:12 AM, Arnaud Lacombe wrote:
>>> Hi,
>>>
>>> On Mon, Sep 26, 2011 at 12:43 AM, dave jones wrote:
Hi,
I have two production machines runn
Synopsis: [igb] igb(4) from HEAD fails to build on 7-STABLE
State-Changed-From-To: closed->open
State-Changed-By: eadler
State-Changed-When: Tue Sep 27 01:21:14 UTC 2011
State-Changed-Why:
woops, I meant -f not -c, sorry
http://www.freebsd.org/cgi/query-pr.cgi?pr=160873
_
Hi,
On Mon, Sep 26, 2011 at 7:22 PM, wrote:
> Synopsis: [igb] igb(4) from HEAD fails to build on 7-STABLE
>
> State-Changed-From-To: open->closed
> State-Changed-By: eadler
> State-Changed-When: Mon Sep 26 23:22:01 UTC 2011
> State-Changed-Why:
> fix has been committed ?
>
No.
Please re-open, a
On Mon, Sep 26, 2011 at 1:41 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Sep 26, 2011 at 1:12 AM, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Mon, Sep 26, 2011 at 12:43 AM, dave jones wrote:
>>> Hi,
>>> I have two production machines running on freebsd 9.0-beta2 and both got
>>> kernel panic related to n
Synopsis: [igb] igb(4) from HEAD fails to build on 7-STABLE
State-Changed-From-To: open->closed
State-Changed-By: eadler
State-Changed-When: Mon Sep 26 23:22:01 UTC 2011
State-Changed-Why:
fix has been committed ?
http://www.freebsd.org/cgi/query-pr.cgi?pr=160873
On Sep 26, 2011, at 4:23 PM, jyl_2006 wrote:
> OK ,In Ubuntu, I use getsockopt to get sctp_status with lksctp tarball, the
> result show me that only sender get the correct value about cwnd , the
> receive's cwnd keep the same value.
cwnd does not change when you don't send anything. Also, cwnd is
> root@tao[~]# ifconfig vr0 inet6 2a01:348:294::1 prefixlen 64 -alias
> root@tao[~]# ifconfig gif0 destroy
> root@tao[~]# ifconfig gif0
> ifconfig: interface gif0 does not exist
> Internet6:
> Destination Gateway Flags
> Netif Expire
> ::/96
On Thu, Sep 22, 2011 at 7:24 AM, Marek Salwerowicz wrote:
> W dniu 2011-08-10 16:22, Freddie Cash pisze:
>
>
>>The more correct method is to double-NAT the traffic, such
>>that the LAN
>>clients connect to public IPs, and the DMZ servers see
>>connections from
>>
Hi--
On Sep 26, 2011, at 9:53 AM, Martin Wilke wrote:
> Any other Idea what we can do to get a failover between both servers?
Multi datacenter failover is *hard*. You have to evaluate which parts are
static systems-- ie, display the same web images from all DCs, provide a
current UTC timestamp
Any other Idea what we can do to get a failover between both servers?
On Sep 26, 2011, at 2:07 PM, James Shupe wrote:
> z.z.z.z would have to be an anycast address announced by both
> datacenters, so your idea is unlikely to work.
>
> --
> James Shupe, OSRE
> founder/ developer/ engineer
> jsh
On 26 September 2011 17:05, Gary Palmer wrote:
>
> Not sure, however an experiment may be in order
>
> # ifconfig gif0
> ifconfig: interface gif0 does not exist
> # ifconfig gif0 create
> # ifconfig gif0 tunnel 1.2.3.4
> # ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128
> # netstat -nr -f inet
On Mon, Sep 26, 2011 at 04:04:00PM +0100, Matt Smith wrote:
> On 26 September 2011 15:21, Gary Palmer wrote:
> > Smells like a routing table problem or similar configuration problem.
> > On my tunnel endpoint, admitedly running 7.4 not 8.x or head, pings
> > to the LOCAL endpoint of the gif0 tunne
On 26 September 2011 15:21, Gary Palmer wrote:
> Smells like a routing table problem or similar configuration problem.
> On my tunnel endpoint, admitedly running 7.4 not 8.x or head, pings
> to the LOCAL endpoint of the gif0 tunnel go over lo0, not the external
> interface (gif0). I believe that
OK ,In Ubuntu, I use getsockopt to get sctp_status with lksctp tarball, the
result show me that only sender get the correct value about cwnd , the
receive's cwnd keep the same value.
Second time, I use Ubuntu as sender and use FreeBSD 9.0 as receiver, and I
does not set any system parameters by u
On Mon, Sep 26, 2011 at 02:49:15PM +0100, Matt Smith wrote:
> On 26 September 2011 14:29, Gary Palmer wrote:
> > On Mon, Sep 26, 2011 at 10:27:53AM +0100, Matt Smith wrote:
> > Do you have access to any other IPv6 hosts on a separate link? ?If so,
> > I would suggest trying a ping or traceroute ba
Sorry, didn't look at the images (limited bw), I've seen something
like this before in timewait. This "can't happen" with UDP so will be
interested in learning more about the bug.
On Mon, Sep 26, 2011 at 4:02 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Sep 26, 2011 at 5:12 AM, K. Macy wrote:
>>
Hi,
On Mon, Sep 26, 2011 at 5:12 AM, K. Macy wrote:
>
>
> On Monday, September 26, 2011, Adrian Chadd wrote:
>> On 26 September 2011 13:41, Arnaud Lacombe wrote:
>>> /*
>>> * XXX
>>> * This entire block sorely needs a rewrite.
>>> */
>>> if (t &&
>>> ((t->inp_flags & IN
I use one wireless card to communicate with another computer,which also has
one wireless card.
Both two computer does not set any system parameters by using command sysctl
.
I use a tarball to test and record. In this tarball,computer A use sendmsg()
to send a file, and computer B use recvmsg() to
On 26 September 2011 14:29, Gary Palmer wrote:
> On Mon, Sep 26, 2011 at 10:27:53AM +0100, Matt Smith wrote:
> Do you have access to any other IPv6 hosts on a separate link? If so,
> I would suggest trying a ping or traceroute back to your IP or
> IPs across the tunnel and see if the packets are
On Mon, Sep 26, 2011 at 10:27:53AM +0100, Matt Smith wrote:
> I have a very strange problem with a gif interface that has been
> confusing me all weekend. For the last six months I have had a gif
> tunnel setup to an ipv6 tunnel broker which has worked without any
> issues. On Friday I had a power
On 26 September 2011 12:46, Bjoern A. Zeeb
wrote:
> Given you are using NAT make sure that works as expected for the gif
> from the remote end. It might be worth, if you can, do tcpdump on
> the external interface of your router.
>
> Also make sure you can reach the IPv4 tunnel destination.
I a
On Sun, 2011-09-25 at 21:31 -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Sun, Sep 25, 2011 at 8:03 PM, Ben Hutchings
> wrote:
> > On Sat, 2011-09-24 at 13:56 -0700, Juli Mallett wrote:
> >> On Sat, Sep 24, 2011 at 13:52, Luigi Rizzo wrote:
> >> > apart from the typo ("know know") yes the email cont
On Sep 26, 2011, at 9:27 AM, Matt Smith wrote:
> root@tao[~]# ifconfig gif0
> gif0: flags=8051 metric 0 mtu 1280
>tunnel inet 192.168.1.2 --> 77.75.104.126
Given you are using NAT make sure that works as expected for the gif
from the remote end. It might be worth, if you can, do tcpdump
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
I have a very strange problem with a gif interface that has been
confusing me all weekend. For the last six months I have had a gif
tunnel setup to an ipv6 tunnel broker which has worked without any
issues. On Friday I had a power cut. The power returned, the server
restarted, and the tunnel has be
On Monday, September 26, 2011, Adrian Chadd wrote:
> On 26 September 2011 13:41, Arnaud Lacombe wrote:
>> /*
>> * XXX
>> * This entire block sorely needs a rewrite.
>> */
>>if (t &&
>>((t->inp_flags & INP_TIMEWAIT) == 0) &&
>>(so->so_type != SOCK_STREAM ||
>
28 matches
Mail list logo
