date:20160224

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

2016-02-24 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207463

--- Comment #4 from Kristof Provost  ---
I'll talk to re@ about MFCing this after the BETA3 builds are done (so in a
couple of days).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

2016-02-24 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207463

--- Comment #3 from commit-h...@freebsd.org ---
A commit references this bug:

Author: kp
Date: Thu Feb 25 07:33:59 UTC 2016
New revision: 296025
URL: https://svnweb.freebsd.org/changeset/base/296025

Log:
  pf: Fix possible out-of-bounds write

  In the DIOCRSETADDRS ioctl() handler we allocate a table for struct
pfr_addrs,
  which is processed in pfr_set_addrs(). At the users request we also provide
  feedback on the deleted addresses, by storing them after the new list
  ('bcopy(, addr + size + i, sizeof(ad));' in pfr_set_addrs()).

  This means we write outside the bounds of the buffer we've just allocated.
  We need to look at pfrio_size2 instead (i.e. the size the user reserved for
our
  feedback). That'd allow a malicious user to specify a smaller pfrio_size2
than
  pfrio_size though, in which case we'd still read outside of the allocated
  buffer. Instead we allocate the largest of the two values.

  Reported By:  Paul J Murphy 
  PR:   207463
  MFC after:5 days
  Differential Revision:https://reviews.freebsd.org/D5426

Changes:
  head/sys/netpfil/pf/pf_ioctl.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: net-im/skype4 under FreeBSD 10.3

2016-02-24 Thread Pavel Timofeev

2016-02-16 11:45 GMT+03:00 Slawa Olhovchenkov :
> On Tue, Feb 16, 2016 at 10:49:01AM +0300, Pavel Timofeev wrote:
>
>> 2016-02-15 15:28 GMT+03:00 Pavel Timofeev :
>> >
>> > 15 февр. 2016 г. 14:00 пользователь "Slawa Olhovchenkov" 
>> > написал:
>> >
>> >
>> >>
>> >> On Mon, Feb 15, 2016 at 12:06:08PM +0300, Pavel Timofeev wrote:
>> >>
>> >> > Hi!
>> >> > Has anybody tried net-im/skype4 under FreeBSD 10.3(-BETA[0-9])??
>> >>
>> >> I am using net-im/skype4 under FreeBSD 10.2-STABLE (after new
>> >> linuxulator import).
>> >> Chat and voice work good.
>> >>
>> >> > Seems like net-im/skype4 missing some dependencies and if it's
>> >> > satisfied net-im/skype4 hangs after start.
>> >> > linprocfs mounting doesn't help.
>> >> > I installed them all from the ports tree.
>> >> > Any experience?
>> >>
>> >> I am don't see this issue.
>> >
>> > Ok, thank you. I'll recheck.
>>
>> Well, I've managed to start skype4.
>> What I did is:
>> # mkdir -p /compat/linux/proc/
>> add linprocfs to /etc/fstab
>> add linux_enable="YES" to /etc/rc.conf
>> # reboot
>> # portmaster /usr/ports/net-im/skype4
>> Then I tried to start it and got:
>> % skype
>> /usr/local/share/skype/skype: error while loading shared libraries:
>> libpulse-mainloop-glib.so.0: cannot open shared object file: No such
>> file or directory
>> Then I installed missing dependency:
>
> I am use poudriere build and all dependens present:
>
> # pkg info -d skype4
> skype4-4.3.0.37,1:
> linux-skype_oss_wrapper-0.1.1
> linux_base-c6-6.6_6
> linux-c6-pulseaudio-libs-glib2-0.9.21
> linux-c6-qt47-4.7.2_1
> linux-c6-qt47-webkit-4.7.2_1
> webcamd-4.2.0.9
> linux-c6-libv4l-0.6.3_1
> linux-c6-xorg-libs-7.4_3
> linux-c6-expat-2.0.1_2
> linux-c6-openssl-compat-0.9.8e_2
> desktop-file-utils-0.22_3
> linux-c6-fontconfig-2.8.0_1
> linux-c6-qt47-x11-4.7.2_1
>
>> # portmaster /usr/ports/audio/linux-c6-pulseaudio-libs
>> And tried to start it again:
>> % skype
>> /usr/local/share/skype/skype: error while loading shared libraries:
>> libssl.so.10: cannot open shared object file: No such file or
>> directory
>> Installed another missing dependency:
>> # portmaster /usr/ports/security/linux-c6-openssl
>> And finally skype could start.
>>
>> So there are some missing dependencies. I've created a bug report.
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207240


