Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail)

2014-01-01 Thread Nikolay Denev 
On Sun, Dec 22, 2013 at 1:10 PM,  wrote:

> Thank you very much for your problem report.
> It has the internal identification `misc/185092'.
> The individual assigned to look at your
> report is: freebsd-bugs.
>
> You can access the state of your problem report at any time
> via this link:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=185092
>
> >Category:   misc
> >Responsible:freebsd-bugs
> >Synopsis:   panic: rtfree 2 (using RADIX_MPATH in a VNET jail)
> >Arrival-Date:   Sun Dec 22 13:10:00 UTC 2013
>

I'm trying to understand exactly what is happening here, and examining a
core dump with kgdb I'm getting some output that confuses me :

(kgdb) bt
#0  doadump (textdump=-1011569920) at pcpu.h:233
#1  0xc06069b2 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:447
#2  0xc0606d0e in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:754
#3  0xc06de639 in rtfree (rt=) at
/usr/src/sys/net/route.c:464
#4  0xc06e188d in route_output (m=) at
/usr/src/sys/net/rtsock.c:951
#5  0xc06de18f in raw_usend (so=, flags=0, m=, nam=0x0, control=,
td=0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
#6  0xc066eca9 in sosend_generic (so=0xc3e9c1a8, uio=,
top=, control=0x0,
flags=, td=) at
/usr/src/sys/kern/uipc_socket.c:1271
#7  0xc066efc7 in sosend (so=0xc3e9c1a8, addr=0x0, uio=0xd9b9cc10, top=0x0,
control=0x0, flags=0, td=0xc3bd2000)
at /usr/src/sys/kern/uipc_socket.c:1315
#8  0xc0654af4 in soo_write (fp=0xc3c0c818, uio=0xd9b9cc10,
active_cred=0xc3f1dd00, flags=0, td=0xc3bd2000)
at /usr/src/sys/kern/sys_socket.c:103
#9  0xc064c866 in dofilewrite (td=0xc3bd2000, fd=3, fp=0xc3c0c818,
auio=0xd9b9cc10, offset=-1, flags=0) at file.h:303
#10 0xc064c566 in kern_writev (td=0xc3bd2000, fd=3, auio=) at /usr/src/sys/kern/sys_generic.c:467
#11 0xc064c4bc in sys_write (td=, uap=) at /usr/src/sys/kern/sys_generic.c:382
#12 0xc08614d3 in syscall (frame=) at
subr_syscall.c:134
#13 0xc084cca1 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:270
#14 0x281975b7 in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb) fr 3
#3  0xc06de639 in rtfree (rt=) at
/usr/src/sys/net/route.c:464
464 panic("rtfree 2");
(kgdb) print *rt
$1 = {rt_nodes = {{rn_mklist = 0xc3b4ab30, rn_parent = 0x1, rn_bit = 0,
rn_bmask = 0 '\0', rn_flags = 0 '\0', rn_u = {rn_leaf = {
  rn_Key = 0xc0882687 "shutdown_post_sync", rn_Mask = 0x103
, rn_Dupedkey = 0x0}, rn_node = {
  rn_Off = -1064819065, rn_L = 0x103, rn_R = 0x0}}}, {rn_mklist
= 0x0, rn_parent = 0x4, rn_bit = -18048, rn_bmask = -94 '?',
  rn_flags = 195 '?', rn_u = {rn_leaf = {rn_Key = 0xc3a545e0 "",
rn_Mask = 0xc3a4e440 " ??(???\020'", rn_Dupedkey = 0xc3a4e880},
rn_node = {rn_Off = -1012578848, rn_L = 0xc3a4e440, rn_R =
0xc3a4e880, rt_gateway = 0x74756873, rt_flags = 1853321060,
  rt_refcnt = 1936683103, rt_ifp = 0x79735f74, rt_ifa = 0x636e, rt_rmx =
{rmx_mtu = 0, rmx_expire = 0, rmx_pksent = 0, rmx_weight = 0},
  rt_fibnum = 0, rt_mtx = {lock_object = {lo_name = 0x0, lo_flags = 0,
lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}}



rn_Key with value of “shutdown_post_sync” ?

It’s visible also in the raw_usend() frame:

(kgdb) fr 5
#5  0xc06de18f in raw_usend (so=, flags=0, m=, nam=0x0, control=,
td=0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
238 return ((*so->so_proto->pr_output)(m, so));
(kgdb) print *m
$2 = {m_hdr = {mh_next = 0xc3b4ab30, mh_nextpkt = 0x1, mh_data = 0x0,
mh_len = -1064819065, mh_type = 0, mh_flags = 66304, mh_pad = 0},
  M_dat = {MH = {MH_pkthdr = {rcvif = 0x0, tags = {slh_first = 0x4}, len =
-1012745856, flowid = 3282388448,
csum_flags = 14097648373312316480, fibnum = 26739, cosqos = 117
'u', rsstype = 116 't', l2hlen = 100 'd', l3hlen = 111 'o',
l4hlen = 119 'w', l5hlen = 110 'n', PH_per = {eigth = "_post_sy",
sixteen = {28767, 29551, 24436, 31091}, thirtytwo = {1936683103,
2037604212}, sixtyfour = {8751443454668533855}, unintptr =
{1936683103}, ptr = 0x736f705f}, PH_loc = {
  eigth = "nc\000\000\000\000\000", sixteen = {25454, 0, 0, 0},
thirtytwo = {25454, 0}, sixtyfour = {25454}, unintptr = {25454},
  ptr = 0x636e}}, MH_dat = {MH_ext = {ref_cnt = 0x0, ext_buf = 0x0,
ext_size = 0, ext_type = 0, ext_flags = 0, ext_free = 0,
  ext_arg1 = 0x0, ext_arg2 = 0x0},
MH_databuf = '\0' , "file", '\0' ,
"\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\000\000\000\000\004\000\000\000\000\000\000\0Y?",
'\0' ,
"`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203??\000\000\000\000\000???",
'\0' }},
M_databuf =
"\000\000\000\000\004\000\000\000\200E??@??\200??shutdown_post_sync",
'\0' , "file", '\0' ,
"\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\000\000\000\000\004\000\000\000\000\000\000\0Y?",
'\0' ,
"`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203??\000\000\000\000\000???",
'\0' }}


This i

Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail)

2014-01-01 Thread Nikolay Denev 
The following reply was made to PR misc/185092; it has been noted by GNATS.

