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 segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7751 (spc) trap number = 12 panic: page fault Uptime: 20d6h25m18s Physical memory: 1910 MB Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc053a730 in boot (howto=260) at /usr/BSD/src/sys/kern/kern_shutdown.c:418 #2 0xc053a931 in panic (fmt=Variable fmt is not available. ) at /usr/BSD/src/sys/kern/kern_shutdown.c:574 #3 0xc0762e4c in trap_fatal (frame=0xe783bb54, eva=0) at /usr/BSD/src/sys/i386/i386/trap.c:950 #4 0xc07630b0 in trap_pfault (frame=0xe783bb54, usermode=0, eva=0) at /usr/BSD/src/sys/i386/i386/trap.c:863 #5 0xc0763a92 in trap (frame=0xe783bb54) at /usr/BSD/src/sys/i386/i386/trap.c:541 #6 0xc074f81b in calltrap () at /usr/BSD/src/sys/i386/i386/exception.s:166 #7 0xc05955ca in sctp_generic_sendmsg (td=0xcafb7d80, uap=0xe783bcfc) at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 #8 0xc0763405 in syscall (frame=0xe783bd38) at /usr/BSD/src/sys/i386/i386/trap.c:1101 #9 0xc074f880 in Xint0x80_syscall () at /usr/BSD/src/sys/i386/i386/exception.s:262 #10 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 7 #7 0xc05955ca in sctp_generic_sendmsg (td=0xcafb7d80, uap=0xe783bcfc) at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 2386ktrsockaddr(to); (kgdb) p to $1 = (struct sockaddr *) 0x0 (kgdb) l 2381error = getsock(td-td_proc-p_fd, uap-sd, fp, NULL); 2382if (error) 2383goto sctp_bad; 2384#ifdef KTRACE 2385if (KTRPOINT(td, KTR_STRUCT)) 2386ktrsockaddr(to); 2387#endif 2388 2389iov[0].iov_base = uap-msg; 2390iov[0].iov_len = uap-mlen; As seen from code, if uap-tolen is zero, `to' isn't initialized and remains NULL. This error is identical to -CURRENT. Seems this zero originates from libc code for sctp_send(): === #ifdef SYS_sctp_generic_sendmsg struct sockaddr *to = NULL; return (syscall(SYS_sctp_generic_sendmsg, sd, data, len, to, 0, sinfo, flags)); #else === why after `to'? -netch- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
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 you provide a small test program? http://segfault.kiev.ua/~netch/20100626.2/ sps.c - server, spc.c - client run server in one terminal and client under ktrace in another one. why after `to'? shall be written as why 0 after `to'? -netch- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
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 fix too) -netch- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
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:06 +0300 Hi, Fri, Aug 07, 2009 at 23:41:13, bruce wrote about Re: kern/136803: [sctp] [panic] Kernel panic and hanging on using SCTP: It looks like revision 1.62.2.17 of /sys/netinet/sctp_pcb.c fixed this crash. Could you confirm whether the problem has been fixed? With this version, can't reproduce anymore. Thanks! -netch- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
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- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
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 aren't ported to *BSD, 2.3.11 is last 2.3) Not really, NetBSD pppd is 2.4 based. Thank for information; I were watching only for central distribution (on samba.org). If porting NetBSD's one, it can help in most listed features. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
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 NULL is invalid it's discussable (and flammable) question. Initing pointer to NULL is popular method and it's reasonable to keep it working without extra actions, as verifying !=NULL at freeing. As this discussion has no common with -net questions, I propose to move it to some another list. However, since the API specification is silent on this, I'd then request that the man page make an explicit note that the application programmer should be check if the argument to freeaddrinfo() is valid because passing a NULL pointer may cause an unexpected result, including segfaulting, on other systems. Agreed. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
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 the same arguments to free() and you'll see nonsense. If free(NULL) is freely allowed, what's the problem with freeaddrinfo()? because the reason for the NULL argument might be a bug in the program, and, as a result of hiding the bug by making NULL was specially designed by C authors as special value, no valid pointer here. One may wrap anything with if(p) freeaddrinfo(p);, but this has no deep sense and leads only to style flames. freeaddrinfo(NULL) safe, it might cause much more serious effects later in the program. What effects? Why they doesn't appear with another pointer? In my understanding, this kind of discussion has always been controversial; whether we want to make more explicit errors (even if those are segfaults), or whether we want to spoil bad programmers by making the library interface safe. Segfaulting on NULL makes nothing more safe. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
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 mail to [EMAIL PROTECTED]
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 userland I don't know if it's possible to get a look at those fields. In any way, I suggest not to do that. ifnet.if_xname is supposed to be *the* name of the interface. There is no such thing as original name. Having driver name one can determine essential capabilities of the interface, including VLAN support, possibility and allowed style of media specification, etc. 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 do manual logging as the only source. In any way, I suggest not to do that. What about good old principle Tools, not policy? -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
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 do manual logging as the only source. This is a better reason, but if you want the logs to make sense, you will have to be aware of changes. Hmm, we may want to log(9) renames. I'm considering adding an ifconfig -v option that would imply -m and add more details like index, epoch, dname, dunit, etc. Well, both ideas (logging renames and a switch to print more info) are highly pleasant. Thanks in advance for implementation. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
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 divert socket.: Address already in use). Is there any reason to wait until natd finishes polite restart? I usually kill it with -KILL, result is the same. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
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 -- 10.0.0.1 netmask 0x [EMAIL PROTECTED]:~ # ifconfig gre1 gre1: flags=9051UP,POINTOPOINT,RUNNING,LINK0,MULTICAST mtu 1476 tunnel inet 193.193.193.11 -- 193.193.193.138 inet 10.0.0.1 -- 10.0.0.2 netmask 0x Interaction 10.0.0.1 - 10.0.0.2 works ok. Adding IPSEC transport between external sides of tunnel: [EMAIL PROTECTED]:~ # less /etc/ipsec.conf flush; add 193.193.193.11 193.193.193.138 esp 1100 -m transport -E des-cbc 01239876 -A keyed-md5 dafa0066a4fc7788; add 193.193.193.138 193.193.193.11 esp 1101 -m transport -E des-cbc 01239876 -A keyed-md5 dafa0066a4fc7788; spdflush; spdadd 193.193.193.138/32 193.193.193.11/32 any -P out ipsec esp/transport//use; spdadd 193.193.193.11/32 193.193.193.138/32 any -P in ipsec esp/transport//use; [EMAIL PROTECTED]:~ # less /etc/ipsec.conf flush; add 193.193.193.11 193.193.193.138 esp 1100 -m transport -E des-cbc 01239876 -A keyed-md5 dafa0066a4fc7788; add 193.193.193.138 193.193.193.11 esp 1101 -m transport -E des-cbc 01239876 -A keyed-md5 dafa0066a4fc7788; spdflush; spdadd 193.193.193.11/32 193.193.193.138/32 any -P out ipsec esp/transport//use; spdadd 193.193.193.138/32 193.193.193.11/32 any -P in ipsec esp/transport//use; (IKE is disabled specially to simplify functioning.) Well, all interaction of external IPs is OK, with encryption and decryption. But interaction of internal IP's (e.g. `ping 10.0.0.2') fails. The same setup works in the following cases: - Encryption of packets going to GRE tunnel on FreeBSD and decryption on Cisco 7140 (well, with des-cbc, but disabling AH between FreeBSD's doesn't fix the problem): I see them after Cisco. - Encryption and decryption when tunnel is switched from GRE to IPIP (device gif). So, the only problem side is obtaining packets from GRE after IPSEC decryption: it fails on FreeBSD without any understandable reason. Questions here: 1. Did anybody seen the same problem? 2. Is it relative to my setup? If yes, why Cisco 7140 is able to decrypt and detunnel IPSEC+GRE? Admin for this Cisco router doesn't want to select IPIP encapsulation due to CEF problems, so I want to give maximal efforts to run it with GRE. P.S. Tunnel IPSEC mode also doesn't help, with the same result (Cisco can decrypt, FreeBSD can't). -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
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 unreasonable annoying. When going to localhost, all is OK. My impression is those delays are similar to ones in case when TCP_NODELAY was not turned on. Openssh client is standard from -current date=2001.05.12.00.00.00 (`SSH-1.99-OpenSSH_2.9 [EMAIL PROTECTED] 20010503'). All ssh servers are openssh from 4.3-RC or 4.3-RELEASE. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
