SCTP panic with sctp_send()

Hi, FreeBSD 7.3-RELEASE i386 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05955ca stack pointer = 0x28:0xe783bb94 frame pointer = 0x28:0xe783bc80 code

Re: SCTP panic with sctp_send()

Hi, Sat, Jun 26, 2010 at 17:11:13, tuexen wrote about Re: SCTP panic with sctp_send(): As seen from code, if uap-tolen is zero, `to' isn't initialized and remains NULL. This error is identical to -CURRENT. How can the crash be reproduced? Any code with sctp_send() under ktrace. Can

Re: SCTP panic with sctp_send()

Hi, Sat, Jun 26, 2010 at 21:30:12, tuexen wrote about Re: SCTP panic with sctp_send(): As seen from code, if uap-tolen is zero, `to' isn't initialized and remains NULL. This error is identical to -CURRENT. Thanks for reporting it. It is fixed in r209540 for current. Thanks! (for second

Re: kern/136803: [sctp] [panic] Kernel panic and hanging on using SCTP

The following reply was made to PR kern/136803; it has been noted by GNATS. From: Valentin Nechayev ne...@netch.kiev.ua To: Bruce Cran br...@cran.org.uk Cc: bug-follo...@freebsd.org Subject: Re: kern/136803: [sctp] [panic] Kernel panic and hanging on using SCTP Date: Sat, 8 Aug 2009 10:06

Re: kern/21998: [socket] [patch] ident only for outgoing connections

Fri, Nov 16, 2007 at 02:40:01, kmacy wrote about Re: kern/21998: [socket] [patch] ident only for outgoing connections: Need to confirm that this issue still applies. Yes, nothing is changed (at least for versions known to me) http://www.freebsd.org/cgi/query-pr.cgi?pr=21998 -netch-

Re: FreeBSD kernel pppd - mppe/mschapv1/2/radius support

Mon, Dec 06, 2004 at 18:21:05, josemi wrote about Re: FreeBSD kernel pppd - mppe/mschapv1/2/radius support: MPPE isn't possible due to lack of support in kernel for PPP terminal discipline. For others, you can use port (net/pppd23) as base. This is the most reasonable variant now (2.4

Re: freeaddrinfo(NULL)

Wed, Sep 22, 2004 at 05:07:13, jinmei wrote about Re: freeaddrinfo(NULL): I was not talking about things like whether NULL had been specially designed or not. I was basically talking about any invalid argument to freeaddrinfo. Well, garbage in pointer is unquestionably invalid, but whether

Re: freeaddrinfo(NULL)

Wed, Sep 22, 2004 at 03:58:05, jinmei wrote about Re: freeaddrinfo(NULL): As Umemoto-san said, if we made freeaddrinfo(NULL) safe, the application programmers might tend to rely on the safety net and the uncareful coding style. This can be worse than the segfault here, Let you try to apply

original interface name? (5.*)

Hi, is there a stable way to determine original interface name (before any renaming) in 5.3? I.e. as driver + sequence number? -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any

Re: original interface name? (5.*)

Fri, Sep 10, 2004 at 21:30:11, max wrote about Re: original interface name? (5.*): Hi, is there a stable way to determine original interface name (before any renaming) in 5.3? I.e. as driver + sequence number? From inside the kernel you can use ifnet.if_dname + ifnet.if_dunit, from the

Re: original interface name? (5.*)

Fri, Sep 10, 2004 at 12:58:26, brooks wrote about Re: original interface name? (5.*): Device number among with driver name are enough to determine needed information based on driver information and boot logs. It is pointless to use interface without such information, and it is pointless to

Re: race condition in ipfw restart (please review the fix)

Thu, Mar 25, 2004 at 01:59:34, fjoe (Max Khon) wrote about race condition in ipfw restart (please review the fix): MK ipfw restart has race condition: there is sleep 2 statement after MK killall natd but if natd will not die in 2 seconds ipfw can't MK start nat daemon (natd: Unable to bind

gre, ipsec, can't detunnel

Trying to set up ipsec'ed tunnel with explicit routing to it. Having 2 FreeBSD's (quarta - 4.9, grizzly - 5.2.1). [EMAIL PROTECTED]:~ # ifconfig gre0 gre0: flags=9051UP,POINTOPOINT,RUNNING,LINK0,MULTICAST mtu 1476 tunnel inet 193.193.193.138 -- 193.193.193.11 inet 10.0.0.2 --

ssh protocol 2 interactive delays

What is the difference between ssh protocol 1 and protocol 2 stream control? I tried protocol 1 in openssh and protocol 2 in openssh and Ylonen's SSH 2.3.0 via PSTN 56K line. With protocol 1 interactive delays are reasonable. With protocol 2, in both openssh and Ylonen's ssh, delays are