Re: SSH hung with an OpenSSH_6.6.1p1 -- OpenSSH_5.8p2_hpn13v11

2015-03-26 Thread Mike Tancsa

On 3/26/2015 2:44 AM, Wu ShuKun wrote:


OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010
failed with Latest SSH:
% ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015


Hi,
The latest is 1.0.1m, no?

}# ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015

What version of FreeBSD are you using ?  Ssh and Openssl from the ports 
? or in the base ?


---Mike

--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


SSH hung with an OpenSSH_6.6.1p1 -- OpenSSH_5.8p2_hpn13v11

2015-03-26 Thread Wu ShuKun
   greeting!
   ssh connection failed by using a new version SSH to and old one.
Below is the symptoms which on a same network.
Connection is Okay with old version SSH
%ssh -V
OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010
%ssh -v 10.41.172.19
OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 10.41.172.19 [10.41.172.19] port 22.
debug1: Connection established.
debug1: identity file /home/wsk/.ssh/id_rsa type -1
debug1: identity file /home/wsk/.ssh/id_rsa-cert type -1
debug1: identity file /home/wsk/.ssh/id_dsa type -1
debug1: identity file /home/wsk/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503
debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.4p1 FreeBSD-20100308
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-client aes128-ctr hmac-md5 none
debug1: kex: client-server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host '10.41.172.19 (10.41.172.19)' can't be established.
RSA key fingerprint is ab:81:83:79:6a:d8:29:23:a0:51:1d:e6:f0:aa:ce:d6.
Are you sure you want to continue connecting (yes/no)?
---
failed with Latest SSH:
% ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015
% ssh -v 10.41.172.19
OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 10.41.172.19 [10.41.172.19] port 22.
debug1: Connection established.
debug1: identity file /home/wsk/.ssh/id_rsa type -1
debug1: identity file /home/wsk/.ssh/id_rsa-cert type -1
debug1: identity file /home/wsk/.ssh/id_dsa type -1
debug1: identity file /home/wsk/.ssh/id_dsa-cert type -1
debug1: identity file /home/wsk/.ssh/id_ecdsa type -1
debug1: identity file /home/wsk/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/wsk/.ssh/id_ed25519 type -1
debug1: identity file /home/wsk/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503
debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH_5*
compat 0x0c00
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-client aes128-ctr hmac-md5 none
debug1: kex: client-server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Connection closed by 10.41.172.19

any ideas?

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Early use of log() does not end up in kernel msg buffer

2015-03-26 Thread Eric Badger
Using log(9) when no process is reading the log results in the message 
going only to the console (contrast with printf(9), which goes to the 
console and to the kernel message buffer in this case). I believe it is 
truer to the semantics of logging for messages to *always* go to the 
message buffer (where they can eventually be collected and in fact put 
into a logfile). I therefore propose the attached patch, which sends 
log(9) to the message buffer always, and to the console only if no one 
has yet opened the log.


It may be more complete to log to the console only if the log level is 
greater than some (user defined) value, but this seems like that might 
be more than necessary for this case.


Thoughts?

Eric
diff --git share/man/man9/printf.9 share/man/man9/printf.9
index 84ac822..505ea9b 100644
--- share/man/man9/printf.9
+++ share/man/man9/printf.9
@@ -67,7 +67,8 @@ The
 .Fn log
 function sends the message to the kernel logging facility, using
 the log level as indicated by
-.Fa pri .
+.Fa pri ,
+and to the console if no process is yet reading the log.
 .Pp
 Each of these related functions use the
 .Fa fmt
diff --git sys/kern/subr_prf.c sys/kern/subr_prf.c
index 7e6fd09..6509522 100644
--- sys/kern/subr_prf.c
+++ sys/kern/subr_prf.c
@@ -295,7 +295,7 @@ log(int level, const char *fmt, ...)
 	va_list ap;
 
 	va_start(ap, fmt);
-	(void)_vprintf(level, log_open ? TOLOG : TOCONS, fmt, ap);
+	(void)_vprintf(level, log_open ? TOLOG : TOCONS | TOLOG, fmt, ap);
 	va_end(ap);
 
 	msgbuftrigger = 1;
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598

2015-03-26 Thread Mark Millard
Basic context:

# freebsd-version -ku; uname -apKU
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 
05:15:23 PDT 2015 root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG 
 powerpc powerpc64 1100062 1100062


The problem:

Summary of the details that are listed later. Both of the following exist:

/usr/src/sys/netinet/sctp.h
/usr/include/netinet/sctp.h