This is what I wanted
https://svnweb.freebsd.org/ports?view=revision=409490
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

2016-02-24 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207463

--- Comment #2 from Paul J Murphy  ---
Yes, you are correct.  My patch was sufficient only for the default usage by
/sbin/pfctl, but left scope for other usage to cause problems.  I've looked
over your patch, and it looks good to me.  The existing buffer protection code
in pfr_set_addrs() also looks like it will handle a smaller size2 cleanly.  I
have just updated my releng/10.2 system to stable/10's sys/netpfil/pf and
sbin/pfctl, with your patch applied to it, and it seems to both pass a quick
and basic functionality test, and fix bug #192677 (it is now successfully
replacing a pf table with over 130,000 addrs, where 10.2-p12 fails for anything
over around 65,000).

Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

2016-02-24 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207463

Kristof Provost  changed:

   What|Removed |Added

 CC||k...@freebsd.org
   Assignee|freebsd-b...@freebsd.org|k...@freebsd.org

--- Comment #1 from Kristof Provost  ---
I think your analysis is correct.

The intention of the bcopy() appears to be to copy additional addresses behind
the original list (hence the adds + size + i construction).

You're correct that the buffer allocated by 'totlen = io->pfrio_size *
sizeof(struct pfr_addr);' is too small for that.
It's possible to panic a box that way.

I don't think your fix is sufficient though. If user space provides a smaller
pfrio_size2 than pfrio_size (remember that all user space programmers are out
to get us!) then we'd still end up running outsize the allocated buffer.

I think we need to allocate the largest of pfrio_size and pfrio_size2:
https://reviews.freebsd.org/D5426

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

2016-02-24 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207463

Bug ID: 207463
   Summary: [patch]
stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETAD
DRS) buffer overflow
   Product: Base System
   Version: 10.3-BETA2
  Hardware: Any
OS: Any
Status: New
  Keywords: patch
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: freebsd-b...@freebsd.org
  Reporter: p...@inetstat.net
CC: freebsd-stable@FreeBSD.org
  Keywords: patch

Created attachment 167367
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167367=edit
stable/10/sys/netpfil/pf/pf_ioctl.c patch

While investigating bug #192677 (pfctl iotcl buffer to small for bigger spamd
blacklists) on releng/10.2, I believe I have spotted a kernel buffer overflow
in stable/10/sys/netpfil/pf/pf_ioctl.c / stable/10/sys/netpfil/pf/pf_table.c,
introduced by base r286862 / base r286961.

stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS):

totlen = io->pfrio_size * sizeof(struct pfr_addr);
pfras = malloc(totlen, M_TEMP, M_WAITOK);

stable/10/sys/netpfil/pf/pf_table.c:pfr_set_addrs():

bcopy(, addr + size + i, sizeof(ad));

Inside pfr_set_addrs(), pfioctl()'s "pfras" becomes "addr", "io->pfrio_size"
becomes "size", and "io->pfrio_size2" becomes "size2".  pfr_set_addrs() uses
size2 to protect the buffer just above that bcopy.  Looking carefully at
stable/10/sys/sbin/pfctl/pfctl_table.c:pfctl_table("replace") and
stable/10/sys/sbin/pfctl/pfctl_radix.c:pfr_buf_grow(), io->pfrio_buffer passed
into the ioctl is size2.

This is theoretical, based on simulating the code mentally.  I'm fairly certain
that my analysis is correct, but I've not verified it via compiled stable/10
code.  The bcopy seems to fairly obviously run off the end of the buffer when
it is only "size".  The fix should be quite simple, by just changing the buffer
to be "size2" in stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS):

totlen = io->pfrio_size2 * sizeof(struct pfr_addr);

Untested patch attached.  I believe this applies to both stable/10 and head.  I
have tagged it as 10.3-BETA, as that seems to be the places where the more
urgent attention is needed, as it would be quite unfortunate for 10.3 to be
released with this bug (if my analysis is correct).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2 - Process stuck in unkillable sleep

2016-02-24 Thread Michael Jung


On 2016-02-24 08:18, Konstantin Belousov wrote:

On Wed, Feb 24, 2016 at 02:26:19PM +1000, Paul Koch wrote:


Occasionally we see a process get stuck in an unkillable state and
the only solution is a hard reboot.

Occasionally == once every two weeks across 60+ servers, which are 
spread
across the globe in customer sites.  We have no remote access to these 
boxes.


The process that most often that gets stuck, but not limited to, is a 
large
scale Ping/SNMP poller.  It is a fairly simplistic C program that just 
fires

