Re: King Jim Portabook

2016-12-10 Thread Ryan McBride 
On Sat, Dec 10, 2016 at 08:17:10PM +0900, Ryan McBride wrote:
> So I've been eying this machine for a while:
> http://www.kingjim.co.jp/sp/portabook/xmc10/

Included below is the dmesg with the previous diff applied.

Besides all the devices that show "not configured", there are a bunch of
other things that don't work. I guess there's more broken that I haven't
run into yet.

- Built-in keyboard does not work in the bootloader (an external USB
  keyboard is fine)

- zzz fails with "acpi0: state S3 unavailable"

- Console does not use the whole screen, there is an empty border around
  the whole screen (~2 chars tall at top and bottom, ~3 wide on the
  sides)

- X fails to start (see below)

Any ACPI hackers interested in a Christmas "gift"?


[23.406] (--) checkDevMem: using aperture driver /dev/xf86
[23.415] (--) Using wscons driver on /dev/ttyC4
[23.429] 
X.Org X Server 1.18.4
Release Date: 2016-07-19
[23.429] X Protocol Version 11, Revision 0
[23.429] Build Operating System: OpenBSD 6.0 amd64 
[23.429] Current Operating System: OpenBSD asdf.my.domain 6.0 GENERIC.MP#1 
amd64
[23.429] Build Date: 25 November 2016  11:21:01AM
[23.429]  
[23.429] Current version of pixman: 0.34.0
[23.429]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[23.429] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[23.429] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 22 05:10:12 
2015
[23.432] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"
[23.434] (==) No Layout section.  Using the first Screen section.
[23.434] (==) No screen section available. Using defaults.
[23.434] (**) |-->Screen "Default Screen Section" (0)
[23.435] (**) |   |-->Monitor ""
[23.437] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[23.437] (==) Disabling SIGIO handlers for input devices
[23.438] (==) Automatically adding devices
[23.438] (==) Automatically enabling devices
[23.438] (==) Not automatically adding GPU devices
[23.439] (==) Max clients allowed: 256, resource mask: 0x1f
[23.457] (==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/TTF/,
/usr/X11R6/lib/X11/fonts/OTF/,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/
[23.457] (==) ModulePath set to "/usr/X11R6/lib/modules"
[23.457] (II) The server relies on wscons to provide the list of input 
devices.
If no devices become available, reconfigure wscons or disable 
AutoAddDevices.
[23.458] (II) Loader magic: 0x1b864e534020
[23.458] (II) Module ABI versions:
[23.458]X.Org ANSI C Emulation: 0.4
[23.458]X.Org Video Driver: 20.0
[23.458]X.Org XInput driver : 22.1
[23.458]X.Org Server Extension : 9.0
[23.459] (--) PCI:*(0:0:2:0) 8086:22b0:1b0a:01bc rev 32, Mem @ 
0x9000/16777216, 0x8000/268435456, I/O @ 0xf000/64
[23.459] (II) LoadModule: "glx"
[23.463] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
[23.501] (II) Module glx: vendor="X.Org Foundation"
[23.501]compiled for 1.18.4, module version = 1.0.0
[23.501]ABI class: X.Org Server Extension, version 9.0
[23.501] (==) AIGLX enabled
[23.502] (==) Matched intel as autoconfigured driver 0
[23.502] (==) Matched vesa as autoconfigured driver 1
[23.502] (==) Assigned the driver to the xf86ConfigLayout
[23.502] (II) LoadModule: "intel"
[23.502] (II) Loading /usr/X11R6/lib/modules/drivers/intel_drv.so
[23.513] (II) Module intel: vendor="X.Org Foundation"
[23.513]compiled for 1.18.4, module version = 2.99.916
[23.513]Module class: X.Org Video Driver
[23.513]ABI class: X.Org Video Driver, version 20.0
[23.513] (II) LoadModule: "vesa"
[23.514] (II) Loading /usr/X11R6/lib/modules/drivers/vesa_drv.so
[23.516] (II) Module vesa: vendor="X.Org Foundation"
[23.516]compiled for 1.18.4, module version = 2.3.4
[23.516]Module class: X.Org Video Driver
[23.516]ABI class: X.Org Video Driver, version 20.0
[23.516] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[23.517] (II) intel: Driver for Intel(R) HD Graph

King Jim Portabook

2016-12-10 Thread Ryan McBride 
So I've been eying this machine for a while:
http://www.kingjim.co.jp/sp/portabook/xmc10/

Original price was a rediculous JPY 96,000 but it's dropped to a reasonable
JPY 20,000 (about USD 200) so I picked one up.

bsd.rd boots, but GENERIC / GENERIC.MP fail to parse the ACPI AML; it
needs the following diff to boot.

Perhaps someone more familiar with ACPI than I can pick this up and
actually do something useful with the ACPI_OPREG_GSB instead of just
skipping it.


Index: dev/acpi//dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.227
diff -u -p -u -r1.227 dsdt.c
--- dev/acpi//dsdt.c25 Oct 2016 06:48:58 -  1.227
+++ dev/acpi//dsdt.c27 Nov 2016 06:11:58 -
@@ -2031,6 +2031,9 @@ aml_convert(struct aml_value *a, int cty
c = aml_allocvalue(AML_OBJTYPE_BUFFER, a->length,
a->v_string);
break;
+   case AML_OBJTYPE_UNINITIALIZED:
+   c = aml_allocvalue(AML_OBJTYPE_BUFFER, 0, NULL);
+   break;
}
break;
case AML_OBJTYPE_INTEGER:
@@ -2064,6 +2067,9 @@ aml_convert(struct aml_value *a, int cty
c = aml_allocvalue(AML_OBJTYPE_STRING, a->length,
a->v_buffer);
break;
+   case AML_OBJTYPE_UNINITIALIZED:
+   c = aml_allocvalue(AML_OBJTYPE_STRING, 0, NULL);
+   break;
case AML_OBJTYPE_STRING:
aml_addref(a, "XConvert");
return a;
@@ -2462,6 +2468,8 @@ aml_rwfield(struct aml_value *fld, int b
val, mode, fld->v_field.flags);
} else if (fld->v_field.type == AMLOP_FIELD) {
switch (ref1->v_opregion.iospace) {
+   case ACPI_OPREG_GSB:
+   break;
case ACPI_OPREG_GPIO:
aml_rwgpio(ref2, bpos, blen, val, mode,
fld->v_field.flags);

Re: autoinstall(8) tweaks

2015-04-14 Thread Ryan McBride 
On Thu, Apr 09, 2015 at 04:27:17AM -0600, Theo de Raadt wrote:
  But it seems people are expected to build a custom bsd.rd if they
  want something different so I'll bow out of this conversation.
 
 No, the situation is that less than 1% of the user community
 apparently have a secret usage case, but never manage to explain it.
 

I manage a bunch of OpenBSD proxies that I would like to be able to
build from scratch using automated tools; everything is in place 
(ansible) except for the base OpenBSD install as I need a separate
/var/squid partition to prevent cache / log disasters from filling /var;
similar concerns would apply to many other data / log-heavy daemons.

On other systems where I don't know how the data will grow, I typically
configure them with something close to the auto layout, but a smaller
/home, and leave the remaining disk empty. When I get a feel for what
the data usage is in /var/daemon or /home or /usr/local, I can expand
/home or create a new partition and migrate the data.

Other reasons to want non-auto partitioning like include:
- simpler dump/restore
- moving certain parts of hier(7) onto a different device
  (you can do this as a post-install task if they are empty, but
  it becomes a pain if it's something that's part of base)

A place where the latter can be quite useful is on a virtualised guest,
where you can easily make one storage device persistant, and another
ephemeral across reboots.

Yes, all of this can be done manually, but basically any place I would
care to work at is moving towards complete automation of system installs
(for *hack*Cloud*spit*, Continuous Delivery, DR, or just plain old
laziness). It would be really nice if the OpenBSD installer would handle
this in a sane fashion.

Note: I don't use the auto-layout except on throwaway test installs
as it never seems to give me the layout I need, and except for laptops
I would prefer to never use the interactive installer at all.

support WCCPv2 in gre(4)

2014-12-20 Thread Ryan McBride 
This diff allows us to set net.inet.gre.wccp sysctl to 2, in which 
case gre(4) will skip the WCCPv2 redirect header, allowing us to
handle the packet in the same way as WCCPv1.

Squid knows how to set up the WCCPv2 session with the Cisco and
handles transparent HTTP proxying, use PF divert the traffic into
Squid's intercept port (or with relayd, use 'forward to destination')

Tested on amd64 with a Cisco ASA 5520.

More magic (perhaps in PF) would be needed to actually interpret
the redirect header and fully handle the WCCPv2 protocol.


Index: share/man/man4/gre.4
===
RCS file: /cvs/src/share/man/man4/gre.4,v
retrieving revision 1.39
diff -u -p -u -r1.39 gre.4
--- share/man/man4/gre.419 Oct 2013 16:53:15 -  1.39
+++ share/man/man4/gre.420 Dec 2014 11:56:25 -
@@ -54,7 +54,10 @@ variables respectively in
 .It Va net.inet.gre.allow
 Allow GRE packets in and out of the system.
 .It Va net.inet.gre.wccp
-Allow WCCPv1-style GRE packets into the system (depends on the above).
+Set to 1 to allow WCCPv1-style GRE packets into the system,
+set to 2 to handle the the packets as WCCPv2-style GRE, truncating
+the redirect header.
+This variable depends on the above.
 .It Va net.inet.mobileip.allow
 Allow MobileIP packets in and out of the system.
 .El
@@ -235,8 +238,8 @@ The kernel must be set to forward datagr
 option to
 .Xr sysctl 8 .
 .Pp
-The GRE interface will accept WCCPv1-style GRE encapsulated packets
-from a Cisco router.
+The GRE interface will accept WCCPv1-style or WWCPv2-style GRE
+encapsulated packets from a Cisco router.
 Some magic with the packet filter configuration
 and a caching proxy like squid are needed to do anything useful with
 these packets.
@@ -292,6 +295,5 @@ these packets.
 .Sh BUGS
 GRE RFC not yet fully implemented (no GRE options).
 .Pp
-For the WCCP GRE encapsulated packets we can only reliably accept
-WCCPv1 format; WCCPv2 formatted packets add another header which will
-skew the decode, and results are not defined (i.e. don't do WCCPv2).
+For WCCPv2 GRE encapsulated packets we don't handle the redirect
+header, but simply skip it.
Index: sys/netinet/ip_gre.c
===
RCS file: /cvs/src/sys/netinet/ip_gre.c,v
retrieving revision 1.52
diff -u -p -u -r1.52 ip_gre.c
--- sys/netinet/ip_gre.c19 Dec 2014 17:14:40 -  1.52
+++ sys/netinet/ip_gre.c20 Dec 2014 11:56:25 -
@@ -145,14 +145,22 @@ gre_input2(struct mbuf *m, int hlen, u_c
 *   GRE tunnel is precisely a IP-in-GRE tunnel that 
differs
 *   only in its protocol number.  At least, it works 
for me.
 *
-*   The Internet Draft can be found if you look for
+*   The Internet Drafts can be found if you look for
+*   the following:
 * draft-forster-wrec-wccp-v1-00.txt
+* draft-wilson-wrec-wccp-v2-01.txt
 *
 *   So yes, we're doing a fall-through (unless, of 
course,
 *   net.inet.gre.wccp is 0).
 */
if (!gre_wccp)
return (0);
+   /*
+* For WCCPv2, additionally skip the 4 byte
+* redirect header.
+*/
+   if (gre_wccp == 2) 
+   hlen += 4;
case ETHERTYPE_IP: /* shouldn't need a schednetisr(), as */
ifq = ipintrq;  /* we are in ip_input */
af = AF_INET;

Re: Remove rti_ifp from struct rt_addrinfo

2014-04-25 Thread Ryan McBride 
On Fri, Apr 25, 2014 at 02:40:57AM +0200, Alexander Bluhm wrote:
 On Fri, Apr 25, 2014 at 09:09:03AM +0900, Ryan McBride wrote:
  Part of the reason it's there is to make carp work properly for services
  listening on the carp interface, in particular so that hosts in the
  BACKUP state will reach the MASTER rather than trying and failing to
  connect to their own carp interface. Maybe not needed in all setups, but
  likely to break things if we simply remove it.
 
 Why do you want to connect from the BACKUP machine to the MASTER
 using CARP addresses?  Just add another fixed address and you can
 do that.

Two reasons that come to mind are:

1) For troubleshooting, so I can ping or otherwise monitor the MASTER
host.

2) In some cases it's undisireable (or even not possible) to run
services on other IP addresses. For example, services that only allow
you to configure 1 listening IP, or services where you wish to avoid
users connecting to anything but the MASTER server.

 The current implementation may change the routing table in subtile
 ways until nothing works.  In IPv6 the routes are fixed and there
 are less problems.

In my opinion the current (intended) behaviour is correct; my preference
would be to see this fixed rather than removed.

Re: Remove rti_ifp from struct rt_addrinfo

2014-04-24 Thread Ryan McBride 
On Thu, Apr 24, 2014 at 06:25:59PM +0200, Henning Brauer wrote:
 * Alexander Bluhm alexander.bl...@gmx.net [2014-04-24 18:18]:
  The carp_setroute() function starts with the encouraging comment
  /* XXX this mess needs fixing */.
 
 I didn't change my mind at least :)
 1.136(henning  04-May-07):  /* XXX this mess needs fixing */
 
  When switching carp states fast,
  the routing table gets messed up.  In our product we removed all
  calls to carp_setroute(sc, RTM_DELETE).  There is one carp_setroute(sc,
  RTM_ADD) left.  I don't know wether it is needed.  I would recommend
  to try to delete the whole function and fix fallout if any.
 
 I tend towards that.
 ryan, marco?

I think I have not lookd at that code in nearly 10 years, I will need
more coffee. Maybe someone can summon the ghost of pasco@, as he did
most of the cleanup in the 3.5-3.6 series of major changes.

Part of the reason it's there is to make carp work properly for services
listening on the carp interface, in particular so that hosts in the
BACKUP state will reach the MASTER rather than trying and failing to
connect to their own carp interface. Maybe not needed in all setups, but
likely to break things if we simply remove it.

Re: rm -P

2012-07-28 Thread Ryan McBride 
I'm a bit late to the party, I know. But I just wanted to point out that
NIST now requires only the regular 'secure erase' ATA command to
sanitize a drive for anything that wouldn't require the drive to be
pitched into a metal shredder, pulverised, ground into powder, and then
melted into slag.

In other words, on modern hard drives, a single write with zeros is
probably enough. And if it isn't, the data shouldn't have been
unencrypted on the drive in the first place.

I'm opposed to adding more complication to this utility. I'd prefer that
it does it quickly and correctly, so that I will use it. The people who
want 35 overwrites won't trust the tool we provide anyways.


P.S.  An advantage of writing with zeros is that it's easy to verify
that the overwrite was done correctly. arc4random()... not so much.


On Wed, Jul 25, 2012 at 10:01:13AM -0500, Todd T. Fries wrote:
 Penned by Christian Weisgerber on 20120725  9:37.07, we have:
 | Ted Unangst t...@tedunangst.com wrote:
 | 
 |  So I'm wiping a file from a fairly slow USB stick and it's taking
 |  forever.  I don't really give a shit about some guy with a quantum
 |  tachyon microscope taking it apart,
 | 
 | But if you do, overwriting with a constant pattern is stupid.  You
 | want to overwrite the old data with random bytes, effectively running
 | a stream cipher on any remnant signal.
 | 
 | (And forget about this with flash media, where you each write to
 | the same logical block may end up in different physical blocks.)
 | 
 |  I just want the files to be gone
 |  enough that a simple undelete tool won't bring them back.  The three
 |  wipes is the charm approach of rm -P is a little heavy handed.
 |  
 |  What I propose is making -P wipe the file once each time it's
 |  provided.  I get the simple whack the data for good option I want, the
 |  paranoid weirdos get the rm `jot -b -P 4096` scrubber they want.
 | 
 | Replace the memset() in pass() with arc4random_buf() and I'm starting
 | to like it.
 
 There is a paper entitled Secure Deletion of Data from Magnetic and 
 Solid-State Memory
 from the Sixth (6th) Annual USENiX Security Symposium that talks about this.
 
 For the extreme bit twiddling bunch, the recommendation is to use 35 rounds.
 1-4 using /dev/arandom
 5-31 using Guttman's deterministic patterns
 32-35 using /dev/arandom again
 
 I've seen diffs proposed to do this in 'rm' before introduce another flag.
 
 I could easily see how we could do parts of the above until 35 -P's are given.
 
 Also, consider the ramdisks, and make -P become something that is not compiled
 `#ifdef SMALL'.
 
 One could, alternately, provide a 'secrm' alias to call some other tool to do
 the bit wiping and finally call rm.
 
 I won't complain what happens either way, but I would be rather pleased if 
 something
 of the Guttman's recommondations could be incorporated for high counts of -P.

Re: set { tos ..., prio ... }

2012-07-08 Thread Ryan McBride 
I agree with this. Others to consider:

- 'tag': we could then replace the nasty 'tagged' keyword with 'tag' and
  do proper 'tag != FOO' syntax.

- synproxy and modulate state - could go into 'scrub' also?



On Sat, Jul 07, 2012 at 07:24:23PM +0200, Henning Brauer wrote:
 so, we have some utter confusion in pf about filter criteria versus
 packet modifying options. I propose we move the ones that write into
 a set block, while the filter criteria remain as they are. for the
 moment this diff handles tos (I always disliked set-tos...) and prio.
 rdomain/rtable stuff should be done the same way (afterwards).
 no backwards compat for prio because i clearly stated it's not the
 final syntax all the time.
 
 no manpage bits yet.
 
 match set { prio 6, tos lowdelay }
 match set prio 6
 
 Index: sbin/pfctl/parse.y
 ===
 RCS file: /cvs/src/sbin/pfctl/parse.y,v
 retrieving revision 1.614
 diff -u -p -r1.614 parse.y
 --- sbin/pfctl/parse.y7 Jul 2012 16:24:32 -   1.614
 +++ sbin/pfctl/parse.y7 Jul 2012 17:09:19 -
 @@ -508,6 +508,7 @@ int   parseport(char *, struct range *r, i
  %typev.hfsc_opts   hfscopts_list hfscopts_item hfsc_opts
  %typev.queue_bwspecbandwidth
  %typev.filter_opts filter_opts filter_opt filter_opts_l
 +%typev.filter_opts filter_sets filter_set filter_sets_l
  %typev.antispoof_opts  antispoof_opts antispoof_opt 
 antispoof_opts_l
  %typev.queue_opts  queue_opts queue_opt queue_opts_l
  %typev.scrub_opts  scrub_opts scrub_opt scrub_opts_l
 @@ -979,7 +980,7 @@ scrub_opt : NODF  {
   scrub_opts.marker |= FOM_MAXMSS;
   scrub_opts.maxmss = $2;
   }
 - | SETTOS tos {
 + | SETTOS tos {  /* XXX remove in 5.4-current */
   if (scrub_opts.marker  FOM_SETTOS) {
   yyerror(set-tos cannot be respecified);
   YYERROR;
 @@ -2379,7 +2380,21 @@ filter_opt : USER uids {
   }
   filter_opts.rcv = $2;
   }
 - | prio {
 + | ONCE {
 + filter_opts.marker |= FOM_ONCE;
 + }
 + | filter_sets
 + ;
 +
 +filter_sets  : SET '{' filter_sets_l '}' { $$ = filter_opts; }
 + | SET filter_set{ $$ = filter_opts; }
 + ;
 +
 +filter_sets_l: filter_sets_l comma filter_set
 + | filter_set
 + ;
 +
 +filter_set   : prio {
   if (filter_opts.marker  FOM_SETPRIO) {
   yyerror(prio cannot be redefined);
   YYERROR;
 @@ -2388,8 +2403,13 @@ filter_opt : USER uids {
   filter_opts.set_prio[0] = $1.b1;
   filter_opts.set_prio[1] = $1.b2;
   }
 - | ONCE {
 - filter_opts.marker |= FOM_ONCE;
 + | TOS tos {
 + if (filter_opts.marker  FOM_SETTOS) {
 + yyerror(tos cannot be respecified);
 + YYERROR;
 + }
 + filter_opts.marker |= FOM_SETTOS;
 + filter_opts.settos = $2;
   }
   ;
  
 Index: sbin/pfctl/pfctl_parser.c
 ===
 RCS file: /cvs/src/sbin/pfctl/pfctl_parser.c,v
 retrieving revision 1.285
 diff -u -p -r1.285 pfctl_parser.c
 --- sbin/pfctl/pfctl_parser.c 7 Jul 2012 16:24:32 -   1.285
 +++ sbin/pfctl/pfctl_parser.c 7 Jul 2012 17:08:31 -
 @@ -843,6 +843,25 @@ print_rule(struct pf_rule *r, const char
   if (r-tos)
   printf( tos 0x%2.2x, r-tos);
  
 + if (r-set_prio[0] != PF_PRIO_NOTSET ||
 + r-scrub_flags  PFSTATE_SETTOS) {
 + char *comma = ;
 + printf( set {);
 + if (r-set_prio[0] != PF_PRIO_NOTSET) {
 + if (r-set_prio[0] == r-set_prio[1])
 + printf(%s prio %u, comma, r-set_prio[0]);
 + else
 + printf(%s prio(%u, %u), comma, r-set_prio[0],
 + r-set_prio[1]);
 + comma = ,;
 + }
 + if (r-scrub_flags  PFSTATE_SETTOS) {
 + printf(%s tos 0x%2.2x, comma, r-set_tos);
 + comma = ,;
 + }
 + printf( });
 + }
 +
   ropts = 0;
   if (r-max_states || r-max_src_nodes || r-max_src_states)
   ropts = 1;
 @@ -998,12 +1017,6 @@ print_rule(struct pf_rule *r, const char
   printf(min-ttl %d, r-min_ttl);
   ropts = 0;
   }
 -

Re: Small fixes for if_oerrors in vlan(4), mpe(4) and pppx

2011-08-20 Thread Ryan McBride 
committed, thanks!

On Sat, Aug 20, 2011 at 02:46:30AM -0300, Christiano F. Haesbaert wrote:
 Hi, vlan_start() was increasing packet counts before checking if the
 packet was successfully enqueued. I made a hunt for similar errors.
 
 Index: net/if_mpe.c
 ===
 RCS file: /cvs/src/sys/net/if_mpe.c,v
 retrieving revision 1.25
 diff -d -u -p -w -r1.25 if_mpe.c
 --- net/if_mpe.c  28 Jan 2011 14:58:24 -  1.25
 +++ net/if_mpe.c  20 Aug 2011 04:06:29 -
 @@ -265,7 +265,7 @@ mpeoutput(struct ifnet *ifp, struct mbuf
   if (error) {
   /* mbuf is already freed */
   splx(s);
 - return (error);
 + goto out;
   }
   if_start(ifp);
   splx(s);
 Index: net/if_pppx.c
 ===
 RCS file: /cvs/src/sys/net/if_pppx.c,v
 retrieving revision 1.9
 diff -d -u -p -w -r1.9 if_pppx.c
 --- net/if_pppx.c 7 Jul 2011 20:42:56 -   1.9
 +++ net/if_pppx.c 20 Aug 2011 05:37:48 -
 @@ -1057,6 +1057,10 @@ pppx_if_output(struct ifnet *ifp, struct
  
   s = splnet();
   IFQ_ENQUEUE(ifp-if_snd, m, NULL, error);
 + if (error) {
 + splx(s);
 + goto out;
 + }
   if_start(ifp);
   splx(s);
  
 Index: net/if_vlan.c
 ===
 RCS file: /cvs/src/sys/net/if_vlan.c,v
 retrieving revision 1.87
 diff -d -u -p -w -r1.87 if_vlan.c
 --- net/if_vlan.c 18 Feb 2011 17:06:45 -  1.87
 +++ net/if_vlan.c 20 Aug 2011 03:58:05 -
 @@ -251,15 +251,15 @@ vlan_start(struct ifnet *ifp)
* Send it, precisely as ether_output() would have.
* We are already running at splnet.
*/
 - p-if_obytes += m-m_pkthdr.len;
 - if (m-m_flags  M_MCAST)
 - p-if_omcasts++;
   IFQ_ENQUEUE(p-if_snd, m, NULL, error);
   if (error) {
   /* mbuf is already freed */
   ifp-if_oerrors++;
   continue;
   }
 + p-if_obytes += m-m_pkthdr.len;
 + if (m-m_flags  M_MCAST)
 + p-if_omcasts++;
  
   ifp-if_opackets++;
   if_start(p);

--

Re: recent change of nat-to behavior

2011-07-31 Thread Ryan McBride 
On Sun, Jul 31, 2011 at 02:04:35PM +0200, Peter N. M. Hansteen wrote:
 Ryan McBride mcbr...@openbsd.org writes:
  Please try a newer snapshot, this bug was fixed in the following commit:
 
 Latest snapshot (date Jul 31) still loads
 
 match out log on $ext_if inet nat-to ($ext_if)
 
 as 
 
 match out log on xl0 inet all nat-to (xl0) round-robin

This part of the behaviour is normal and has not changed (since the
commit below, I believe). On 4.9 I get the following:

i386-49$ echo pass out on egress nat-to (egress) | pfctl -vnf -
pass out on egress all flags S/SA keep state nat-to (egress) round-robin
i386-49$

The interface may have more than one address...


---
CVSROOT:/cvs
Module name:src
Changes by: mcbr...@cvs.openbsd.org 2010/01/11 20:20:52

Modified files:
libexec/tftp-proxy: filter.c
sbin/pfctl : parse.y pfctl.c pfctl_optimize.c pfctl_parser.c
 pfctl_parser.h pfctl_table.c
share/man/man4 : pf.4
share/man/man5 : pf.conf.5
sys/net: pf.c pf_if.c pf_ioctl.c pf_lb.c pf_table.c
 pfvar.h
usr.sbin/ftp-proxy: filter.c
usr.sbin/relayd: pfe_filter.c

Log message:
First pass at removing the 'pf_pool' mechanism for translation and routing
actions. Allow interfaces to be specified in special table entries for
the routing actions. Lists of addresses can now only be done using tables,
which pfctl will generate automatically from the existing syntax.

Functionally, this deprecates the use of multiple tables or dynamic
interfaces in a single nat or rdr rule.

ok henning dlg claudio
---

 but NATed traffic is handled correctly AFAICS.
 
 So you should consider this bug closeable.

Thanks for confirming that it's fixed.

Re: recent change of nat-to behavior

2011-07-31 Thread Ryan McBride 
On Sun, Jul 31, 2011 at 02:30:05PM +0200, Peter N. M. Hansteen wrote:
 Ryan McBride mcbr...@openbsd.org writes:
  The interface may have more than one address...
 
 That's probably just me not noticing, but the odd part is that while
 this interface has several addresses, it only has one IPv4 address:

The point of using a dynamic interface is to handle possible future
situations as well. So even if you only have one address now, how does
PF know that you'll never do ifconfig xl0 inet alias ...?

Basically, when you use ( ifname ), internally in PF it's handled as
a table that's managed by the kernel, and

1) pfctl has no idea what's in that table, so it has to assume that
   there might be multiple addresses
2) all tables get implicit round-robin load-balancing unless you specify
   something else (I think the only other valid option for tables at the
   moment is 'least-states')

Anyhow, the behaviour is the same as what you're expecting: round-robin
on a single address means you always get that address selected.

Re: recent change of nat-to behavior

2011-07-30 Thread Ryan McBride 
Please try a newer snapshot, this bug was fixed in the following commit:


CVSROOT:/cvs
Module name:src
Changes by: mcbr...@cvs.openbsd.org 2011/07/29 04:48:35

Modified files:
sys/net: pf_lb.c 

Log message:
Make sure we use the right tbl/dyn pointer to check the pfrkt_refcntcost;
improved debugging for error cases inside the weighted round-robin loop.

original diff from claudio, ok henning




On Sat, Jul 30, 2011 at 05:17:44PM +0200, Peter N. M. Hansteen wrote:
 I finally got around to upgrading my home gateway from 4.9-current
 (late snapshot) to 5.0-beta (jul 27 snapshot), and I stumbled across
 what appears to be a subtle but significant change in nat-to behavior.
 
 my $ext_if is
 
 xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 lladdr 00:50:da:21:cb:c9
 priority: 0
 groups: egress
 media: Ethernet autoselect (100baseTX full-duplex)
 status: active
 inet 213.187.179.198 netmask 0xfffc broadcast 213.187.179.199
 inet6 fe80::250:daff:fe21:cbc9%xl0 prefixlen 64 scopeid 0x3
 inet6 2001:16d8:ccbc:dead:beef::1 prefixlen 64
 
 and the nat-to line was
 
 match out log on $ext_if inet nat-to ($ext_if)
 
 AFter upgrading, this was loaded as 
 
 match out log on $ext_if inet nat-to $ext_addr round-robin
 
 - meaning that return traffic wasn't necessarily seen.
 
 Changing the rule to 
 
 match out log on $ext_if inet nat-to $ext_addr
 
 restored the config to a working state.
 
 Does this count as a buglet (or something that should be documented, at
 least)?
 
 - P
 
 -- 
 Peter N. M. Hansteen, member of the first RFC 1149 implementation team
 http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
 Remember to set the evil bit on all malicious network traffic
 delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
 

--

Do you use set reassemble off?

2011-07-05 Thread Ryan McBride 
If there is anyone out there who disables fragment reassembly (enabled
by default), you need to help testing this diff which folds
pf_test_fragment() into pf_test_rule().

If I don't hear from anyone we may one day decide that nobody actually
does this and remove the ability to disable reassembly completely...


Index: sys/net/if_pflog.c
===
RCS file: /cvs/src/sys/net/if_pflog.c,v
retrieving revision 1.35
diff -u -p -r1.35 if_pflog.c
--- sys/net/if_pflog.c  20 Jun 2011 19:03:41 -  1.35
+++ sys/net/if_pflog.c  6 Jul 2011 03:56:44 -
@@ -273,6 +273,7 @@ pflog_bpfcopy(const void *src_arg, void 
 {
const struct mbuf   *m;
struct pfloghdr *pfloghdr;
+   struct pf_state *s = NULL;
u_intcount;
u_char  *dst;
u_short  action, reason;
@@ -335,7 +336,7 @@ pflog_bpfcopy(const void *src_arg, void 
memset(pd, 0, sizeof(pd));
pd.hdr.any = pf_hdrs;
if (pf_setup_pdesc(pfloghdr-af, pfloghdr-dir, pd, mfake, action,
-   reason, NULL, NULL, NULL, NULL, off, hdrlen) == -1)
+   reason, NULL, NULL, NULL, s, NULL, off, hdrlen) == -1)
return;
 
PF_ACPY(osaddr, pd.src, pd.af);
Index: sys/net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.759
diff -u -p -r1.759 pf.c
--- sys/net/pf.c4 Jul 2011 18:12:51 -   1.759
+++ sys/net/pf.c6 Jul 2011 04:35:06 -
@@ -186,10 +186,6 @@ static __inline int pf_create_state(str
struct pf_rule_actions *, struct pf_src_node *[]);
 int pf_state_key_setup(struct pf_pdesc *, struct
pf_state_key **, struct pf_state_key **, int);
-int pf_test_fragment(struct pf_rule **, int,
-   struct pfi_kif *, struct mbuf *,
-   struct pf_pdesc *, struct pf_rule **,
-   struct pf_ruleset **);
 int pf_tcp_track_full(struct pf_state_peer *,
struct pf_state_peer *, struct pf_state **,
struct pfi_kif *, struct mbuf *, int,
@@ -1467,13 +1463,13 @@ pf_calc_skip_steps(struct pf_rulequeue *
if (cur-src.neg != prev-src.neg ||
pf_addr_wrap_neq(cur-src.addr, prev-src.addr))
PF_SET_SKIP_STEPS(PF_SKIP_SRC_ADDR);
+   if (cur-dst.neg != prev-dst.neg ||
+   pf_addr_wrap_neq(cur-dst.addr, prev-dst.addr))
+   PF_SET_SKIP_STEPS(PF_SKIP_DST_ADDR);
if (cur-src.port[0] != prev-src.port[0] ||
cur-src.port[1] != prev-src.port[1] ||
cur-src.port_op != prev-src.port_op)
PF_SET_SKIP_STEPS(PF_SKIP_SRC_PORT);
-   if (cur-dst.neg != prev-dst.neg ||
-   pf_addr_wrap_neq(cur-dst.addr, prev-dst.addr))
-   PF_SET_SKIP_STEPS(PF_SKIP_DST_ADDR);
if (cur-dst.port[0] != prev-dst.port[0] ||
cur-dst.port[1] != prev-dst.port[1] ||
cur-dst.port_op != prev-dst.port_op)
@@ -2719,6 +2715,14 @@ pf_rule_to_actions(struct pf_rule *r, st
PFSTATE_SETTOS|PFSTATE_SCRUB_TCP));
 }
 
+#define PF_TEST_ATTRIB(t, a)   \
+   do {\
+   if (t) {\
+   r = a;  \
+   goto nextrule;  \
+   }   \
+   } while (0)
+
 int
 pf_test_rule(struct pf_rule **rm, struct pf_state **sm, int direction,
 struct pfi_kif *kif, struct mbuf *m, int off,
@@ -2763,6 +2767,9 @@ pf_test_rule(struct pf_rule **rm, struct
return (PF_DROP);
}
 
+   if (pd-frag)
+   goto fragment;
+
switch (pd-proto) {
case IPPROTO_TCP:
pd-nsport = th-th_sport;
@@ -2803,7 +2810,8 @@ pf_test_rule(struct pf_rule **rm, struct
break;
 #endif /* INET6 */
default:
-   pd-nsport = pd-ndport;
+ fragment:
+   pd-nsport = pd-ndport = 0;
break;
}
 
@@ -2813,116 +2821,134 @@ pf_test_rule(struct pf_rule **rm, struct
r = TAILQ_FIRST(pf_main_ruleset.rules.active.ptr);
while (r != NULL) {
r-evaluations++;
-   if (pfi_kif_match(r-kif, kif) == r-ifnot)
-   r = r-skip[PF_SKIP_IFP].ptr;
-   else if (r-direction  r-direction != direction)
-   r = r-skip[PF_SKIP_DIR].ptr;
-   else if (r-onrdomain = 0  
-   (r-onrdomain == pd-rdomain) == r-ifnot)
-   r =

Re: Allegations regarding OpenBSD IPSEC

2010-12-30 Thread Ryan McBride 
On Thu, Dec 30, 2010 at 09:38:41AM +0100, Janne Johansson wrote:
  without a 'hint' (true or fake), where would you start auditing the
  code? It's just too much.
 
 Ted Unangst already solved that for all the potential lookers:
 
 Quote from http://marc.info/?l=openbsd-miscm=124413533913404w=2
 -
 It's not about where you start. It's about starting anywhere. Here, watch,
 it's this easy:
 find /usr/src -name *.c | random 1
 -

Note that this assumes that there is no backdoor in random(6) (or
arc4random_uniform, which it calls) designed to prevent the source file
with the backdoor from being selected with the above command.

Re: Allegations regarding OpenBSD's PRNG

2010-12-22 Thread Ryan McBride 
On Wed, Dec 22, 2010 at 10:44:48AM -0700, Kjell Wooding wrote:
 Oh good grief. Yes, ARC4 is being used to stretch a random source. Feel free
 to hunt for the distinguisher in the OpenBSD multi-consumer model. There's a
 good paper in there. If you can show a distinguisher (even without
 reseedings) with an equivalent number of consumers randomly pulling data
 from the stream, then you might  be able to tell us how long we should go
 between reseeding.

I agree that there's a good paper in this, I would love to see the
entropy added by the multi-consumer model quantified, or even an upper
bound placed on it.  In the past when I've given my talk on randomness
in the OpenBSD network stack, I've discussed this and I always ask for
someone to come forward with such a paper. 

Unfortunately I don't get the impression that the amateur cryptographers
questioning the OpenBSD PRNG are qualified to produce such a paper (if
they were, they wouldn't be mailing here, they'd be submitting it to
real cryptographers for peer review)

Re: mg + tinyscheme

2010-01-29 Thread Ryan McBride 
On Wed, Jan 27, 2010 at 09:19:21AM -0500, Ted Unangst wrote:
 So our choices are basically lisp or forth.  I
 assert without proof that forth is the wrong choice.

The first thing I thought when I saw your proposal was Cool. I should
add a Forth interpreter to ed(1).

/etc/pf.os update; anyone got fingerprints?

2009-10-19 Thread Ryan McBride 
I'd like to update the PF os fingerprints; I belive that others have
threatened on tech@ to do this, and I'd like to hear from them if they
have any partial diffs or collections of fingeerprints.

-Ryan

Re: pf_ioctl.c question

2009-10-04 Thread Ryan McBride 
I can't speak for everyone, but splitting the clauses of an if statement
with ifdefs makes my eyes bleed.

I would personally prefer to see these replaced with a switch statment,
as used elsewhere in PF; however this would probably need a goto that
points to the end of the main switch() statment to avoid insanely
complex costructs. Wait, that already exists...


switch (pp-af) {
#ifdef INET
case AF_INET:
break;
#endif / * INET */
#idfed INET6
case AF_INET6:
break;
#endif /* INET6 */
default:
error  = EAFNOSUPPORT;
goto fail;
}



On Sat, Oct 03, 2009 at 09:04:01PM +0400, Vadim Zhukov wrote:
 Hello all, especially network hackers.
 
 There are a few places in sys/net/pf_ioctl.c that look strange for me.
 They are like so:
 
 #ifndef INET
   if (pp-af == AF_INET) {
   error = EAFNOSUPPORT;
   break;
   }
 #endif /* INET */
 #ifndef INET6
   if (pp-af == AF_INET6) {
   error = EAFNOSUPPORT;
   break;
   }
 #endif /* INET6 */
 
 The problem is that newrule-af is not checked for anything except
 AF_INET and AF_INET6. I.e. any address family will be accepted by ioctl.
 It doesn't matter very much, because other routines will silently ignore
 unknown address families. But why report EAFNOTSUPPORT at all then?
 
 The sample patch is below (hope it will apply cleanly; I just extracted
 it from the another work doing now).