From: Nikolay Denev 
To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org, 
"freebsd-...@freebsd.org" 
Cc:  
Subject: Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail)
Date: Wed, 1 Jan 2014 13:10:57 +

 --001a11c3d860640c3f04eee868e9
 Content-Type: text/plain; charset=windows-1252
 Content-Transfer-Encoding: quoted-printable
 
 On Sun, Dec 22, 2013 at 1:10 PM,  wrote:
 
 > Thank you very much for your problem report.
 > It has the internal identification `misc/185092'.
 > The individual assigned to look at your
 > report is: freebsd-bugs.
 >
 > You can access the state of your problem report at any time
 > via this link:
 >
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D185092
 >
 > >Category:   misc
 > >Responsible:freebsd-bugs
 > >Synopsis:   panic: rtfree 2 (using RADIX_MPATH in a VNET jail)
 > >Arrival-Date:   Sun Dec 22 13:10:00 UTC 2013
 >
 
 I'm trying to understand exactly what is happening here, and examining a
 core dump with kgdb I'm getting some output that confuses me :
 
 (kgdb) bt
 #0  doadump (textdump=3D-1011569920) at pcpu.h:233
 #1  0xc06069b2 in kern_reboot (howto=3D260) at
 /usr/src/sys/kern/kern_shutdown.c:447
 #2  0xc0606d0e in panic (fmt=3D) at
 /usr/src/sys/kern/kern_shutdown.c:754
 #3  0xc06de639 in rtfree (rt=3D) at
 /usr/src/sys/net/route.c:464
 #4  0xc06e188d in route_output (m=3D) at
 /usr/src/sys/net/rtsock.c:951
 #5  0xc06de18f in raw_usend (so=3D, flags=3D0, m=3D, nam=3D0x0, control=3D,
 td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
 #6  0xc066eca9 in sosend_generic (so=3D0xc3e9c1a8, uio=3D,
 top=3D, control=3D0x0,
 flags=3D, td=3D) at
 /usr/src/sys/kern/uipc_socket.c:1271
 #7  0xc066efc7 in sosend (so=3D0xc3e9c1a8, addr=3D0x0, uio=3D0xd9b9cc10, to=
 p=3D0x0,
 control=3D0x0, flags=3D0, td=3D0xc3bd2000)
 at /usr/src/sys/kern/uipc_socket.c:1315
 #8  0xc0654af4 in soo_write (fp=3D0xc3c0c818, uio=3D0xd9b9cc10,
 active_cred=3D0xc3f1dd00, flags=3D0, td=3D0xc3bd2000)
 at /usr/src/sys/kern/sys_socket.c:103
 #9  0xc064c866 in dofilewrite (td=3D0xc3bd2000, fd=3D3, fp=3D0xc3c0c818,
 auio=3D0xd9b9cc10, offset=3D-1, flags=3D0) at file.h:303
 #10 0xc064c566 in kern_writev (td=3D0xc3bd2000, fd=3D3, auio=3D) at /usr/src/sys/kern/sys_generic.c:467
 #11 0xc064c4bc in sys_write (td=3D, uap=3D) at /usr/src/sys/kern/sys_generic.c:382
 #12 0xc08614d3 in syscall (frame=3D) at
 subr_syscall.c:134
 #13 0xc084cca1 in Xint0x80_syscall () at
 /usr/src/sys/i386/i386/exception.s:270
 #14 0x281975b7 in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 Current language:  auto; currently minimal
 (kgdb) fr 3
 #3  0xc06de639 in rtfree (rt=3D) at
 /usr/src/sys/net/route.c:464
 464 panic("rtfree 2");
 (kgdb) print *rt
 $1 =3D {rt_nodes =3D {{rn_mklist =3D 0xc3b4ab30, rn_parent =3D 0x1, rn_bit =
 =3D 0,
 rn_bmask =3D 0 '\0', rn_flags =3D 0 '\0', rn_u =3D {rn_leaf =3D {
   rn_Key =3D 0xc0882687 "shutdown_post_sync", rn_Mask =3D 0x103
 , rn_Dupedkey =3D 0x0}, rn_node =3D {
   rn_Off =3D -1064819065, rn_L =3D 0x103, rn_R =3D 0x0}}}, {rn_=
 mklist
 =3D 0x0, rn_parent =3D 0x4, rn_bit =3D -18048, rn_bmask =3D -94 '?',
   rn_flags =3D 195 '?', rn_u =3D {rn_leaf =3D {rn_Key =3D 0xc3a545e0 ""=
 ,
 rn_Mask =3D 0xc3a4e440 " ??(???\020'", rn_Dupedkey =3D 0xc3a4e880},
 rn_node =3D {rn_Off =3D -1012578848, rn_L =3D 0xc3a4e440, rn_R =3D
 0xc3a4e880, rt_gateway =3D 0x74756873, rt_flags =3D 1853321060,
   rt_refcnt =3D 1936683103, rt_ifp =3D 0x79735f74, rt_ifa =3D 0x636e, rt_rm=
 x =3D
 {rmx_mtu =3D 0, rmx_expire =3D 0, rmx_pksent =3D 0, rmx_weight =3D 0},
   rt_fibnum =3D 0, rt_mtx =3D {lock_object =3D {lo_name =3D 0x0, lo_flags =
 =3D 0,
 lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 0}}
 
 
 
 rn_Key with value of =93shutdown_post_sync=94 ?
 
 It=92s visible also in the raw_usend() frame:
 
 (kgdb) fr 5
 #5  0xc06de18f in raw_usend (so=3D, flags=3D0, m=3D, nam=3D0x0, control=3D,
 td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
 238 return ((*so->so_proto->pr_output)(m, so));
 (kgdb) print *m
 $2 =3D {m_hdr =3D {mh_next =3D 0xc3b4ab30, mh_nextpkt =3D 0x1, mh_data =3D =
 0x0,
 mh_len =3D -1064819065, mh_type =3D 0, mh_flags =3D 66304, mh_pad =3D 0},
   M_dat =3D {MH =3D {MH_pkthdr =3D {rcvif =3D 0x0, tags =3D {slh_first =3D =
 0x4}, len =3D
 -1012745856, flowid =3D 3282388448,
 csum_flags =3D 14097648373312316480, fibnum =3D 26739, cosqos =3D 1=
 17
 'u', rsstype =3D 116 't', l2hlen =3D 100 'd', l3hlen =3D 111 'o',
 l4hlen =3D 119 'w', l5hlen =3D 110 'n', PH_per =3D {eigth =3D "_pos=
 t_sy",
 sixteen =3D {28767, 29551, 24436, 31091}, thirtytwo =3D {1936683103,
 2037604212}, sixtyfour =3D {8751443454668533855}, unintptr =3D
 {1936683103}, ptr =3D 0x736f705f}, PH_loc =3D {
   eigth =3D "nc\000\000\000\000\000", sixteen =3D {25454, 0, 0, 0},
 thirtytwo =3D {25454, 0}, sixtyfour =3

Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail)

2014-01-01 Thread Nikolay Denev 
On Wed, Jan 1, 2014 at 1:10 PM, Nikolay Denev  wrote:

> On Sun, Dec 22, 2013 at 1:10 PM,  wrote:
>
>> Thank you very much for your problem report.
>> It has the internal identification `misc/185092'.
>> The individual assigned to look at your
>> report is: freebsd-bugs.
>>
>> You can access the state of your problem report at any time
>> via this link:
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=185092
>>
>> >Category:   misc
>> >Responsible:freebsd-bugs
>> >Synopsis:   panic: rtfree 2 (using RADIX_MPATH in a VNET jail)
>> >Arrival-Date:   Sun Dec 22 13:10:00 UTC 2013
>>
>
> I'm trying to understand exactly what is happening here, and examining a
> core dump with kgdb I'm getting some output that confuses me :
>
> (kgdb) bt
> #0  doadump (textdump=-1011569920) at pcpu.h:233
> #1  0xc06069b2 in kern_reboot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:447
> #2  0xc0606d0e in panic (fmt=) at
> /usr/src/sys/kern/kern_shutdown.c:754
> #3  0xc06de639 in rtfree (rt=) at
> /usr/src/sys/net/route.c:464
> #4  0xc06e188d in route_output (m=) at
> /usr/src/sys/net/rtsock.c:951
> #5  0xc06de18f in raw_usend (so=, flags=0, m= optimized out>, nam=0x0, control=,
> td=0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
> #6  0xc066eca9 in sosend_generic (so=0xc3e9c1a8, uio= out>, top=, control=0x0,
> flags=, td=) at
> /usr/src/sys/kern/uipc_socket.c:1271
> #7  0xc066efc7 in sosend (so=0xc3e9c1a8, addr=0x0, uio=0xd9b9cc10,
> top=0x0, control=0x0, flags=0, td=0xc3bd2000)
> at /usr/src/sys/kern/uipc_socket.c:1315
> #8  0xc0654af4 in soo_write (fp=0xc3c0c818, uio=0xd9b9cc10,
> active_cred=0xc3f1dd00, flags=0, td=0xc3bd2000)
> at /usr/src/sys/kern/sys_socket.c:103
> #9  0xc064c866 in dofilewrite (td=0xc3bd2000, fd=3, fp=0xc3c0c818,
> auio=0xd9b9cc10, offset=-1, flags=0) at file.h:303
> #10 0xc064c566 in kern_writev (td=0xc3bd2000, fd=3, auio= out>) at /usr/src/sys/kern/sys_generic.c:467
> #11 0xc064c4bc in sys_write (td=, uap= optimized out>) at /usr/src/sys/kern/sys_generic.c:382
> #12 0xc08614d3 in syscall (frame=) at
> subr_syscall.c:134
> #13 0xc084cca1 in Xint0x80_syscall () at
> /usr/src/sys/i386/i386/exception.s:270
> #14 0x281975b7 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> Current language:  auto; currently minimal
> (kgdb) fr 3
> #3  0xc06de639 in rtfree (rt=) at
> /usr/src/sys/net/route.c:464
> 464 panic("rtfree 2");
> (kgdb) print *rt
> $1 = {rt_nodes = {{rn_mklist = 0xc3b4ab30, rn_parent = 0x1, rn_bit = 0,
> rn_bmask = 0 '\0', rn_flags = 0 '\0', rn_u = {rn_leaf = {
>   rn_Key = 0xc0882687 "shutdown_post_sync", rn_Mask = 0x103
> , rn_Dupedkey = 0x0}, rn_node = {
>   rn_Off = -1064819065, rn_L = 0x103, rn_R = 0x0}}},
> {rn_mklist = 0x0, rn_parent = 0x4, rn_bit = -18048, rn_bmask = -94 '?',
>   rn_flags = 195 '?', rn_u = {rn_leaf = {rn_Key = 0xc3a545e0 "",
> rn_Mask = 0xc3a4e440 " ??(???\020'", rn_Dupedkey = 0xc3a4e880},
> rn_node = {rn_Off = -1012578848, rn_L = 0xc3a4e440, rn_R =
> 0xc3a4e880, rt_gateway = 0x74756873, rt_flags = 1853321060,
>   rt_refcnt = 1936683103, rt_ifp = 0x79735f74, rt_ifa = 0x636e, rt_rmx =
> {rmx_mtu = 0, rmx_expire = 0, rmx_pksent = 0, rmx_weight = 0},
>   rt_fibnum = 0, rt_mtx = {lock_object = {lo_name = 0x0, lo_flags = 0,
> lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}}
>
>
>
> rn_Key with value of “shutdown_post_sync” ?
>
> It’s visible also in the raw_usend() frame:
>
> (kgdb) fr 5
> #5  0xc06de18f in raw_usend (so=, flags=0, m= optimized out>, nam=0x0, control=,
> td=0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
> 238 return ((*so->so_proto->pr_output)(m, so));
> (kgdb) print *m
> $2 = {m_hdr = {mh_next = 0xc3b4ab30, mh_nextpkt = 0x1, mh_data = 0x0,
> mh_len = -1064819065, mh_type = 0, mh_flags = 66304, mh_pad = 0},
>   M_dat = {MH = {MH_pkthdr = {rcvif = 0x0, tags = {slh_first = 0x4}, len =
> -1012745856, flowid = 3282388448,
> csum_flags = 14097648373312316480, fibnum = 26739, cosqos = 117
> 'u', rsstype = 116 't', l2hlen = 100 'd', l3hlen = 111 'o',
> l4hlen = 119 'w', l5hlen = 110 'n', PH_per = {eigth = "_post_sy",
> sixteen = {28767, 29551, 24436, 31091}, thirtytwo = {1936683103,
> 2037604212}, sixtyfour = {8751443454668533855}, unintptr =
> {1936683103}, ptr = 0x736f705f}, PH_loc = {
>   eigth = "nc\000\000\000\000\000", sixteen = {25454, 0, 0, 0},
> thirtytwo = {25454, 0}, sixtyfour = {25454}, unintptr = {25454},
>   ptr = 0x636e}}, MH_dat = {MH_ext = {ref_cnt = 0x0, ext_buf =
> 0x0, ext_size = 0, ext_type = 0, ext_flags = 0, ext_free = 0,
>   ext_arg1 = 0x0, ext_arg2 = 0x0},
> MH_databuf = '\0' , "file", '\0'  times>,
> "\006\000\000\000\020\000\000\000??\215?\000\000C\001\000\000\000\000\000\000\000\000\004\000\000\000\000\000\000\0Y?",
> '\0' ,
> "`2Y?\000\000\000\000\000\000\000\000T\211\223?\022\000\000\000\000\203??\000\000\000\000\000???",
> '\0' }},
> M_databuf =
> "\000\000\000\000\004\000\000\000\20

kern/185387: if_axe usb ethernet interface no ssh, no http with 10.0-RC3

2014-01-01 Thread Huub Schuurmans 

>Number: 185387
>Category:   kern
>Synopsis:   if_axe usb ethernet interface no ssh, no http with 10.0-RC3
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 01 16:10:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Huub Schuurmans
>Release:10.0-RC3
>Organization:
Wireless Leiden
>Environment:
10.0-RC3 FreeBSD 10.0-RC3 #0 r260039M: Sun Dec 29 22:04:42 CET 2013 ugen1.2: 
 at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) 
pwr=ON (200mA)
>Description:
USB-LAN adapters with the ASIX AX88772 chip do not work properly on 10.0-RC3, 
whereas thera are no problems with 9.0-RELEASE.
Ping and dhcp work, ssh and http do not.
Test setup consists of two ALIX.2 boards (uses CPU: Geode(TM) Integrated 
Processor by AMD PCS 498.06-MHz 586-class CPU and an AMD CS5536 (Geode) USB 2.0 
controller)

Host9.0-RELEASE with httpd, sshd, dhcpd running, connected with utp-cable 
(tested) to host10.0-RC3 with usb-lan adapter connected:
ue0: flags=8843 metric 0 mtu 1500 
options=8000b ether 00:00:00:00:00:01 inet6 
fe80::200:ff:fe00:1 %ue0 prefixlen 64 scopeid 0x8  inet 172.16.6.77 netmask 
0xfff8 broadcast 172.16.6.79  nd6 
options=29 media: Ethernet autoselect 
(100baseTX ) status: active

Ping and dhcp from host10.0-RC3 to Host9.0-RELEASE is OK, but ssh and fetch 
(http) time out.

Same setup with both hosts running 9.0-RELEASE functions without problems
Same setup with hostRC10-RC3 and different usb-lan adapter works OK (I tested 
if_aue, if_udav and if_mos).




>How-To-Repeat:
setup a similar test with two hosts and this usb-lan adapter
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

bin/185390: freebsd-update should work on installed version

2014-01-01 Thread Gary Aitken 

>Number: 185390
>Category:   bin
>Synopsis:   freebsd-update should work on installed version
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 01 17:10:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Gary Aitken
>Release:9.2-RELEASE
>Organization:
>Environment:
9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013 
r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
It should be possible to run freebsd-update on the installed version, to add 
components not previously included.  For example, if "src" is not listed when 
the original update was done, it should be possible to add it to the 
"Components" argument and rerun.

Or if it is desired to prune a portion of the system, it should be possible to
change the "Components" argument to "src/sys src/base world kernel" to prune 
the installed src.

Or if StrictComponents was set at the default and for some reason src was not 
updated, it should be possible to change it to "yes" and rerun to get src 
updated.
>How-To-Repeat:
>From a 9.2-RELEASE system, run
  
# freebsd-update -r 9.2-RELEASE upgrade
freebsd-update: Cannot upgrade from 9.2-RELEASE to itself

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail)

2014-01-01 Thread Nikolay Denev 
Ok, killing openvpn with -9 leaves the routes around, and particularly
interesting are the following routes :

78.90.222.xx   10.255.255.0   UGHS0 5841 epair0 =>
78.90.222.xx/3210.255.255.0   UGS 00 epair0

Now, if I do :

route delete 78.90.222.xx 10.255.255.0

The route, with the H flag is deleted. If I repeat the command the
second route is deleted as well, even if the second command specifies
a netmask no panic.

However the first delete command specifies the /32 mask like this :

route delete  78.90.222.xx 10.255.255.0 255.255.255.255

Then I get "rtfree 2" kernel panic immediately.

This seems to be happening as I'm manually installing static routes in
the vnet jail for the VPN remote endpoints , however OpenVPN adds such
routes too however differently, which results in two routing entries.

For example :

route add $IP $GW
and
route add $IP $GW 255.255.255.255

add to different route entries, one is /32 network, the other is a host route.



--Nikolay

On Wed, Jan 1, 2014 at 1:21 PM, Nikolay Denev  wrote:
> On Wed, Jan 1, 2014 at 1:10 PM, Nikolay Denev  wrote:
>>
>> On Sun, Dec 22, 2013 at 1:10 PM,  wrote:
>>>
>>> Thank you very much for your problem report.
>>> It has the internal identification `misc/185092'.
>>> The individual assigned to look at your
>>> report is: freebsd-bugs.
>>>
>>> You can access the state of your problem report at any time
>>> via this link:
>>>
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=185092
>>>
>>> >Category:   misc
>>> >Responsible:freebsd-bugs
>>> >Synopsis:   panic: rtfree 2 (using RADIX_MPATH in a VNET jail)
>>> >Arrival-Date:   Sun Dec 22 13:10:00 UTC 2013
>>
>>
>> I'm trying to understand exactly what is happening here, and examining a
>> core dump with kgdb I'm getting some output that confuses me :
>>
>> (kgdb) bt
>> #0  doadump (textdump=-1011569920) at pcpu.h:233
>> #1  0xc06069b2 in kern_reboot (howto=260) at
>> /usr/src/sys/kern/kern_shutdown.c:447
>> #2  0xc0606d0e in panic (fmt=) at
>> /usr/src/sys/kern/kern_shutdown.c:754
>> #3  0xc06de639 in rtfree (rt=) at
>> /usr/src/sys/net/route.c:464
>> #4  0xc06e188d in route_output (m=) at
>> /usr/src/sys/net/rtsock.c:951
>> #5  0xc06de18f in raw_usend (so=, flags=0, m=> optimized out>, nam=0x0, control=,
>> td=0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
>> #6  0xc066eca9 in sosend_generic (so=0xc3e9c1a8, uio=> out>, top=, control=0x0,
>> flags=, td=) at
>> /usr/src/sys/kern/uipc_socket.c:1271
>> #7  0xc066efc7 in sosend (so=0xc3e9c1a8, addr=0x0, uio=0xd9b9cc10,
>> top=0x0, control=0x0, flags=0, td=0xc3bd2000)
>> at /usr/src/sys/kern/uipc_socket.c:1315
>> #8  0xc0654af4 in soo_write (fp=0xc3c0c818, uio=0xd9b9cc10,
>> active_cred=0xc3f1dd00, flags=0, td=0xc3bd2000)
>> at /usr/src/sys/kern/sys_socket.c:103
>> #9  0xc064c866 in dofilewrite (td=0xc3bd2000, fd=3, fp=0xc3c0c818,
>> auio=0xd9b9cc10, offset=-1, flags=0) at file.h:303
>> #10 0xc064c566 in kern_writev (td=0xc3bd2000, fd=3, auio=> out>) at /usr/src/sys/kern/sys_generic.c:467
>> #11 0xc064c4bc in sys_write (td=, uap=> optimized out>) at /usr/src/sys/kern/sys_generic.c:382
>> #12 0xc08614d3 in syscall (frame=) at
>> subr_syscall.c:134
>> #13 0xc084cca1 in Xint0x80_syscall () at
>> /usr/src/sys/i386/i386/exception.s:270
>> #14 0x281975b7 in ?? ()
>> Previous frame inner to this frame (corrupt stack?)
>> Current language:  auto; currently minimal
>> (kgdb) fr 3
>> #3  0xc06de639 in rtfree (rt=) at
>> /usr/src/sys/net/route.c:464
>> 464 panic("rtfree 2");
>> (kgdb) print *rt
>> $1 = {rt_nodes = {{rn_mklist = 0xc3b4ab30, rn_parent = 0x1, rn_bit = 0,
>> rn_bmask = 0 '\0', rn_flags = 0 '\0', rn_u = {rn_leaf = {
>>   rn_Key = 0xc0882687 "shutdown_post_sync", rn_Mask = 0x103
>> , rn_Dupedkey = 0x0}, rn_node = {
>>   rn_Off = -1064819065, rn_L = 0x103, rn_R = 0x0}}},
>> {rn_mklist = 0x0, rn_parent = 0x4, rn_bit = -18048, rn_bmask = -94 '?',
>>   rn_flags = 195 '?', rn_u = {rn_leaf = {rn_Key = 0xc3a545e0 "",
>> rn_Mask = 0xc3a4e440 " ??(???\020'", rn_Dupedkey = 0xc3a4e880},
>> rn_node = {rn_Off = -1012578848, rn_L = 0xc3a4e440, rn_R =
>> 0xc3a4e880, rt_gateway = 0x74756873, rt_flags = 1853321060,
>>   rt_refcnt = 1936683103, rt_ifp = 0x79735f74, rt_ifa = 0x636e, rt_rmx =
>> {rmx_mtu = 0, rmx_expire = 0, rmx_pksent = 0, rmx_weight = 0},
>>   rt_fibnum = 0, rt_mtx = {lock_object = {lo_name = 0x0, lo_flags = 0,
>> lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}}
>>
>>
>>
>> rn_Key with value of “shutdown_post_sync” ?
>>
>> It’s visible also in the raw_usend() frame:
>>
>> (kgdb) fr 5
>> #5  0xc06de18f in raw_usend (so=, flags=0, m=> optimized out>, nam=0x0, control=,
>> td=0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
>> 238 return ((*so->so_proto->pr_output)(m, so));
>> (kgdb) print *m
>> $2 = {m_hdr = {mh_next = 0xc3b4ab30, mh_nextpkt = 0x1, mh_data = 0x0,
>> mh_len = -1064819065, mh_type = 0, mh_flags = 66304, mh_pad = 0},
>>   M

Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail)

2014-01-01 Thread Nikolay Denev 
The following reply was made to PR misc/185092; it has been noted by GNATS.

From: Nikolay Denev 
To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org, 
"freebsd-...@freebsd.org" 
Cc:  
Subject: Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail)
Date: Wed, 1 Jan 2014 17:39:42 +

 Ok, killing openvpn with -9 leaves the routes around, and particularly
 interesting are the following routes :
 
 78.90.222.xx   10.255.255.0   UGHS0 5841 epair0 =3D=
 >
 78.90.222.xx/3210.255.255.0   UGS 00 epair0
 
 Now, if I do :
 
 route delete 78.90.222.xx 10.255.255.0
 
 The route, with the H flag is deleted. If I repeat the command the
 second route is deleted as well, even if the second command specifies
 a netmask no panic.
 
 However the first delete command specifies the /32 mask like this :
 
 route delete  78.90.222.xx 10.255.255.0 255.255.255.255
 
 Then I get "rtfree 2" kernel panic immediately.
 
 This seems to be happening as I'm manually installing static routes in
 the vnet jail for the VPN remote endpoints , however OpenVPN adds such
 routes too however differently, which results in two routing entries.
 
 For example :
 
 route add $IP $GW
 and
 route add $IP $GW 255.255.255.255
 
 add to different route entries, one is /32 network, the other is a host rou=
 te.
 
 
 
 --Nikolay
 
 On Wed, Jan 1, 2014 at 1:21 PM, Nikolay Denev  wrote:
 > On Wed, Jan 1, 2014 at 1:10 PM, Nikolay Denev  wrote:
 >>
 >> On Sun, Dec 22, 2013 at 1:10 PM,  wrot=
 e:
 >>>
 >>> Thank you very much for your problem report.
 >>> It has the internal identification `misc/185092'.
 >>> The individual assigned to look at your
 >>> report is: freebsd-bugs.
 >>>
 >>> You can access the state of your problem report at any time
 >>> via this link:
 >>>
 >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D185092
 >>>
 >>> >Category:   misc
 >>> >Responsible:freebsd-bugs
 >>> >Synopsis:   panic: rtfree 2 (using RADIX_MPATH in a VNET jail)
 >>> >Arrival-Date:   Sun Dec 22 13:10:00 UTC 2013
 >>
 >>
 >> I'm trying to understand exactly what is happening here, and examining a
 >> core dump with kgdb I'm getting some output that confuses me :
 >>
 >> (kgdb) bt
 >> #0  doadump (textdump=3D-1011569920) at pcpu.h:233
 >> #1  0xc06069b2 in kern_reboot (howto=3D260) at
 >> /usr/src/sys/kern/kern_shutdown.c:447
 >> #2  0xc0606d0e in panic (fmt=3D) at
 >> /usr/src/sys/kern/kern_shutdown.c:754
 >> #3  0xc06de639 in rtfree (rt=3D) at
 >> /usr/src/sys/net/route.c:464
 >> #4  0xc06e188d in route_output (m=3D) at
 >> /usr/src/sys/net/rtsock.c:951
 >> #5  0xc06de18f in raw_usend (so=3D, flags=3D0, m=3D=
 > optimized out>, nam=3D0x0, control=3D,
 >> td=3D0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
 >> #6  0xc066eca9 in sosend_generic (so=3D0xc3e9c1a8, uio=3D> out>, top=3D, control=3D0x0,
 >> flags=3D, td=3D) at
 >> /usr/src/sys/kern/uipc_socket.c:1271
 >> #7  0xc066efc7 in sosend (so=3D0xc3e9c1a8, addr=3D0x0, uio=3D0xd9b9cc10,
 >> top=3D0x0, control=3D0x0, flags=3D0, td=3D0xc3bd2000)
 >> at /usr/src/sys/kern/uipc_socket.c:1315
 >> #8  0xc0654af4 in soo_write (fp=3D0xc3c0c818, uio=3D0xd9b9cc10,
 >> active_cred=3D0xc3f1dd00, flags=3D0, td=3D0xc3bd2000)
 >> at /usr/src/sys/kern/sys_socket.c:103
 >> #9  0xc064c866 in dofilewrite (td=3D0xc3bd2000, fd=3D3, fp=3D0xc3c0c818,
 >> auio=3D0xd9b9cc10, offset=3D-1, flags=3D0) at file.h:303
 >> #10 0xc064c566 in kern_writev (td=3D0xc3bd2000, fd=3D3, auio=3D> out>) at /usr/src/sys/kern/sys_generic.c:467
 >> #11 0xc064c4bc in sys_write (td=3D, uap=3D> optimized out>) at /usr/src/sys/kern/sys_generic.c:382
 >> #12 0xc08614d3 in syscall (frame=3D) at
 >> subr_syscall.c:134
 >> #13 0xc084cca1 in Xint0x80_syscall () at
 >> /usr/src/sys/i386/i386/exception.s:270
 >> #14 0x281975b7 in ?? ()
 >> Previous frame inner to this frame (corrupt stack?)
 >> Current language:  auto; currently minimal
 >> (kgdb) fr 3
 >> #3  0xc06de639 in rtfree (rt=3D) at
 >> /usr/src/sys/net/route.c:464
 >> 464 panic("rtfree 2");
 >> (kgdb) print *rt
 >> $1 =3D {rt_nodes =3D {{rn_mklist =3D 0xc3b4ab30, rn_parent =3D 0x1, rn_b=
 it =3D 0,
 >> rn_bmask =3D 0 '\0', rn_flags =3D 0 '\0', rn_u =3D {rn_leaf =3D {
 >>   rn_Key =3D 0xc0882687 "shutdown_post_sync", rn_Mask =3D 0x1030=
 000
 >> , rn_Dupedkey =3D 0x0}, rn_node =3D {
 >>   rn_Off =3D -1064819065, rn_L =3D 0x103, rn_R =3D 0x0}}},
 >> {rn_mklist =3D 0x0, rn_parent =3D 0x4, rn_bit =3D -18048, rn_bmask =3D -=
 94 '?',
 >>   rn_flags =3D 195 '?', rn_u =3D {rn_leaf =3D {rn_Key =3D 0xc3a545e0=
  "",
 >> rn_Mask =3D 0xc3a4e440 " ??(???\020'", rn_Dupedkey =3D 0xc3a4e880},
 >> rn_node =3D {rn_Off =3D -1012578848, rn_L =3D 0xc3a4e440, rn_R =
 =3D
 >> 0xc3a4e880, rt_gateway =3D 0x74756873, rt_flags =3D 1853321060,
 >>   rt_refcnt =3D 1936683103, rt_ifp =3D 0x79735f74, rt_ifa =3D 0x636e, rt=
 _rmx =3D
 >> {rmx_mtu =3D 0, rmx_expire =3D 0, rmx_pksent =3D 0, rmx

bin/185393: find -lname buffer read overflow bug

2014-01-01 Thread Ben Reser 

>Number: 185393
>Category:   bin
>Synopsis:   find -lname buffer read overflow bug
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 01 19:40:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Ben Reser
>Release:9.1
>Organization:
>Environment:
FreeBSD freebsd9.1 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 
09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC 
 amd64
>Description:
The implementation of -lname and -ilname improperly use readlink() by not 
setting a null character before using the string.  readlink() is documented as 
not doing this for you and returns the length of the link string, requiring the 
caller to set the null character.

In particular this is implemented in the usr.bin/find/function.c in the 
f_name() function.  The function uses an automatic buffer which gets reused 
through multiple calls, resulting in link names that are shorter than the 
preceding values stored in the buffer to fail to match properly.

This could cause the program to read past the end of the buffer.  In practice 
this doesn't seem to happen because the buffer seems to always end up in zeroed 
memory the first time it is used (though there's no requirement for it to do 
so).  This would result in a crash of the find command.

You can force reading past the end of the buffer by creating a link that points 
at a path of PATH_MAX length on the path being searched.  Presumably it's not 
possible to create a link that points at a path longer than that but if 
possible that would also allow reading past the end of the buffer.  I haven't 
bothered to exercise this.

It might be possible to view this as a minor security issue if someone is using 
find to try and find link with -lname for auditing purposes, since they might 
not reliably find what they are looking for.  The read past the end of the 
buffer doesn't seem particularly useful.  For one it'd only ever be a read, 
which isn't particularly useful and for another find doesn't run with escalated 
privileges.  So all in all I think it'd be a stretch to call this anything 
other than an ordinary bug.

This bug was introduced in r176497 (committed 5 years 10 months ago), so any 
releases of FreeBSD that contain this change would contain the same issue.  I 
actually happened to find the issue in OS X's fork of your find command.  But 
successfully duplicated the issue in a VM of 9.1 that I had laying around.
>How-To-Repeat:
The following shell script should demonstrate the issue:

#!/usr/bin/env bash

set -e

# Demonstration of -lname bug with FreeBSD and OS X find.

# find stops output matching links as soon as it passes a link
# that points at a path that is longer than the path we are trying
# to match.  Note that file system ordering of results may change
# when this happens.  OS X seems to return readdir results in
# alphabetical sorted order (HFS+) and FreeBSD (UFS) seems to return
# them in creation order (though there does seem to be some variation
# on this).  So the below example has both the creation
# order and the alphabetical sort order such that it should reliably
# reproduce the issue.  However, I've not tested this with other
# supported file systems so they may have different behavior, possibly
# even non-deterministic behavior that makes this harder to demonstrate.

# Expected behavior will have no output and a zero exit value.

test_dir=`mktemp -d find-test.XXX`
cd "$test_dir" > /dev/null
ln -s /usr/bin/gcc a
ln -s /usr/bin/touch b
ln -s /usr/bin/gcc c
ln -s /usr/bin/gcc d
ln -s /usr/bin/gcc e

echo './a' > expected
echo './c' >> expected
echo './d' >> expected
echo './e' >> expected

"${FIND:-find}" . -lname /usr/bin/gcc | sort > received
set +e
diff -u expected received
rv=$?
set -e
cd - > /dev/null
rm -rf "$test_dir"
exit $rv

>Fix:
Set a null character at fn[len] (where len is the return of the readlink() 
call) as implemented in the attached patch.

Patch attached with submission follows:

Index: usr.bin/find/function.c
===
--- usr.bin/find/function.c (revision 260159)
+++ usr.bin/find/function.c (working copy)
@@ -1124,9 +1124,11 @@ f_name(PLAN *plan, FTSENT *entry)
const char *name;
 
if (plan->flags & F_LINK) {
+   int len = readlink(entry->fts_path, fn, sizeof(fn));
+   if (len == -1)
+   return 0;
+   fn[len] = '\0';
name = fn;
-   if (readlink(entry->fts_path, fn, sizeof(fn)) == -1)
-   return 0;
} else
name = entry->fts_name;
return !fnmatch(plan->c_data, name,


>Release-Note:
>Audit-Trail:
>Unformatted:
___

kern/185395: IPv4 Multicast broken in 10.x

2014-01-01 Thread Peter Jeremy 

>Number: 185395
>Category:   kern
>Synopsis:   IPv4 Multicast broken in 10.x
>Confidential:   no
>Severity:   serious
>Priority:   high
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 01 19:40:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Peter Jeremy
>Release:FreeBSD 10.0-PRERELEASE amd64
>Organization:
n/a
>Environment:
System: FreeBSD server.rulingia.com 10.0-PRERELEASE FreeBSD 10.0-PRERELEASE #22 
r259613M: Sat Dec 21 09:49:27 EST 2013 
r...@server.rulingia.com:/var/obj/usr/src/sys/server amd64

Also verified on 10.0-ALPHA1 r255569 arm and r259613M i386.

>Description:
IPv4 multicast ethernet frames use the IP address of the default
route in the destination MAC address, instead of the IP address of
the multicast destination.  This breaks multicast filtering at the
receiver.

This is a regression from FreeBSD 9.2.

>How-To-Repeat:

Run (eg) 'tcpdump -e icmp' on one terminal and 'ping 224.18.52.86'
in another window.  The tcpdump should show ICMP packets with a
destination MAC address of 01:00:5E:12:34:56 but, in my case, they
have a destination MAC address of 01:00:5E:28:7B:7B - which matches
the IP address of my router.

>Fix:
Unknown.  The cause isn't obvious from a cursory look at the 9.x
and 10.x code.
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: bin/185393: find -lname buffer read overflow bug

2014-01-01 Thread Ben Reser 
The following reply was made to PR bin/185393; it has been noted by GNATS.

From: Ben Reser 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: bin/185393: find -lname buffer read overflow bug
Date: Wed, 01 Jan 2014 12:03:04 -0800

 This is a multi-part message in MIME format.
 --080101030108030107080503
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 Correction on the patch.  Forgot to subtract one byte from the buffer to allow
 for the NULL character to be set.  Updated patch attached.
 
 --080101030108030107080503
 Content-Type: text/plain; charset=UTF-8;
  name="fbsd-find-lname.patch.txt"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="fbsd-find-lname.patch.txt"
 
 Index: usr.bin/find/function.c
 ===
 --- usr.bin/find/function.c(revision 260159)
 +++ usr.bin/find/function.c(working copy)
 @@ -1124,9 +1124,11 @@ f_name(PLAN *plan, FTSENT *entry)
const char *name;
  
if (plan->flags & F_LINK) {
 +  int len = readlink(entry->fts_path, fn, sizeof(fn) - 1);
 +  if (len == -1)
 +  return 0;
 +  fn[len] = '\0';
name = fn;
 -  if (readlink(entry->fts_path, fn, sizeof(fn)) == -1)
 -  return 0;
} else
name = entry->fts_name;
return !fnmatch(plan->c_data, name,
 
 --080101030108030107080503--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/185395: IPv4 Multicast broken in 10.x

2014-01-01 Thread Olivier Cochard-Labbé 
The following reply was made to PR kern/185395; it has been noted by GNATS.

From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= 
To: Peter Jeremy , Gleb Smirnoff 
Cc: freebsd-gnats-submit 
Subject: Re: kern/185395: IPv4 Multicast broken in 10.x
Date: Wed, 1 Jan 2014 22:03:36 +0100

 --047d7b86db46eafcdb04eeef03ad
 Content-Type: text/plain; charset=ISO-8859-1
 
 On Wed, Jan 1, 2014 at 8:33 PM, Peter Jeremy  wrote:
 
 >
 > >Description:
 > IPv4 multicast ethernet frames use the IP address of the default
 > route in the destination MAC address, instead of the IP address of
 > the multicast destination.  This breaks multicast filtering at the
 > receiver.
 >
 > This is a regression from FreeBSD 9.2.
 >
 > >Fix:
 > Unknown.  The cause isn't obvious from a cursory look at the 9.x
 > and 10.x code.
 >
 
 And what about the commit 249925 "Add const qualifier to the dst parameter
 of the ifnet if_output method" (Fri Apr 26 12:50:32 2013 UTC) ?
 
 This commit modify function arpresolve() in sys/netinet/if_ether.c by
 replacing:
 arpresolve(...,struct sockaddr *dst, ...)
 by
 arpresolve(...,const struct sockaddr *dst, ...).
 
 And inside this function there is a call to this macro:
 ETHER_MAP_IP_MULTICAST(&SIN(dst)->sin_addr, desten);
 
 => If the 'structure dst' in now a 'const struct dst', can the struct 'dst'
 still be modified by the macro ??
 (I'm learning C, and don't understand this complex code).
 
 Regards,
 
 Olivier
 
 --047d7b86db46eafcdb04eeef03ad
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 On W=
 ed, Jan 1, 2014 at 8:33 PM, Peter Jeremy  wrote:
 
 
 >Description:
 =A0 =A0 =A0 =A0 IPv4 multicast ethernet frames use the IP address of the de=
 fault
 =A0 =A0 =A0 =A0 route in the destination MAC address, instead of the IP add=
 ress of
 =A0 =A0 =A0 =A0 the multicast destination. =A0This breaks multicast filteri=
 ng at the
 =A0 =A0 =A0 =A0 receiver.
 
 =A0 =A0 =A0 =A0 This is a regression from FreeBSD 9.2.
 >Fix:
 =A0 =A0 =A0 =A0 Unknown. =A0The cause isn't obvious from a cursory look=
  at the 9.x
 =A0 =A0 =A0 =A0 and 10.x code.And what=
  about the commit 249925 "Add const qualifier to the dst parameter of =
 the ifnet if_output method" (Fri Apr 26 12:50:32 2013 UTC) ?=
 
 
 This commit modify function arpresolve() in sys/netinet/if_e=
 ther.c by replacing:arpresolve(...,struct sockaddr *dst, ...)byarpresolve(...,const struct sockaddr *dst, ...).
 
 And inside this function there is a call to this =
 macro:ETHER_MAP_IP_MULTICAST(&SIN(dst)->sin_addr, des=
 ten);=3D> If the 'structure dst' i=
 n now a 'const struct dst', can the struct 'dst' still be m=
 odified by the macro ??
 
 (I'm learning C, and don't understand this complex code).Regards,Olivier<=
 /div>
 
 --047d7b86db46eafcdb04eeef03ad--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/182557: Frequent reboots due to kernel trap happening in pf_test_rule

2014-01-01 Thread glebius 
Synopsis: Frequent reboots due to kernel trap happening in pf_test_rule

State-Changed-From-To: open->closed
State-Changed-By: glebius
State-Changed-When: Wed Jan 1 21:51:17 UTC 2014
State-Changed-Why: 
This is duplicate of 182141, and the latter has much more information in it,
so preferred to be left open.

http://www.freebsd.org/cgi/query-pr.cgi?pr=182557
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/182141: [pf] crash in pf_test_rule

2014-01-01 Thread glebius 
Old Synopsis: Very frequent (at most 3 hours) kernel trap 12
New Synopsis: [pf] crash in pf_test_rule

State-Changed-From-To: open->feedback
State-Changed-By: glebius
State-Changed-When: Wed Jan 1 21:53:02 UTC 2014
State-Changed-Why: 
Patch sent to submitter for testing.


Responsible-Changed-From-To: freebsd-bugs->glebius
Responsible-Changed-By: glebius
Responsible-Changed-When: Wed Jan 1 21:53:02 UTC 2014
Responsible-Changed-Why: 
Patch sent to submitter for testing.

http://www.freebsd.org/cgi/query-pr.cgi?pr=182141
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

misc/185406: update py-django-simple-captcha from 0.4.0 to 0.4.1

2014-01-01 Thread John Hixson 

>Number: 185406
>Category:   misc
>Synopsis:   update py-django-simple-captcha from 0.4.0 to 0.4.1
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 02 03:20:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: John Hixson
>Release:11.0-CURRENT
>Organization:
iXsystems, Inc.
>Environment:
FreeBSD thinkbsd 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r259022M: Fri Dec  6 
12:03:57 PST 2013 john@thinkbsd:/usr/obj/usr/src/sys/THINKBSD  amd64

>Description:

>How-To-Repeat:

>Fix:


Patch attached with submission follows:

diff -urN py-django-simple-captcha.orig/Makefile 
py-django-simple-captcha/Makefile
--- py-django-simple-captcha.orig/Makefile  2013-11-30 01:39:47.0 
-0800
+++ py-django-simple-captcha/Makefile   2014-01-01 19:09:16.117372521 -0800
@@ -2,7 +2,7 @@
 # $FreeBSD: www/py-django-simple-captcha/Makefile 335272 2013-11-30 09:39:47Z 
sunpoet $
 
 PORTNAME=  django-simple-captcha
-PORTVERSION=   0.4.0
+PORTVERSION=   0.4.1
 CATEGORIES=www python
 MASTER_SITES=  CHEESESHOP
 PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
diff -urN py-django-simple-captcha.orig/distinfo 
py-django-simple-captcha/distinfo
--- py-django-simple-captcha.orig/distinfo  2013-11-30 01:39:47.0 
-0800
+++ py-django-simple-captcha/distinfo   2014-01-01 19:09:48.335013035 -0800
@@ -1,2 +1,2 @@
-SHA256 (django-simple-captcha-0.4.0.tar.gz) = 
9a09294da01e9c3205f08604fc25fd54423b31b1b3c882427605d22e8d6ee291
-SIZE (django-simple-captcha-0.4.0.tar.gz) = 60285
+SHA256 (django-simple-captcha-0.4.1.tar.gz) = 
caa194d5b7ea0cbcb69a797daaebae72d34a9ca32bfafddd08ead8e87bd7ef46
+SIZE (django-simple-captcha-0.4.1.tar.gz) = 60775


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/185395: IPv4 Multicast broken in 10.x

2014-01-01 Thread Peter Jeremy 
The following reply was made to PR kern/185395; it has been noted by GNATS.

From: Peter Jeremy 
To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= 
Cc: freebsd-gnats-submit 
Subject: Re: kern/185395: IPv4 Multicast broken in 10.x
Date: Thu, 2 Jan 2014 17:47:56 +1100

 --s9fJI615cBHmzTOP
 Content-Type: text/plain; charset=iso-8859-1
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On 2014-Jan-01 22:03:36 +0100, Olivier Cochard-Labb=E9 =
  wrote:
 >And what about the commit 249925 "Add const qualifier to the dst parameter
 >of the ifnet if_output method" (Fri Apr 26 12:50:32 2013 UTC) ?
 >
 >This commit modify function arpresolve() in sys/netinet/if_ether.c by
 >replacing:
 >arpresolve(...,struct sockaddr *dst, ...)
 >by
 >arpresolve(...,const struct sockaddr *dst, ...).
 >
 >And inside this function there is a call to this macro:
 >ETHER_MAP_IP_MULTICAST(&SIN(dst)->sin_addr, desten);
 
 ETHER_MAP_IP_MULTICAST does left to right assignment - the first argument is
 only read so this change doesn't affect anything.
 
 >=3D> If the 'structure dst' in now a 'const struct dst', can the struct 'd=
 st'
 >still be modified by the macro ??
 
 The macro never modified 'dst'.  In any case, the compiler tracks 'const'
 and would raise a compile-time error if something tried to modify dst.
 
 --=20
 Peter Jeremy
 
 --s9fJI615cBHmzTOP
 Content-Type: application/pgp-signature
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (FreeBSD)
 
 iKYEARECAGYFAlLFC5xfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
 bnBncC5maWZ0aGhvcnNlbWFuLm5ldDBCRjc3QTcyNTg5NEVCRTY0RjREN0VFRUZF
 OEE0N0JGRjAwRkI4ODcACgkQ/opHv/APuIeGJQCgrnnT3SfB+/6uk0lDzXhIBjfm
 jOEAoL9KLPmZUm3vuTu+V4oUEkMoBysl
 =vVA+
 -END PGP SIGNATURE-
 
 --s9fJI615cBHmzTOP--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"