out lots of ping (raw ICMP socket) and SNMP (UDP socket) requests
asynchronously.

We've managed to trap the problem a few times on a test server running 
in
VirtualBox, but it also occurs on customer sites who run VMware, 
Hyper-V,

QEMU and on bare metal.


We raise this PR
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204081

but suspect it is a similar/same issue as
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200992

This is the info we've gathered from the most recent time it has 
occurred:



# uname -a
FreeBSD shed153.akips.com 10.2-RELEASE-p12 FreeBSD 10.2-RELEASE-p12 #0 
r295070:
Sat Jan 30 20:03:44 UTC 2016  
r...@shed21.akips.com:/usr/obj/usr/src/sys/GENERIC amd64



# ps auxww | grep nm-poller
akips1014   0.0  2.6 871820 106540  -  Ds   10Feb16  1078:59.06 
nm-poller



# procstat -k 1014
  PIDTID COMM   TDNAME   KSTACK
 1014 100365 nm-poller  -mi_switch sleepq_timedwait_sig 
_cv_timedwait_sig_sbt seltdwait kern_select sys_select amd64_syscall 
Xfast_syscall




Yes, on HEAD it was reported that the https://reviews.freebsd.org/D5221
fixed the problem.  Still not reviewed.

I did back-port to stable/10, the patch below is probably not 
applicable

to 10.2, you would need 10.3 for it.  Some revisions are missed from
stable/10, but I think that the issue worked around in the patch is at
the core of troubles many people reported.

Index: sys/kern/kern_timeout.c
===
--- sys/kern/kern_timeout.c (revision 295966)
+++ sys/kern/kern_timeout.c (working copy)
@@ -1127,7 +1127,7 @@ _callout_stop_safe(c, safe)
 	 * Some old subsystems don't hold Giant while running a 
callout_stop(),

 * so just discard this check for the moment.
 */
