pfctl: only allow "once" rules in anchors
This diff ensures that PF one shot rules can only be used inside anchors
and not in the main ruleset.
OK?
Index: sbin/pfctl/parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.624
diff -u -p -u -p -r1.624 parse.y
--- sbin/pfctl/parse.y 1 Aug 2013 19:03:11 - 1.624
+++ sbin/pfctl/parse.y 20 Aug 2013 01:54:10 -
@@ -1703,8 +1703,14 @@ pfrule : action dir logquick interface
r.set_prio[1] = $8.set_prio[1];
r.scrub_flags |= PFSTATE_SETPRIO;
}
- if ($8.marker & FOM_ONCE)
+ if ($8.marker & FOM_ONCE) {
+ if (pf->asd == 0) {
+ yyerror("'once' can only be used "
+ "inside anchors\n");
+ YYERROR;
+ }
r.rule_flag |= PFRULE_ONCE;
+ }
if ($8.marker & FOM_AFTO)
r.rule_flag |= PFRULE_AFTO;
r.af = $5;
Index: share/man/man5/pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.527
diff -u -p -u -p -r1.527 pf.conf.5
--- share/man/man5/pf.conf.525 Apr 2013 16:53:11 - 1.527
+++ share/man/man5/pf.conf.518 Aug 2013 19:13:23 -
@@ -611,6 +611,7 @@ directive occurs only at configuration f
.It Ar once
Creates a one shot rule that will remove itself from an active ruleset after
the first match.
+This parameter can only be used in an anchor.
In case this is the only rule in the anchor, the anchor will be destroyed
automatically after the rule is matched.
.Pp
ehci* on amd64 RAMDISK
Hi tech@. Along other lines, amd64 RAMDISK_CD have: # USB Controllers ehci*at pci?# Enhanced Host Controller # USB bus support usb*at ehci? But amd64 RAMDISK only have: # PCI USB Controllers ehci* at pci? # Enhanced Host Controller (notice absence of usb* at ehci? mapping) I have found KVM devices not attaching while using RAMDISK because KVM sits on ehci but there is no usb* at ehci? mapping. If I disable ehci, KVM normally attaches devices to legacy bus. So we either need to totally remove ehci (which is not used by any upper abstraction layers), or add usb* at ehci? mapping (which, probably, was intentionally omitted during 1.52->1.53). Cheers, Alexey
Re: Additional device apparently supported by urtwn(4)
On Mon, Aug 19, 2013 at 11:15 PM, Jonathan Gray wrote: > On Mon, Aug 19, 2013 at 07:45:42PM +0900, william dunand wrote: > > Hi Tech, > > > > It looks like urtwn(4) supports a mini dongle I happen to have bought, > the > > IO-DATA WN-G150UM. > > I registered the device in usbdevs and if_urtwn.c and have been running > it > > on 5.3 without major problem for about a week now. It is not 100% stable > > but it's decent enough. > > > > Is that enough to get it committed somehow? > > Please let me know if you need further information. > > > > Thanks! > > William > > It seems gmail mangled the whitespace on your patch so it wouldn't apply. > So I've applied it by hand and committed the changes, thanks. > Sorry for that, I didn't realize. Good thing the patch was a very small one. Thanks a lot!
Re: Additional device apparently supported by urtwn(4)
On Mon, Aug 19, 2013 at 07:45:42PM +0900, william dunand wrote: > Hi Tech, > > It looks like urtwn(4) supports a mini dongle I happen to have bought, the > IO-DATA WN-G150UM. > I registered the device in usbdevs and if_urtwn.c and have been running it > on 5.3 without major problem for about a week now. It is not 100% stable > but it's decent enough. > > Is that enough to get it committed somehow? > Please let me know if you need further information. > > Thanks! > William It seems gmail mangled the whitespace on your patch so it wouldn't apply. So I've applied it by hand and committed the changes, thanks.
Re: src/sbin/ifconfig: missing include
On 19 August 2013 12:52, David Coppa wrote: > > This misses util.h: > > cc -O2 -pipe -fno-pie -Wall -DINET6 -c /usr/src/sbin/ifconfig/ifconfig.c > /usr/src/sbin/ifconfig/ifconfig.c: In function 'setifwpakey': > /usr/src/sbin/ifconfig/ifconfig.c:1759: warning: implicit declaration of > function 'pkcs5_pbkdf2' > > OK? > OK
Re: src/sbin/ifconfig: missing include
On Mon, Aug 19, 2013 at 12:52:41PM +0200, David Coppa wrote: > > This misses util.h: > > cc -O2 -pipe -fno-pie -Wall -DINET6 -c /usr/src/sbin/ifconfig/ifconfig.c > /usr/src/sbin/ifconfig/ifconfig.c: In function 'setifwpakey': > /usr/src/sbin/ifconfig/ifconfig.c:1759: warning: implicit declaration of > function 'pkcs5_pbkdf2' > > OK? yes, -Otto > > Index: ifconfig.c > === > RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v > retrieving revision 1.268 > diff -u -p -u -p -r1.268 ifconfig.c > --- ifconfig.c16 Aug 2013 12:29:17 - 1.268 > +++ ifconfig.c19 Aug 2013 10:52:06 - > @@ -100,6 +100,7 @@ > #include > #include > #include > +#include > #include > > #include "brconfig.h"
src/sbin/ifconfig: missing include
This misses util.h: cc -O2 -pipe -fno-pie -Wall -DINET6 -c /usr/src/sbin/ifconfig/ifconfig.c /usr/src/sbin/ifconfig/ifconfig.c: In function 'setifwpakey': /usr/src/sbin/ifconfig/ifconfig.c:1759: warning: implicit declaration of function 'pkcs5_pbkdf2' OK? Index: ifconfig.c === RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v retrieving revision 1.268 diff -u -p -u -p -r1.268 ifconfig.c --- ifconfig.c 16 Aug 2013 12:29:17 - 1.268 +++ ifconfig.c 19 Aug 2013 10:52:06 - @@ -100,6 +100,7 @@ #include #include #include +#include #include #include "brconfig.h"
Additional device apparently supported by urtwn(4)
Hi Tech,
It looks like urtwn(4) supports a mini dongle I happen to have bought, the
IO-DATA WN-G150UM.
I registered the device in usbdevs and if_urtwn.c and have been running it
on 5.3 without major problem for about a week now. It is not 100% stable
but it's decent enough.
Is that enough to get it committed somehow?
Please let me know if you need further information.
Thanks!
William
diff -u ./if_urtwn.c /usr/src/sys/dev/usb/if_urtwn.c
--- ./if_urtwn.c Tue Oct 9 07:46:01 2012
+++ /usr/src/sys/dev/usb/if_urtwn.c Fri Aug 16 10:45:08 2013
@@ -102,6 +102,7 @@
{ USB_VENDOR_GUILLEMOT, USB_PRODUCT_GUILLEMOT_HWNUP150 },
{ USB_VENDOR_HAWKING, USB_PRODUCT_HAWKING_RTL8192CU },
{ USB_VENDOR_HP3, USB_PRODUCT_HP3_RTL8188CU },
+ { USB_VENDOR_IODATA, USB_PRODUCT_IODATA_WNG150UM },
{ USB_VENDOR_NETGEAR, USB_PRODUCT_NETGEAR_WNA1000M },
{ USB_VENDOR_NETGEAR, USB_PRODUCT_NETGEAR_RTL8192CU },
{ USB_VENDOR_NETGEAR4, USB_PRODUCT_NETGEAR4_RTL8188CU },
diff -u ./usbdevs /usr/src/sys/dev/usb/usbdevs
--- ./usbdevs Sat Feb 16 12:02:04 2013
+++ /usr/src/sys/dev/usb/usbdevs Fri Aug 16 10:44:17 2013
@@ -2203,6 +2203,7 @@
product IODATA RT3072_2 0x0945 RT3072
product IODATA RT3072_3 0x0947 RT3072
product IODATA RT3072_4 0x0948 RT3072
+product IODATA WNG150UM 0x094c WN-G150UM
product IODATA USBRSAQ 0x0a03 RSAQ1 Serial
product IODATA2 USB2SC 0x0a09 USB2.0-SCSI Bridge USB2-SC
product IODATA USBRSAQ5 0x0a0e RSAQ5 Serial
diff -u ./usbdevs.h /usr/src/sys/dev/usb/usbdevs.h
--- ./usbdevs.h Sat Feb 16 12:02:04 2013
+++ /usr/src/sys/dev/usb/usbdevs.h Fri Aug 16 10:44:22 2013
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.606 2013/01/28 12:02:01 stsp Exp $ */
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -2210,6 +2210,7 @@
#define USB_PRODUCT_IODATA_RT3072_2 0x0945 /* RT3072 */
#define USB_PRODUCT_IODATA_RT3072_3 0x0947 /* RT3072 */
#define USB_PRODUCT_IODATA_RT3072_4 0x0948 /* RT3072 */
+#define USB_PRODUCT_IODATA_WNG150UM 0x094c /* WN-G150UM */
#define USB_PRODUCT_IODATA_USBRSAQ 0x0a03 /* RSAQ1 Serial */
#define USB_PRODUCT_IODATA2_USB2SC 0x0a09 /* USB2.0-SCSI Bridge USB2-SC */
#define USB_PRODUCT_IODATA_USBRSAQ5 0x0a0e /* RSAQ5 Serial */
diff -u ./usbdevs_data.h /usr/src/sys/dev/usb/usbdevs_data.h
--- ./usbdevs_data.h Sat Feb 16 12:02:04 2013
+++ /usr/src/sys/dev/usb/usbdevs_data.h Fri Aug 16 10:44:22 2013
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.600 2013/01/28 12:02:01 stsp Exp $ */
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -4680,6 +4680,10 @@
{
USB_VENDOR_IODATA, USB_PRODUCT_IODATA_RT3072_4,
"RT3072",
+ },
+ {
+ USB_VENDOR_IODATA, USB_PRODUCT_IODATA_WNG150UM,
+ "WN-G150UM",
},
{
USB_VENDOR_IODATA, USB_PRODUCT_IODATA_USBRSAQ,
Re: Stop using static variables in ICMP
On 9 August 2013 11:04, Martin Pieuchot wrote: > This is the last episode from the first season of the serie, "move > your variables to the stack". Like in the previous episodes, this > one will let us execute the various icmp functions in parallel > without risk of trashing a value. > > It also reduces the difference with the icmp6 code adding a redirect > route. > > ok? > OK