The first can be newer than the 2nd during buildworld.

The buildworld compile of /head/lib/libc/net/sctp_sys_calls.c from an updated 
/usr/src can/does end up using the second instead of the first, at least for 
the powerpc64-xtoolchain-gcc style of buildworld activity that I am trying.

The recent addition of SCTP_MAX_CWND ends up with its definition missing 
because of this: during the build /usr/include/netinet/sctp.h ends up being the 
file included and the compile fails from the missing additional definition.

Either the #include paths in /head/lib/libc/net/sctp_sys_calls.c or the command 
line arguments should force the /usr/src/sys/netinet/sctp.h vintage file to be 
found. The 3 netinet/ relevant includes are shown below...

 ...
 #include netinet/in.h
 #include arpa/inet.h
 #include netinet/sctp_uio.h
 #include netinet/sctp.h

More than sctp.h might have such issues since there are 3 netinet/ include 
paths in /head/lib/libc/net/sctp_sys_calls.c .

I have not checked for other .c files with similar issues for netinet/... 
usage during buildworld.


The problem details:

/head/lib/libc/net/sctp_sys_calls.c -r279859 added:

 case SCTP_MAX_CWND:
  ((struct sctp_assoc_value *)arg)-assoc_id = id;
  break;

and head (20150325 r280598) contains it.

But the SCTP_MAX_CWND reference blocks buildworld (for at least 
/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc (powerpc64-xtoolchain=gcc) 
use):

 /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC  -O2 -pipe   
 -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include 
 -I/usr/src/lib/libc/powerpc64 -DNLS  -D__DBINTERFACE_PRIVATE 
 -I/usr/src/lib/libc/../../contrib/gdtoa 
 -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 
 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE 
 -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd 
 -I/usr/src/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION 
 -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime  
 -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
 -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING 
 -DSYSCALL_COMPAT -std=gnu99 -fstack-protector -Wsystem-headers -Wall 
 -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign   -c 
 /usr/src/lib/libc/net/sctp_sys_calls.c -o sctp_sys_calls.So
 
 /usr/src/lib/libc/net/sctp_sys_calls.c: In function 'sctp_opt_info':
 /usr/src/lib/libc/net/sctp_sys_calls.c:386:7: error: 'SCTP_MAX_CWND' 
 undeclared (first use in this function)
   case SCTP_MAX_CWND:
   ^
Looking to see where usage and definitions might be in /usr/src for -r280598 ...

 # pwd
 /usr/src
 $ find . \( -type d -name .svn -prune \) -or \( -type f -exec grep 
 SCTP_MAX_CWND {} \; -print \) | more
 case SCTP_MAX_CWND:
 ./lib/libc/net/sctp_sys_calls.c
 case SCTP_MAX_CWND:
 case SCTP_MAX_CWND:
 ./sys/netinet/sctp_usrreq.c
 #define SCTP_MAX_CWND   0x0032
 ./sys/netinet/sctp.h

And looking at the list of includes in /head/lib/libc/net/sctp_sys_calls.c for 
-r279859 shows:

 #include sys/cdefs.h
 __FBSDID($FreeBSD$);
 
 #include stdio.h
 #include string.h
 #include errno.h
 #include stdlib.h
 #include unistd.h
 #include sys/types.h
 #include sys/socket.h
 #include sys/errno.h
 #include sys/syscall.h
 #include sys/uio.h
 #include netinet/in.h
 #include arpa/inet.h
 #include netinet/sctp_uio.h
 #include netinet/sctp.h

That there was no complaint about sctp.h being missing suggests that a 
netinet/sctp.h was found but did not contain a SCTP_MAX_CWND definition: so a 
different one than the above find/grep reported.

Using a find to report other sctp.h files shows:

 # find / \( -type d -name .svn -prune \) -or \( -type f -name sctp.h -print 
 \) | more
 /usr/src/sys/netinet/sctp.h
 /usr/include/netinet/sctp.h

The diff of those shows the problem if the wrong file is found and used:

 # diff /usr/include/netinet/sctp.h /usr/src/sys/netinet/sctp.h
 34c34
  __FBSDID($FreeBSD: head/sys/netinet/sctp.h 269945 2014-08-13 15:50:16Z 
 tuexen $);
 ---
  __FBSDID($FreeBSD: head/sys/netinet/sctp.h 279859 2015-03-10 19:49:25Z 
  tuexen $);
 130a131
  #define SCTP_MAX_CWND   0x0032