-   if (!safe && c->c_lock != NULL) {
+   if ((safe & CS_DRAIN) == 0 && c->c_lock != NULL) {
if (c->c_lock == _object)
use_lock = mtx_owned();
else {
@@ -1207,7 +1207,7 @@ again:
return (0);
}

-   if (safe) {
+   if ((safe & CS_DRAIN) != 0) {
/*
 * The current callout is running (or just
 * about to run) and blocking is allowed, so
@@ -1319,7 +1319,7 @@ again:
CTR3(KTR_CALLOUT, "postponing stop %p func %p arg %p",
c, c->c_func, c->c_arg);
CC_UNLOCK(cc);
-   return (0);
+   return ((safe & CS_MIGRBLOCK) != 0);
}
CTR3(KTR_CALLOUT, "failed to stop %p func %p arg %p",
c, c->c_func, c->c_arg);
Index: sys/kern/subr_sleepqueue.c
===
--- sys/kern/subr_sleepqueue.c  (revision 295966)
+++ sys/kern/subr_sleepqueue.c  (working copy)
@@ -572,7 +572,8 @@ sleepq_check_timeout(void)
 * another CPU, so synchronize with it to avoid having it
 * accidentally wake up a subsequent sleep.
 */
-   else if (callout_stop(>td_slpcallout) == 0) {
+   else if (_callout_stop_safe(>td_slpcallout, CS_MIGRBLOCK)
+   == 0) {
td->td_flags |= TDF_TIMEOUT;
TD_SET_SLEEPING(td);
mi_switch(SW_INVOL | SWT_SLEEPQTIMO, NULL);
Index: sys/sys/callout.h
===
--- sys/sys/callout.h   (revision 295966)
+++ sys/sys/callout.h   (working copy)
@@ -62,6 +62,9 @@ struct callout_handle {
struct callout *callout;
 };

+#defineCS_DRAIN0x0001
+#defineCS_MIGRBLOCK0x0002
+
 #ifdef _KERNEL
 /*
  * Note the flags field is actually *two* fields. The c_flags
@@ -81,7 +84,7 @@ struct callout_handle {
  */
 #definecallout_active(c)   ((c)->c_flags & CALLOUT_ACTIVE)
 #definecallout_deactivate(c)   ((c)->c_flags &= ~CALLOUT_ACTIVE)
-#definecallout_drain(c)_callout_stop_safe(c, 1)
+#definecallout_drain(c)_callout_stop_safe(c, CS_DRAIN)
 void   callout_init(struct callout *, int);
 void   _callout_init_lock(struct callout *, struct lock_object *, int);
 #definecallout_init_mtx(c, mtx, flags) 
\

___
freebsd-stable@freebsd.org mailing list

Re: 10.2 - Process stuck in unkillable sleep

2016-02-24 Thread Konstantin Belousov

On Wed, Feb 24, 2016 at 02:26:19PM +1000, Paul Koch wrote:
> 
> Occasionally we see a process get stuck in an unkillable state and
> the only solution is a hard reboot.
> 
> Occasionally == once every two weeks across 60+ servers, which are spread
> across the globe in customer sites.  We have no remote access to these boxes.
> 
> The process that most often that gets stuck, but not limited to, is a large
> scale Ping/SNMP poller.  It is a fairly simplistic C program that just fires
> out lots of ping (raw ICMP socket) and SNMP (UDP socket) requests
> asynchronously.
> 
> We've managed to trap the problem a few times on a test server running in
> VirtualBox, but it also occurs on customer sites who run VMware, Hyper-V,
> QEMU and on bare metal.
> 
> 
> We raise this PR
>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204081
> 
> but suspect it is a similar/same issue as
>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200992
> 
> This is the info we've gathered from the most recent time it has occurred:
> 
> 
> # uname -a
> FreeBSD shed153.akips.com 10.2-RELEASE-p12 FreeBSD 10.2-RELEASE-p12 #0 
> r295070:
> Sat Jan 30 20:03:44 UTC 2016  
> r...@shed21.akips.com:/usr/obj/usr/src/sys/GENERIC amd64

> # ps auxww | grep nm-poller
> akips1014   0.0  2.6 871820 106540  -  Ds   10Feb16  1078:59.06 nm-poller
> 
> 
> # procstat -k 1014 
>   PIDTID COMM   TDNAME   KSTACK   
>  1014 100365 nm-poller  -mi_switch sleepq_timedwait_sig 
> _cv_timedwait_sig_sbt seltdwait kern_select sys_select amd64_syscall 
> Xfast_syscall 
> 

Yes, on HEAD it was reported that the https://reviews.freebsd.org/D5221
fixed the problem.  Still not reviewed.

I did back-port to stable/10, the patch below is probably not applicable
to 10.2, you would need 10.3 for it.  Some revisions are missed from
stable/10, but I think that the issue worked around in the patch is at
the core of troubles many people reported.

Index: sys/kern/kern_timeout.c
===
--- sys/kern/kern_timeout.c (revision 295966)
+++ sys/kern/kern_timeout.c (working copy)
@@ -1127,7 +1127,7 @@ _callout_stop_safe(c, safe)
 * Some old subsystems don't hold Giant while running a callout_stop(),
 * so just discard this check for the moment.
 */
-   if (!safe && c->c_lock != NULL) {
+   if ((safe & CS_DRAIN) == 0 && c->c_lock != NULL) {
if (c->c_lock == _object)
use_lock = mtx_owned();
else {
@@ -1207,7 +1207,7 @@ again:
return (0);
}
 
-   if (safe) {
+   if ((safe & CS_DRAIN) != 0) {
/*
 * The current callout is running (or just
 * about to run) and blocking is allowed, so
@@ -1319,7 +1319,7 @@ again:
CTR3(KTR_CALLOUT, "postponing stop %p func %p arg %p",
c, c->c_func, c->c_arg);
CC_UNLOCK(cc);
-   return (0);
+   return ((safe & CS_MIGRBLOCK) != 0);
}
CTR3(KTR_CALLOUT, "failed to stop %p func %p arg %p",
c, c->c_func, c->c_arg);
Index: sys/kern/subr_sleepqueue.c
===
--- sys/kern/subr_sleepqueue.c  (revision 295966)
+++ sys/kern/subr_sleepqueue.c  (working copy)
@@ -572,7 +572,8 @@ sleepq_check_timeout(void)
 * another CPU, so synchronize with it to avoid having it
 * accidentally wake up a subsequent sleep.
 */
-   else if (callout_stop(>td_slpcallout) == 0) {
+   else if (_callout_stop_safe(>td_slpcallout, CS_MIGRBLOCK)
+   == 0) {
td->td_flags |= TDF_TIMEOUT;
TD_SET_SLEEPING(td);
mi_switch(SW_INVOL | SWT_SLEEPQTIMO, NULL);
Index: sys/sys/callout.h
===
--- sys/sys/callout.h   (revision 295966)
+++ sys/sys/callout.h   (working copy)
@@ -62,6 +62,9 @@ struct callout_handle {
struct callout *callout;
 };
 
+#defineCS_DRAIN0x0001
+#defineCS_MIGRBLOCK0x0002
+
 #ifdef _KERNEL
 /* 
  * Note the flags field is actually *two* fields. The c_flags
@@ -81,7 +84,7 @@ struct callout_handle {
  */
 #definecallout_active(c)   ((c)->c_flags & CALLOUT_ACTIVE)
 #definecallout_deactivate(c)   ((c)->c_flags &= ~CALLOUT_ACTIVE)
-#definecallout_drain(c)_callout_stop_safe(c, 1)
+#definecallout_drain(c)_callout_stop_safe(c, CS_DRAIN)
 void   callout_init(struct callout *, int);
 void   _callout_init_lock(struct callout *, struct lock_object *, int);
 #definecallout_init_mtx(c, mtx, flags) 
\

___

Re: ipfw dscp cs4

2016-02-24 Thread Ian Smith

On Wed, 24 Feb 2016 13:55:22 +0200, swh...@gov.za wrote:
 > On Wed, 24 Feb 2016, Kurt Jaeger wrote:
 > 
 > > It's a good place, if you run a stable version. What version of FreeBSD
 > > do you run ?
 > 
 > I'm not running -stable, no, but I've seen this behaviour on 9.3-R, 9.3-Rp33
 > and 10.2-Rp8.
 > 
 > > And it's an interesting bug-report. Other places where it might
 > > be useful are:
 > > 
 > > 1) https://bugs.freebsd.org/
 > >   (preferred)
 > > 2) freebsd-i...@freebsd.org
 > > 
 > > Would you mind filling in a bug report ?
 > 
 > I'll set up the bugzilla account now.

And please do also post this (and/or cc: from the bug) to freebsd-ipfw

cheers, Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ipfw dscp cs4

2016-02-24 Thread swhite


On Wed, 24 Feb 2016, Ian Smith wrote:


And please do also post this (and/or cc: from the bug) to freebsd-ipfw


Wilco.

Regards,
- Sean.

--
"For a man to truly understand rejection, he must first be ignored
 by a cat."
-- Anon.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ipfw dscp cs4

2016-02-24 Thread swhite


On Wed, 24 Feb 2016, Kurt Jaeger wrote:


It's a good place, if you run a stable version. What version of FreeBSD
do you run ?


I'm not running -stable, no, but I've seen this behaviour on 9.3-R, 
9.3-Rp33 and 10.2-Rp8.



And it's an interesting bug-report. Other places where it might
be useful are:

1) https://bugs.freebsd.org/
  (preferred)
2) freebsd-i...@freebsd.org

Would you mind filling in a bug report ?


I'll set up the bugzilla account now.

Regards,
- Sean.

--
"For a man to truly understand rejection, he must first be ignored
 by a cat."
-- Anon.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ipfw dscp cs4

2016-02-24 Thread Kurt Jaeger

Hi!

> Not sure if this is the right place to enquire about this. If not please 
> direct me to the right place and accept my apologies.

It's a good place, if you run a stable version. What version of FreeBSD
do you run ?

And it's an interesting bug-report. Other places where it might
be useful are:

1) https://bugs.freebsd.org/
   (preferred)
2) freebsd-i...@freebsd.org

Would you mind filling in a bug report ?

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

ipfw dscp cs4

2016-02-24 Thread swhite


Hi!

Not sure if this is the right place to enquire about this. If not please 
direct me to the right place and accept my apologies.


I'm trying to shape traffic using ipfw/dummynet that has been marked 
upstream with dscp cs4 and get this:


# ipfw add 1 pipe 1 in dscp cs4 recv igb0
1 pipe 1 ip from any to any in dscp be recv igb0
#

but this:

# ipfw add 1 pipe 1 in dscp cs2 recv igb0
1 pipe 1 ip from any to any in dscp cs2 recv igb0
#

...appears to be fine. Pretty much anything else works other than cs4 
which gets interpreted as be (0x0).


Bug?

Regards,
- Sean.

--
"For a man to truly understand rejection, he must first be ignored
 by a cat."
-- Anon.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

Re: net-im/skype4 under FreeBSD 10.3

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

Re: 10.2 - Process stuck in unkillable sleep

Re: 10.2 - Process stuck in unkillable sleep

Re: ipfw dscp cs4

Re: ipfw dscp cs4

Re: ipfw dscp cs4

Re: ipfw dscp cs4

ipfw dscp cs4

13 matches

Site Navigation

Mail list logo

Footer information