Hi!
bsnmpd running with mibII module opens local socket /var/run/snmpd.sock
mentioned in snmp_mibII(3) manual page:
The mibII module opens a socket that is used to execute all network
related ioctl(2) functions. This socket is globally available under the
name mib_netsock.
How do
Hi,
While porting a SCTP test tool, I figured out, that connect with
SOCK_SEQPACKET (SCTP 1-to-many style socket) is always returning 0,
regardless if the connection could be established or not.
The problem is that this result is responsible for client or server
mode of the tools.
If th
On 1/21/2011 4:21 AM, Jan Koum wrote:
>
>
> Dear Mike and Jack,
>
> sadly the problem is not gone for us either. here is what we know so far:
Same here. There was a new BIOS from Intel for our motherboard (INTEL
S3420GPX), but had another hang last night. Debug below. I will try the
newer dri
On Jan 23, 2011, at 4:18 PM, Schoch Christian wrote:
> Hi,
>
> While porting a SCTP test tool, I figured out, that connect with
> SOCK_SEQPACKET (SCTP 1-to-many style socket) is always returning 0,
> regardless if the connection could be established or not.
>
> The problem is that this result
Hi,
here is a version of the NAT-T/UDPENCAP patch as in 8 and 9 for
today's stable/7 for anyone who might want/need it. I would
expect it will equally apply to 7.4-RELEASE once that happened.
http://people.freebsd.org/~bz/20110123-01-stable7-natt.diff
You will need to figure out the
I've been trying to debug an issue where a call to getpeername
on a connected tcp socket returns ENOTCONN with no prior errors
being reported by previous socket calls.
At first I thought this was perl / perl module bug but I've now
reproduced the behaviour with a small native c client.
The flow
- Original Message -
From: "Steven Hartland"
...
Now given no previous errors from either connect, send or recv
if the connection has been terminated by the other end, which
tcpdump shows its has (RST), I would expect to get ECONNRESET
from getpeername and not ENOTCONN.
The only case I
Old Synopsis: High Collision count on "re" network interface
New Synopsis: [re] High Collision count on "re" network interface
Responsible-Changed-From-To: freebsd-amd64->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Jan 23 21:36:46 UTC 2011
Responsible-Changed-Why:
re
Old Synopsis: stuck kernel state in LISTEN on ipv6 daemon which has been killed
New Synopsis: [ip6] stuck kernel state in LISTEN on ipv6 daemon which has been
killed
Responsible-Changed-From-To: freebsd-amd64->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Jan 23 21:38:
The following reply was made to PR kern/154134; it has been noted by GNATS.
From: "Bjoern A. Zeeb"
To: bug-follo...@freebsd.org, g...@apnic.net
Cc:
Subject: Re: kern/154134: [ip6] stuck kernel state in LISTEN on ipv6 daemon
which has been killed
Date: Sun, 23 Jan 2011 22:03:33 + (UTC)
Hi
Synopsis: [re] High Collision count on "re" network interface
State-Changed-From-To: open->feedback
State-Changed-By: yongari
State-Changed-When: Sun Jan 23 22:54:37 UTC 2011
State-Changed-Why:
The counter comes from status report from hardware so I think the
counter is correct. Since you're usin
On Fri, Jan 7, 2011, Brandon Gooch wrote:
> It's likely that the mbuf handling problem (in em_refresh_mbufs()) is
> triggered by the processing you're doing with ipfw (or elsewhere for
> that matter), so, yes, I think it's a bug fixed in the revision
> discussed.
> When you update and test, pleas
The following reply was made to PR kern/152360; it has been noted by GNATS.
From: Pawel Tyll
To: bug-follo...@freebsd.org
Cc: Brandon Gooch
Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet.
Date: Mon, 24 Jan 2011 02:04:10 +0100
Machine fell after 14 days, 22:31:42 for the
The following reply was made to PR kern/154134; it has been noted by GNATS.
From: George Michaelson
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/154134: [ip6] stuck kernel state in LISTEN on ipv6 daemon
which has been killed
Date: Mon, 24 Jan 2011 12:44:07 +1000
On 24/01/2011, at 8:03
Synopsis: [stf] [panic] Panic when creating stf interface
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jan 24 05:04:52 UTC 2011
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=15421
Hi!
On 23.01.2011 16:13:48 +, Bjoern A. Zeeb wrote:
> here is a version of the NAT-T/UDPENCAP patch as in 8 and 9 for
> today's stable/7 for anyone who might want/need it. I would
> expect it will equally apply to 7.4-RELEASE once that happened.
>
> http://people.free
16 matches
Mail list logo