Context details:

 make -j 8 CROSS_TOOLCHAIN=powerpc64-gcc 
 WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_CLANG_IS_CC= \
 WITHOUT_LLDB= \
 WITH_GCC_BOOTSTRAP= WITH_GCC= WITHOUT_GNUCXX= \
 WITHOUT_BOOT= WITHOUT_LIB32= \
 buildworld buildkernel \
 KERNCONF=GENERIC64vtsc-NODEBUG
 TARGET=powerpc TARGET_ARCH=powerpc64

 # svnlite info /usr/src
 Path: .
 Working Copy Root Path: 

Re: Mbuf leak in if_lagg.c

2015-03-26 Thread Adrian Chadd
Hi!

Please file a bug! https://bugs.freebsd.org/submit/

Thanks!


-a


On 19 March 2015 at 09:31, Alexandre Martins
alexandre.mart...@stormshield.eu wrote:
 Hi !

 I found a leak of mbuf in the lagg driver :

 https://svnweb.freebsd.org/base/head/sys/net/if_lagg.c?view=annotate#l1672

 -=-=-=-=-=-=-=-=-=-=-
 m = (lp-lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL;
 -=-=-=-=-=-=-=-=-=-=-

 If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it.

 Can you look at this ?

 Regards

 --
 Alexandre Martins
 STORMSHIELD

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Mbuf leak in if_lagg.c

2015-03-26 Thread Andrey V. Elsukov
On 19.03.2015 19:31, Alexandre Martins wrote:
 Hi !
 
 I found a leak of mbuf in the lagg driver :
 
 https://svnweb.freebsd.org/base/head/sys/net/if_lagg.c?view=annotate#l1672
 
 -=-=-=-=-=-=-=-=-=-=-
 m = (lp-lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL;
 -=-=-=-=-=-=-=-=-=-=-
 
 If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it.
 
 Can you look at this ?

Hi,

what you thing about this patch?
lp_detaching can be non zero in case of parent interface departure.
So I don't see the reason to call ETHER_BPF_MTAP() in this case.

-- 
WBR, Andrey V. Elsukov
Index: if_lagg.c
===
--- if_lagg.c	(revision 280234)
+++ if_lagg.c	(working copy)
@@ -1661,7 +1661,8 @@ lagg_input(struct ifnet *ifp, struct mbuf *m)
 	LAGG_RLOCK(sc, tracker);
 	if ((scifp-if_drv_flags  IFF_DRV_RUNNING) == 0 ||
 	(lp-lp_flags  LAGG_PORT_DISABLED) ||
-	sc-sc_proto == LAGG_PROTO_NONE) {
+	sc-sc_proto == LAGG_PROTO_NONE ||
+	lp-lp_detaching != 0) {
 		LAGG_RUNLOCK(sc, tracker);
 		m_freem(m);
 		return (NULL);
@@ -1668,9 +1669,7 @@ lagg_input(struct ifnet *ifp, struct mbuf *m)
 	}
 
 	ETHER_BPF_MTAP(scifp, m);
-
-	m = (lp-lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL;
-
+	m = lagg_proto_input(sc, lp, m);
 	if (m != NULL) {
 		if (scifp-if_flags  IFF_MONITOR) {
 			m_freem(m);


signature.asc
Description: OpenPGP digital signature


Re: SSH hung with an OpenSSH_6.6.1p1 -- OpenSSH_5.8p2_hpn13v11

2015-03-26 Thread 吴叔坤
all set are in base. and I’m using 10.1-RELEASE-p8 BTW
 在 2015年3月26日,下午6:12,Mike Tancsa m...@sentex.net 写道:
 
 On 3/26/2015 2:44 AM, Wu ShuKun wrote:
 
 OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010
 failed with Latest SSH:
 % ssh -V
 OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015
 
 Hi,
   The latest is 1.0.1m, no?
 
 }# ssh -V
 OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015
 
 What version of FreeBSD are you using ?  Ssh and Openssl from the ports ? or 
 in the base ?
 
   ---Mike
 
 -- 
 ---
 Mike Tancsa, tel +1 519 651 3400
 Sentex Communications, m...@sentex.net
 Providing Internet services since 1994 www.sentex.net
 Cambridge, Ontario Canada   http://www.tancsa.com/

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Mbuf leak in if_lagg.c

2015-03-26 Thread Andrey V. Elsukov
On 26.03.2015 22:42, Andrey V. Elsukov wrote:
 If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it.

 Can you look at this ?
 
 Hi,
 
 what you thing about this patch?
 lp_detaching can be non zero in case of parent interface departure.
 So I don't see the reason to call ETHER_BPF_MTAP() in this case.

Now I see the reason - to capture all received packets before interface
departure. New is attached.

-- 
WBR, Andrey V. Elsukov
Index: if_lagg.c
===
--- if_lagg.c	(revision 280234)
+++ if_lagg.c	(working copy)
@@ -1669,7 +1669,11 @@ lagg_input(struct ifnet *ifp, struct mbuf *m)
 
 	ETHER_BPF_MTAP(scifp, m);
 
-	m = (lp-lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL;
+	if (lp-lp_detaching != 0) {
+		m_freem(m);
+		m = NULL;
+	} else
+		m = lagg_proto_input(sc, lp, m);
 
 	if (m != NULL) {
 		if (scifp-if_flags  IFF_MONITOR) {


signature.asc
Description: OpenPGP digital signature


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-26 Thread Hans Petter Selasky

On 03/26/15 22:37, Adrian Chadd wrote:

Is there a PR filed with this?




There is now:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198936

--HPS

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-26 Thread Adrian Chadd
Is there a PR filed with this?


-a


On 26 March 2015 at 14:00, Jakob Alvermark ja...@alvermark.net wrote:
 On Tue, March 24, 2015 00:29, Hans Petter Selasky wrote:
 Hi,


 Without the attached kernel patch(es), Xorg starts consuming alot of CPU
 and becomes very unresponsive and unusable.

 Using ktrace reveals that X-org is issuing DRM_IOCTL_MODE_GETCONNECTOR
 over and over again with no apparent reason. It doesn't happen when using a
 simple window manager like blackbox. I was not able to use XFCE4 (9-stable
 userland) with 11-current kernel at all, after the latest DRM2 kernel
 updates. It worked fine before the update.

 I'm not sure what is causing it. Going through the new DRM2 code
 revealed that a mode sorting function did not take all parameters like
 interlaced or not into account, causing the mode list to be reshuffelled
 every time a new mode scan was done. Not sure if Xorg cares about this
 though.

 I got the same problem with XFCE4, Xorg at 100% CPU.

 Applied the patch and it works again.

 Jakob


 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-26 Thread Jakob Alvermark
On Tue, March 24, 2015 00:29, Hans Petter Selasky wrote:
 Hi,


 Without the attached kernel patch(es), Xorg starts consuming alot of CPU
 and becomes very unresponsive and unusable.

 Using ktrace reveals that X-org is issuing DRM_IOCTL_MODE_GETCONNECTOR
 over and over again with no apparent reason. It doesn't happen when using a
 simple window manager like blackbox. I was not able to use XFCE4 (9-stable
 userland) with 11-current kernel at all, after the latest DRM2 kernel
 updates. It worked fine before the update.

 I'm not sure what is causing it. Going through the new DRM2 code
 revealed that a mode sorting function did not take all parameters like
 interlaced or not into account, causing the mode list to be reshuffelled
 every time a new mode scan was done. Not sure if Xorg cares about this
 though.

I got the same problem with XFCE4, Xorg at 100% CPU.

Applied the patch and it works again.

Jakob


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

2015-03-26 Thread Hans Petter Selasky

On 03/26/15 22:37, Adrian Chadd wrote:

Is there a PR filed with this?



No, do you want me to make one?

--HPS

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Suspend sometimes hangs the whole system

2015-03-26 Thread Jochen Fahrner
Hello,

Normally suspend/resume is working fine on my Lenovo Thinkpad T61. But
sometimes, when I press the power button to suspend, the whole system
hangs and does not suspend. In X11 the mouse cursor goes away and no
mouse action is possible. The graphics screen is staying there and it
does not switch to console as on a normal suspend. Also manually
switching to a console screen is not possible. Even the ssh daemon does
not respond when I try to login thhroug ssh from some other pc. Looks
like sshd is already sleeping. The only way to get it back to life is a
hard reset.

How can I investigate this problem further?

-- 
Mit besten Grüßen
Jochen Fahrner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Mbuf leak in if_lagg.c

2015-03-26 Thread Alexandre Martins
Hi !

I found a leak of mbuf in the lagg driver :

https://svnweb.freebsd.org/base/head/sys/net/if_lagg.c?view=annotate#l1672

-=-=-=-=-=-=-=-=-=-=-
m = (lp-lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL;
-=-=-=-=-=-=-=-=-=-=-

If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it.

Can you look at this ?

Regards

-- 
Alexandre Martins
STORMSHIELD



smime.p7s
Description: S/MIME cryptographic signature