Re: v6 autoconf, where have my connected routes gone?

2015-08-20 Thread Sebastian Reitenbach 

On 08/19/15 17:51, Martin Pieuchot wrote:

On 18/08/15(Tue) 23:22, Martin Pieuchot wrote:

On 18/08/15(Tue) 14:00, Stuart Henderson wrote:

On 2015/08/18 14:27, Martin Pieuchot wrote:

On 18/08/15(Tue) 13:05, Stuart Henderson wrote:

I'm trying to add v6 to my second ISP connection on pppoe1, unlike my
first ISP, this one requires autoconf and dhcpv6-pd to pick up addresses
and have them routed. (They are referring to TR-187,
https://www.broadband-forum.org/technical/download/TR-187.pdf -
the residential gateway requirements are in section 6.1)

I haven't got as far as looking at dhcpv6-pd because when I enable
autoconf, as soon as it picks up the address I lose connected routes
to my local /64 subnets:


Which prefixes (ndp -p) and default routers (ndp -r) do you have before
and after the interface picks up the address?


Before: no default routers showing with ndp -r.

$ ndp -p | paste - - - | sed 's/vltime=infinity, pltime=infinity, expire=Never, 
//'
[...]
2001:4b10:1002:cc01::/64 if=vlan2   flags=LO ref=1No advertising router
... After:

$ ndp -r
[...]
2001:4b10:1002:cc01::/64 if=vlan2   flags=LD ref=1No advertising router


See how all your prefix suddenly became detached D?  That's a
limitation of pfxlist_onlink_check() which does not make a difference
between prefixes added to the global prefix list via an advertisement
or via manual configuration.

I'll see if it's possible to split the prefix lists in such way that
the RS/RA code only mess with its own states.


Diff below is just slightly tested and depends on the diff to
Kill IN6_IFF_NODAD but it shows where I'd like to go.

The idea is to use the global prefix list only for AUTOCONF'd addresses.

Since this list is only checked in nd6_is_addr_neighbor() I added a new
case for non-AUTOCONF'd addresses.  With it you should not longer see
the prefix of your manually configured interfaces in the ndp -p output
but it's ok since they should always be in your routing table.


That problem sthen@ describes here, sounds very similar to my home situation.
My router has IPv6 /48 HE tunnel, and on the wired network, i have /64 subnet
where all hosts have statically configured IPv6 addresses, incl. default route.
The router is also WLAN AP, where it has rtadvd running on the WLAN if,
and announcing a different /64 subnet.

Notebooks and other gear, that might have WLAN and network interfaces, when
connected to the wired network, and autoconf on the WLAN interface kicked in,
the IPv6 connection to the local /64 network were gone.

With the patch below, together with the other patch you mention above,
my problem is gone, network works as I expect it.

cheers,
Sebastian




diff --git sys/netinet6/in6.c sys/netinet6/in6.c
index 2f5d5a6..e9101dc 100644
--- sys/netinet6/in6.c
+++ sys/netinet6/in6.c
@@ -462,7 +462,6 @@ in6_control(struct socket *so, u_long cmd, caddr_t data, 
struct ifnet *ifp)

case SIOCAIFADDR_IN6:
{
-   struct nd_prefix *pr;
int plen, error = 0;

/* reject read-only flags */
@@ -509,40 +508,19 @@ in6_control(struct socket *so, u_long cmd, caddr_t data, 
struct ifnet *ifp)
if (ia6-ia6_flags  IN6_IFF_TENTATIVE)
nd6_dad_start(ia6-ia_ifa);

-
plen = in6_mask2len(ifra-ifra_prefixmask.sin6_addr, NULL);
if (plen == 128) {
dohooks(ifp-if_addrhooks, 0);
break;  /* we don't need to install a host route. */
}

-   /*
-* then, make the prefix on-link on the interface.
-* XXX: we'd rather create the prefix before the address, but
-* we need at least one address to install the corresponding
-* interface route, so we configure the address first.
-*/
-   pr = nd6_prefix_add(ifp, ifra-ifra_addr,
-   ifra-ifra_prefixmask, ifra-ifra_lifetime,
-   ((ifra-ifra_flags  IN6_IFF_AUTOCONF) != 0));
-   if (pr == NULL) {
-   log(LOG_ERR, cannot add prefix\n);
-   return (EINVAL); /* XXX panic here? */
-   }
-
-   /* relate the address to the prefix */
-   if (ia6-ia6_ndpr == NULL) {
-   ia6-ia6_ndpr = pr;
-   pr-ndpr_refcnt++;
+   error = rt_ifa_add(ia6-ia_ifa,
+   RTF_UP|RTF_CLONING|RTF_CONNECTED, ia6-ia_ifa.ifa_addr);
+   if (error) {
+   in6_purgeaddr(ia6-ia_ifa);
+   return (error);
}
-
s = splsoftnet();
-   /*
-* this might affect the status of autoconfigured addresses,
-* that is, this address might make other addresses detached.
-*/
-   pfxlist_onlink_check();
-
dohooks(ifp-if_addrhooks, 0);

Re: pkg_* new functionality: arch, version expansion

2015-04-16 Thread Sebastian Reitenbach 



Am 4/16/2015 um 12:03 PM schrieb Sebastian Reitenbach:



Am 4/15/2015 um 11:33 PM schrieb Marc Espie:

On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote:

I've seen at least -beta versions short before release locks. Not
sure if there are -alpha too? Those should be treated
same way as snapshots, I think.

This is the exact same logic that's in fw_update, actually...
so if one is wrong, the other one would be too ?



Well, when running pkg_add on a host that has version like X.X-beta, 
pkg_add

will expand %v to /X.X/ in the path. Usually at those time frames

I meant %c here that gets expanded in that case.

where there are -beta versions, such directories aren't on the mirrors 
(yet),

as far as I can see, pkg_add will fail then.
Just wondering, if is this intended? I also might be wrong ;)

Sebastian

Re: pkg_* new functionality: arch, version expansion

2015-04-16 Thread Sebastian Reitenbach 



Am 4/15/2015 um 11:33 PM schrieb Marc Espie:

On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote:

I've seen at least -beta versions short before release locks. Not
sure if there are -alpha too? Those should be treated
same way as snapshots, I think.

This is the exact same logic that's in fw_update, actually...
so if one is wrong, the other one would be too ?



Well, when running pkg_add on a host that has version like X.X-beta, 
pkg_add

will expand %v to /X.X/ in the path. Usually at those time frames
where there are -beta versions, such directories aren't on the mirrors 
(yet),

as far as I can see, pkg_add will fail then.
Just wondering, if is this intended? I also might be wrong ;)

Sebastian

Re: pkg_* new functionality: arch, version expansion

2015-04-15 Thread Sebastian Reitenbach 

On 04/15/15 17:56, Marc Espie wrote:

was requested by sthen@

works with pkg.conf and PKG_PATH, similar sequences as for dpb:

%a - architecture
%c - either snapshots or version number
%v - always version number.

please test/comment

just tried it after rewriting:

installpath = http://ftp.fr.openbsd.org/pub/OpenBSD/%c/packages/%a/

in pkg.conf

Index: OpenBSD/PackingElement.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackingElement.pm,v
retrieving revision 1.239
diff -u -p -r1.239 PackingElement.pm
--- OpenBSD/PackingElement.pm   25 Feb 2015 16:37:15 -  1.239
+++ OpenBSD/PackingElement.pm   15 Apr 2015 15:53:09 -
@@ -1750,6 +1750,15 @@ sub stringize($)

  my ($machine_arch, $arch);

+sub arch
+{
+   if (!defined $arch) {
+   my $cmd = OpenBSD::Paths-uname. -m;
+   chomp($arch = `$cmd`);
+   }
+   return $arch;
+}
+
  sub check
  {
my ($self, $forced_arch) = @_;
@@ -1768,11 +1777,7 @@ sub check
chomp($machine_arch = `$cmd`);
}
return 1 if $ok eq $machine_arch;
-   if (!defined $arch) {
-   my $cmd = OpenBSD::Paths-uname. -m;
-   chomp($arch = `$cmd`);
-   }
-   return 1 if $ok eq $arch;
+   return 1 if $ok eq arch();
}
return;
  }
Index: OpenBSD/PackageRepository/Installed.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository/Installed.pm,v
retrieving revision 1.29
diff -u -p -r1.29 Installed.pm
--- OpenBSD/PackageRepository/Installed.pm  15 Jun 2014 23:49:51 -  
1.29
+++ OpenBSD/PackageRepository/Installed.pm  15 Apr 2015 15:53:09 -
@@ -26,6 +26,40 @@ use warnings;

  package OpenBSD::PackageRepositoryBase;

+my ($version, $current);
+
+sub expand_locations
+{
+   my ($class, $string, $state) = @_;
+   if ($string eq '%a') {
+   require OpenBSD::PackingElement;
+   return OpenBSD::PackingElement::Arch::arch();
+   } else {
+   if (!defined $version) {
+   require OpenBSD::Paths;
+   open my $cmd, '-|',
+   OpenBSD::Paths-sysctl, '-n', 'kern.version';
+   my $line = $cmd;
+   close($cmd);
+   if ($line =~ m/^OpenBSD (\d\.\d)(\S*)\s/) {
+   $version = $1;
+   if ($2 eq '-current') {
+   $current = 'snapshots';


I've seen at least -beta versions short before release locks. Not
sure if there are -alpha too? Those should be treated
same way as snapshots, I think.



+   } else {
+   $current = $version;
+   }
+   } else {
+   $state-fatal(Can't figure out version);
+   }
+   }
+   if ($string eq '%c') {
+   return $current;
+   } else {
+   return $version;
+   }
+   }
+}
+
  sub parse_url
  {
my ($class, $r, $state) = @_;
@@ -40,6 +74,7 @@ sub parse_url
$$r = '';
}

+   $path =~ s/\%[vac]/$class-expand_locations($, $state)/ge;
$path .= '/' unless $path =~ m/\/$/;
bless { path = $path, state = $state }, $class;
  }

Re: diff: add tuning variables to config(8)

2014-06-16 Thread Sebastian Reitenbach 
 
On Monday, June 16, 2014 18:55 CEST, Miod Vallat m...@online.fr wrote: 
 
  Followings are our kernel variables' default:
  
- sb_max: 256K
- tcbhash_size: 128
- udbhash_size: 128
  
  These variables are sometime too small for busy server or gateway.
  
  I'd like to modify config(8) to customize these variables without
  recompiling the kernel. 
 
 If we go this route, I would rather have a generic command (such as set
 kernel variable name value) to change kernel variables.
 
 The list of said variables would still be restricted to what a given
 config(8) knows, to prevent people from tinkering with things they are
 not supposed to touch.

at least for sb_max I once sent a patch  to tech@ [1] to change it via sysctl, 
but
that was unfortunately rejected ;)
So, I'd still find it easier to change the sysctl than a changing it with 
config(8).
But on the other hand, sysctl might be too easy to use for $average user,
and making it only accessible via config(8) may prevent whining users.

cheers,
Sebastian


[1 ] https://groups.google.com/forum/#!topic/mailing.openbsd.tech/kMRT8VO2VaA

 
 Miod

Re: zskbd_device_lookup is not used anymore

2013-05-04 Thread Sebastian Reitenbach 
 
On Friday, May 3, 2013 17:16 CEST, Mike Belopuhov m...@belopuhov.com wrote: 
 
 hi,
 
 as far as i can tell these functions are not used anymore.

my sparcbook 3gx seems to be happy with it.

Sebastian

 
 ok?
 
 diff --git sys/arch/sparc/dev/z8530kbd.c sys/arch/sparc/dev/z8530kbd.c
 index 0a9c364..c746e56 100644
 --- sys/arch/sparc/dev/z8530kbd.c
 +++ sys/arch/sparc/dev/z8530kbd.c
 @@ -213,8 +213,6 @@ static void zs_modem(struct zskbd_softc *, int);
  static void zs_hwiflow(struct zskbd_softc *);
  static void zs_maskintr(struct zskbd_softc *);
  
 -struct zskbd_softc *zskbd_device_lookup(struct cfdriver *, int);
 -
  /* Low-level routines. */
  static void zskbd_rxint(struct zs_chanstate *);
  static void zskbd_stint(struct zs_chanstate *, int);
 @@ -240,14 +238,6 @@ struct wskbd_consops zskbd_consops = {
  
  #define  ZSKBDUNIT(x)(minor(x)  0x7)
  
 -struct zskbd_softc *
 -zskbd_device_lookup(cf, unit)
 - struct cfdriver *cf;
 - int unit;
 -{
 - return (struct zskbd_softc *)device_lookup(cf, unit);
 -}
 -
  /*
   * zskbd_match: how is this zs channel configured?
   */
 diff --git sys/arch/sparc64/dev/z8530kbd.c sys/arch/sparc64/dev/z8530kbd.c
 index e985544..1359964 100644
 --- sys/arch/sparc64/dev/z8530kbd.c
 +++ sys/arch/sparc64/dev/z8530kbd.c
 @@ -212,8 +212,6 @@ static void zs_modem(struct zskbd_softc *, int);
  static void zs_hwiflow(struct zskbd_softc *);
  static void zs_maskintr(struct zskbd_softc *);
  
 -struct zskbd_softc *zskbd_device_lookup(struct cfdriver *, int);
 -
  /* Low-level routines. */
  static void zskbd_rxint(struct zs_chanstate *);
  static void zskbd_stint(struct zs_chanstate *, int);
 @@ -239,14 +237,6 @@ struct wskbd_consops zskbd_consops = {
  
  #define  ZSKBDUNIT(x)(minor(x)  0x7)
  
 -struct zskbd_softc *
 -zskbd_device_lookup(cf, unit)
 - struct cfdriver *cf;
 - int unit;
 -{ 
 - return (struct zskbd_softc *)device_lookup(cf, unit);
 -}
 -
  /*
   * zskbd_match: how is this zs channel configured?
   */

Re: bind mountd to a specified port

2012-10-19 Thread Sebastian Reitenbach 
Am Donnerstag, 18. Oktober 2012 20:50 CEST, Bob Beck b...@obtuse.com schrieb: 
 
  Anyways, since in my case, I only need a read-only export, I can also go 
  with sharing the files via http.
  Both networks that are separated with the firewall, have about the same 
  trust level.
  So now someone could argue, why the hell a firewall in there at all, but 
  that's a different topic ;)
 
  So let me shut up and forget about it.
 
 Essentially at that point, allowing the RPC range in from your http
 servers to your read only NFS server across the firewall doesn't
 really have any different impact than doing it only with one port.
 More importantly, having the rules there saying for NFS export are a
 nice glaring thing reminding people about the why the hell have a
 firewall there at all issue so it could eventually be solved.
 
 Personally I've always done this with the read only nfs server
 *outside* sharing to the http servers, and an internal server that all
 the changes are made on, with a
 publish mechanism (script, or button that runs a script, or even a
 cron job) that rsync's changes from the internal server to the
 external server via ssh..
 
 You can then have a tiny little http server on the inside, visible
 only to the inside.  for your people to vet the changes before
 publishing them.
 
 Then you only need to allow ssh outbound to rsync the content out, and
 your firewall might do something meaningful :)

I did not really explained my use-case in the first place, which I probably
should do before I really shut up ;)

What I'm doing on the NFS server is mirroring installation sources for some 
Linux
distribution in order to have them locally available. In order to not have 
multiple
copies for each network, I need to make them somehow available there.
The firewall sits in the middle. My plan was to use export the drive read-only
into the other networks, nobody needs to write on it. 
For my use-case, I can also use http server to accomplish the same. 
Why NFS in the first place? Its the same way I do it on other places, 
but from a Linux server, therefore I had a bit of consistency in mind, 
and wanted to do it the same way here.
But as said, for my use case, I can also switch to http to get to the same
result.

thanks,
Sebastian

 
 -Bob

bind mountd to a specified port

2012-10-18 Thread Sebastian Reitenbach 
Hi,

getting NFS through a firewall is not that trivial with mountd binding to a 
random port each time it starts.
The patch below allows to specify a port which mountd will use.

The idea and the patch is not from me. 99% is based on an old patch submitted 
to tech@ in 2007:
http://old.nabble.com/-PATCH--mountd-to-listen-to-specified-port-td11075352.html
The patch did not got much attention at that time, hope for a bit more now ;)

Only one or two minor tweaks were necessary to bring it to compile without 
warnings.
Tested and works well for me on i386/amd64.

comments, rants or even test reports are welcome.

cheers,
Sebastian


Index: include/rpc/svc.h
===
RCS file: /cvs/src/include/rpc/svc.h,v
retrieving revision 1.12
diff -u -r1.12 svc.h
--- include/rpc/svc.h   1 Sep 2010 14:43:34 -   1.12
+++ include/rpc/svc.h   17 Oct 2012 10:33:06 -
@@ -305,6 +305,9 @@
 __BEGIN_DECLS
 extern SVCXPRT *svcudp_create(int);
 extern SVCXPRT *svcudp_bufcreate(int, unsigned int, unsigned int);
+extern SVCXPRT *svcudp_create2(int, int, u_short);
+extern SVCXPRT *svcudp_bufcreate2(int, int, u_short, unsigned int,
+   unsigned int);
 __END_DECLS
 
 
@@ -313,6 +316,7 @@
  */
 __BEGIN_DECLS
 extern SVCXPRT *svctcp_create(int, unsigned int, unsigned int);
+extern SVCXPRT *svctcp_create2(int, int, u_short, unsigned int, unsigned int);
 __END_DECLS
 
 /*
Index: lib/libc/rpc/rpc.3
===
RCS file: /cvs/src/lib/libc/rpc/rpc.3,v
retrieving revision 1.45
diff -u -r1.45 rpc.3
--- lib/libc/rpc/rpc.3  27 Sep 2012 11:31:58 -  1.45
+++ lib/libc/rpc/rpc.3  17 Oct 2012 10:33:11 -
@@ -52,7 +52,7 @@
 .\   NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 .\   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 .\
-.Dd $Mdocdate: September 27 2012 $
+.Dd $Mdocdate: October 15 2012 $
 .Dt RPC 3
 .Os
 .Sh NAME
@@ -109,8 +109,12 @@
 .Nm svcfd_create ,
 .Nm svcraw_create ,
 .Nm svctcp_create ,
+.Nm svctcp_create2 ,
 .Nm svcudp_create ,
 .Nm svcudp_bufcreate ,
+.Nm svcudp_bufcreate2 ,
+.Nm svcudp_create ,
+.Nm svcudp_create2 ,
 .Nm xdr_accepted_reply ,
 .Nm xdr_authunix_parms ,
 .Nm xdr_callhdr ,
@@ -234,11 +238,19 @@
 .Ft SVCXPRT *
 .Fn svctcp_create int sock u_int send_buf_size u_int recv_buf_size
 .Ft SVCXPRT *
+.Fn svctcp_create2 int sock int family u_short port u_int 
send_buf_size u_int recv_buf_size
+.Ft SVCXPRT *
 .Fn svcfd_create int fd u_int sendsize u_int recvsize
 .Ft SVCXPRT *
 .Fn svcudp_create int sock
 .Ft SVCXPRT *
 .Fn svcudp_bufcreate int sock u_int sendsz u_int recvsz
+.Ft SVCXPRT *
+.Fn svcudp_bufcreate2 int sock int family u_short port u_int sendsz 
u_int recvsz
+.Ft SVCXPRT *
+.Fn svcudp_create int sock
+.Ft SVCXPRT *
+.Fn svcudp_create2 int sock int family u_short port
 .Ft bool_t
 .Fn xdr_accepted_reply XDR *xdrs struct accepted_reply *ar
 .Ft bool_t
@@ -1096,6 +1108,13 @@
 users may specify the size of buffers; values of zero
 choose suitable defaults.
 .Pp
+.Fn svctcp_create2
+supersedes
+.Fn svctcp_create
+function. It allows to specify address family and port number also. This
+function accepts AF_INET and AF_INET6 address families. If port is equal to 0,
+the function tries to bind socket to one of reserved ports.
+.Pp
 .Fn svcfd_create
 will create a service on top of any open descriptor.
 Typically, this descriptor is a connected socket for a stream protocol such
@@ -1131,6 +1150,13 @@
 except that it allows the user to specify the maximum packet size for sending
 and receiving UDP-based RPC
 messages instead of using the default size limit of 8800 bytes.
+.Pp
+.Fn svcudp_bufcreate2
+supersedes
+.Fn svcudp_bufcreate
+function. It allows to specify address family and port number also. This
+function accepts AF_INET and AF_INET6 address families. If port is equal to 0,
+the function tries to bind socket to one of reserved ports.
 .Pp
 .Fn xdr_accepted_reply
 is used for encoding RPC reply messages.
Index: lib/libc/rpc/svc_tcp.c
===
RCS file: /cvs/src/lib/libc/rpc/svc_tcp.c,v
retrieving revision 1.30
diff -u -r1.30 svc_tcp.c
--- lib/libc/rpc/svc_tcp.c  1 Sep 2010 14:43:34 -   1.30
+++ lib/libc/rpc/svc_tcp.c  17 Oct 2012 10:33:12 -
@@ -136,7 +136,7 @@
 
if (sock == RPC_ANYSOCK) {
if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP))  0) {
-   perror(svctcp_.c - udp socket creation problem);
+   perror(svctcp_.c - tcp socket creation problem);
return (NULL);
}
madesock = TRUE;
@@ -186,6 +186,119 @@
return (NULL);
}
return (xprt);
+}
+
+/*
+ * This function creates sock (with specified adress family) if sock is -1.
+ * Then binds it to the specified port. It's possible to create v4 and v6
+ *

Re: bind mountd to a specified port

2012-10-18 Thread Sebastian Reitenbach 
Am Donnerstag, 18. Oktober 2012 19:17 CEST, Theo de Raadt 
dera...@cvs.openbsd.org schrieb: 
 
 As you note, this has come up before, and the same reasons exist then
 as now.
 
 The security model makes no sense: firewall, but allow NFS.

Yes, its not optimal ;)

Before with my search, I only found the one I pointed out, now I searched 
further, and I found the 
thread: 
http://old.nabble.com/mountd%3A-user-specified-port-td32147473.html#a32151940

reading up that, I see good points in the arguments from Christopher Zimmerman.

Anyways, since in my case, I only need a read-only export, I can also go with 
sharing the files via http.
Both networks that are separated with the firewall, have about the same trust 
level. 
So now someone could argue, why the hell a firewall in there at all, but that's 
a different topic ;)

So let me shut up and forget about it.

cheers,
Sebastian


 
  getting NFS through a firewall is not that trivial with mountd binding to a 
  random port each time it starts.
  The patch below allows to specify a port which mountd will use.
  
  The idea and the patch is not from me. 99% is based on an old patch 
  submitted to tech@ in 2007:
  http://old.nabble.com/-PATCH--mountd-to-listen-to-specified-port-td11075352.html
  The patch did not got much attention at that time, hope for a bit more now 
  ;)
  
  Only one or two minor tweaks were necessary to bring it to compile without 
  warnings.
  Tested and works well for me on i386/amd64.
  
  comments, rants or even test reports are welcome.
  
  cheers,
  Sebastian
  
  
  Index: include/rpc/svc.h
  ===
  RCS file: /cvs/src/include/rpc/svc.h,v
  retrieving revision 1.12
  diff -u -r1.12 svc.h
  --- include/rpc/svc.h   1 Sep 2010 14:43:34 -   1.12
  +++ include/rpc/svc.h   17 Oct 2012 10:33:06 -
  @@ -305,6 +305,9 @@
   __BEGIN_DECLS
   extern SVCXPRT *svcudp_create(int);
   extern SVCXPRT *svcudp_bufcreate(int, unsigned int, unsigned int);
  +extern SVCXPRT *svcudp_create2(int, int, u_short);
  +extern SVCXPRT *svcudp_bufcreate2(int, int, u_short, unsigned int,
  +   unsigned int);
   __END_DECLS
   
   
  @@ -313,6 +316,7 @@
*/
   __BEGIN_DECLS
   extern SVCXPRT *svctcp_create(int, unsigned int, unsigned int);
  +extern SVCXPRT *svctcp_create2(int, int, u_short, unsigned int, unsigned 
  int);
   __END_DECLS
   
   /*
  Index: lib/libc/rpc/rpc.3
  ===
  RCS file: /cvs/src/lib/libc/rpc/rpc.3,v
  retrieving revision 1.45
  diff -u -r1.45 rpc.3
  --- lib/libc/rpc/rpc.3  27 Sep 2012 11:31:58 -  1.45
  +++ lib/libc/rpc/rpc.3  17 Oct 2012 10:33:11 -
  @@ -52,7 +52,7 @@
   .\   NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
   .\   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
   .\
  -.Dd $Mdocdate: September 27 2012 $
  +.Dd $Mdocdate: October 15 2012 $
   .Dt RPC 3
   .Os
   .Sh NAME
  @@ -109,8 +109,12 @@
   .Nm svcfd_create ,
   .Nm svcraw_create ,
   .Nm svctcp_create ,
  +.Nm svctcp_create2 ,
   .Nm svcudp_create ,
   .Nm svcudp_bufcreate ,
  +.Nm svcudp_bufcreate2 ,
  +.Nm svcudp_create ,
  +.Nm svcudp_create2 ,
   .Nm xdr_accepted_reply ,
   .Nm xdr_authunix_parms ,
   .Nm xdr_callhdr ,
  @@ -234,11 +238,19 @@
   .Ft SVCXPRT *
   .Fn svctcp_create int sock u_int send_buf_size u_int recv_buf_size
   .Ft SVCXPRT *
  +.Fn svctcp_create2 int sock int family u_short port u_int 
  send_buf_size u_int recv_buf_size
  +.Ft SVCXPRT *
   .Fn svcfd_create int fd u_int sendsize u_int recvsize
   .Ft SVCXPRT *
   .Fn svcudp_create int sock
   .Ft SVCXPRT *
   .Fn svcudp_bufcreate int sock u_int sendsz u_int recvsz
  +.Ft SVCXPRT *
  +.Fn svcudp_bufcreate2 int sock int family u_short port u_int 
  sendsz u_int recvsz
  +.Ft SVCXPRT *
  +.Fn svcudp_create int sock
  +.Ft SVCXPRT *
  +.Fn svcudp_create2 int sock int family u_short port
   .Ft bool_t
   .Fn xdr_accepted_reply XDR *xdrs struct accepted_reply *ar
   .Ft bool_t
  @@ -1096,6 +1108,13 @@
   users may specify the size of buffers; values of zero
   choose suitable defaults.
   .Pp
  +.Fn svctcp_create2
  +supersedes
  +.Fn svctcp_create
  +function. It allows to specify address family and port number also. This
  +function accepts AF_INET and AF_INET6 address families. If port is equal 
  to 0,
  +the function tries to bind socket to one of reserved ports.
  +.Pp
   .Fn svcfd_create
   will create a service on top of any open descriptor.
   Typically, this descriptor is a connected socket for a stream protocol such
  @@ -1131,6 +1150,13 @@
   except that it allows the user to specify the maximum packet size for 
  sending
   and receiving UDP-based RPC
   messages instead of using the default size limit of 8800 bytes.
  +.Pp
  +.Fn svcudp_bufcreate2
  +supersedes
  +.Fn svcudp_bufcreate
  +function. It allows to specify address family and port number also. This
  +function

Re: diff: fix LCP keepalive failures on L2TP.

2012-01-31 Thread Sebastian Reitenbach 
On Tuesday, January 31, 2012 10:02 CET, Sebastian Reitenbach 
sebas...@l00-bugdead-prods.de wrote: 
 
 On Monday, January 30, 2012 15:43 CET, YASUOKA Masahiko yasu...@yasuoka.net 
 wrote: 
  
  On Mon, 30 Jan 2012 22:49:22 +0900 (JST)
  YASUOKA Masahiko yasu...@yasuoka.net wrote:
   pipex hook in udp_usrreq() mistakenly assumed that `inp' is
   connected.  The hook could not use the destination address properly,
   so it failed to find the pipex session.  This bug caused LCP keepalive
   failures on L2TP from client that does LCP keepalive and uses sequence
   number on the L2TP data channel (xl2tpd + pppd).
   
   The diff includes kernel header file changes.
   
   ok?
  
  Oops.  Let me update the diff.
  
  The given struct sockaddr object of
  pipex_l2tp_userland_lookup_session() became passed from the userland,
  so its address family must be checked.
  
  ok?
 
 tested IPSec/L2TP with xl2tpd, strongswan client. I did setup the tunnel 
 yesterday 
 evening, and its still alive this morning. Without the patch, the tunnel 
 usually died after
 a couple of minutes.
 
 So this definitely works for me, but I'm probably not the right guy to OK 
 that in this phase of 
 release cycle.
 
 I'll now try with Android phone, since I've seen the same problems with dying 
 tunnel too.

The tunnel established with Android 2.2, now also seems to be stable, at least 
for the last two hours and 15 minutes.
Prior to the patch, like with the Linux client, the tunnel died within a couple 
of minutes, maybe half an hour or hour.

However, I noted with tcpdump, listening on tun0:


# tcpdump -n -i tun0
tcpdump: listening on tun0, link-type LOOP
13:51:15.354776 
tcpdump: WARNING: compensating for unaligned libpcap packets
13:51:15.354795 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:16.334984 
13:51:16.334997 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:17.355463 
13:51:17.355474 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:18.375712 
13:51:18.375722 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:19.354994 
13:51:19.355004 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:20.375274 
13:51:20.375285 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:21.355354 
13:51:21.355364 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:22.334948 
13:51:22.334959 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:23.394820 
13:51:23.394831 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:24.374594 
13:51:24.374605 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:25.394998 
13:51:25.395009 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:26.394767 
13:51:26.394777 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:27.415028 
13:51:27.415039 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
13:51:28.375882 
13:51:28.375892 10.66.66.1  10.66.66.129: icmp: echo reply (DF)

Also when I show the contents with -X:


# tcpdump -n -i tun0 -s 2000 -X
tcpdump: listening on tun0, link-type LOOP
13:55:32.395223 
  : 4500 0054  4000 4001 a1a3 0a42 4281  E..T..@.@BB.
  0010: 0a42 4201 0800 6b54 6063 08bc 43e5 274f  .BB...kT`c..C.'O
  0020: c554 0800 0809 0a0b 0c0d 0e0f 1011 1213  .T..
  0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223   !#
  0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%'()*+,-./0123
  0050: 3435 36374567

tcpdump: WARNING: compensating for unaligned libpcap packets
13:55:32.395249 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
  : 8266 4000 ff01 603c 0a42 4201 0a42 4281  .f@...`.BB..BB.
  0010:  7354 6063 08bc 43e5 274f c554 0800  ..sT`c..C.'O.T..
  0020: 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617  
  0030: 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627   !#$%'
  0040: 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637  ()*+,-./01234567
  0050:  

13:55:34.315241 
  : 4500 0054  4000 4001 a1a3 0a42 4281  E..T..@.@BB.
  0010: 0a42 4201 0800 5e54 6063 08bd 44e5 274f  .BB...^T`c..D.'O
  0020: d153 0800 0809 0a0b 0c0d 0e0f 1011 1213  .S..
  0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223   !#
  0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%'()*+,-./0123
  0050: 3435 36374567

13:55:34.315253 10.66.66.1  10.66.66.129: icmp: echo reply (DF)
  : cd82 4000 ff01 1520 0a42 4201 0a42 4281  ..@ .BB..BB.
  0010:  6654 6063 08bd 44e5 274f d153 0800  ..fT`c..D.'O.S..
  0020: 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617  
  0030: 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627   !#$%'
  0040: 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637  ()*+,-./01234567
  0050:  

13:55:34.994293 
  : 4500 0054  4000 4001 a1a3 0a42 4281  E..T..@.@BB.
  0010: 0a42 4201 0800 8752 6063 08be 45e5 274f  .BBR`c..E.'O
  0020: a754 0800 0809 0a0b 0c0d 0e0f 1011 1213  .T..
  0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223

Re: diff: fix compiler warnings of npppd

2012-01-17 Thread Sebastian Reitenbach 
On Thursday, January 12, 2012 14:30 CET, YASUOKA Masahiko yasu...@yasuoka.net 
wrote: 
 
 This fixes many compiler warnings and some styles. 
 
 ok?

since I'm testing npppd to get mobile phone to run, I tested this diff.

The hunk to npppd/npppd_radius.c doesn't apply, seems to be already in the tree:

Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: npppd/npppd_radius.c
|===
|RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd_radius.c,v
|retrieving revision 1.1
|diff -u -p -r1.1 npppd_radius.c
|--- npppd/npppd_radius.c   6 Jul 2011 20:52:28 -   1.1
|+++ npppd/npppd_radius.c   15 Oct 2011 07:19:38 -
--
Patching file npppd/npppd_radius.c using Plan A...
Reversed (or previously applied) patch detected!  Assume -R? [y] n
Apply anyway? [n] 
Hunk #1 ignored at 120.
Hunk #2 ignored at 151.
Hunk #3 ignored at 198.
3 out of 3 hunks ignored--saving rejects to npppd/npppd_radius.c.rej

So ignoring this part, the rest applies well, and then compiling is also 
working like a charm, no warnings anymore.
tested on amd63

My OK may probably not count much here but you get it:  
OK sebastia@

cheers,
Sebastian

 
 Index: l2tp/l2tp.h
 ===
 RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tp.h,v
 retrieving revision 1.5
 diff -u -p -r1.5 l2tp.h
 --- l2tp/l2tp.h   15 Oct 2011 03:24:11 -  1.5
 +++ l2tp/l2tp.h   15 Oct 2011 07:19:35 -
 @@ -313,7 +313,7 @@ typedef struct _l2tpd {
   /** timeout event context */
   struct event ev_timeout;
   /** instance ID */
 - unsigned id;
 + u_int id;
   /** listener list */
   slist listener;
   /** state */
 @@ -347,7 +347,7 @@ typedef struct _l2tpd {
  typedef struct _l2tp_ctrl {
   struct event ev_timeout;
   /** ID */
 - unsigned id;
 + u_int id;
   /** parent L2TPD */
   l2tpd   *l2tpd;
   /** listener index number */
 @@ -425,7 +425,7 @@ typedef struct _l2tp_ctrl {
   */
  typedef struct _l2tp_call {
   /** ID */
 - unsignedid;
 + u_int   id;
   /** state */
   int state;
   /** parent control connection */
 @@ -475,10 +475,10 @@ void l2tpd_release_call (l2t
  int  l2tpd_start (l2tpd *);
  void l2tpd_stop (l2tpd *);
  void l2tpd_stop_immediatly (l2tpd *);
 -l2tp_ctrl*l2tpd_get_ctrl (l2tpd *, int);
 +l2tp_ctrl*l2tpd_get_ctrl (l2tpd *, u_int);
  void l2tpd_add_ctrl (l2tpd *, l2tp_ctrl *);
  void l2tpd_ctrl_finished_notify(l2tpd *);
 -void l2tpd_remove_ctrl (l2tpd *, int);
 +void l2tpd_remove_ctrl (l2tpd *, u_int);
  int  l2tpd_add_listener (l2tpd *, int, const char *, struct 
 sockaddr *);
  void l2tpd_log (l2tpd *, int, const char *, ...) 
 __attribute__((__format__ (__printf__, 3, 4)));
  
 Index: l2tp/l2tp_ctrl.c
 ===
 RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tp_ctrl.c,v
 retrieving revision 1.7
 diff -u -p -r1.7 l2tp_ctrl.c
 --- l2tp/l2tp_ctrl.c  15 Oct 2011 03:24:11 -  1.7
 +++ l2tp/l2tp_ctrl.c  15 Oct 2011 07:19:36 -
 @@ -93,7 +93,7 @@ static inline const char  *l2tp_ctrl_sta
  #endif
  
  /* Sequence # of l2tp_ctrl ID */
 -static unsigned l2tp_ctrl_id_seq = 0;
 +static u_int l2tp_ctrl_id_seq = 0;
  
  #define SEQ_LT(a,b)  ((int16_t)((a) - (b))   0)
  #define SEQ_GT(a,b)  ((int16_t)((a) - (b))   0)
 Index: l2tp/l2tp_subr.h
 ===
 RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tp_subr.h,v
 retrieving revision 1.3
 diff -u -p -r1.3 l2tp_subr.h
 --- l2tp/l2tp_subr.h  2 Jul 2010 21:20:57 -   1.3
 +++ l2tp/l2tp_subr.h  15 Oct 2011 07:19:36 -
 @@ -83,13 +83,13 @@ avp_set_val32(struct l2tp_avp *avp, uint
  static inline int
  short_cmp(const void *m, const void *n)
  {
 - return (int)((int)m - (int)n);
 + return ((intptr_t)m - (intptr_t)n);
  }
  
  static inline uint32_t
  short_hash(const void *v, int sz)
  {
 - return (int)v % sz;
 + return ((uintptr_t)v % sz);
  }
  
  /*
 Index: l2tp/l2tpd.c
 ===
 RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tpd.c,v
 retrieving revision 1.6
 diff -u -p -r1.6 l2tpd.c
 --- l2tp/l2tpd.c  16 Mar 2011 09:49:11 -  1.6
 +++ l2tp/l2tpd.c  15 Oct 2011 07:19:36 -
 @@ -80,7 +80,7 @@ static inline int   short_cmp (const
  static inline uint32_t  short_hash (const void *, int);
  
  /* sequence # of l2tpd ID */
 -static unsigned l2tpd_id_seq = 0;
 +static u_int l2tpd_id_seq = 0;
  
  #ifndef USE_LIBSOCKUTIL
  struct in_ipsec_sa_cookie{   };
 @@ -99,7 +99,8 @@ struct in_ipsec_sa_cookie   {   };
  int

fix ral (and maybe other cards) hostap mode

2012-01-16 Thread Sebastian Reitenbach 
Hi,

this is a followup on the misc@ problem with ral in hopstap mode on -current 
thread.

I had an AP running with a ral pci card in a soekris box with 4.2 for years.
About two weeks ago, I updated to -current. When the box is started, then the 
ral card
works fine as AP for a while, but then suddenly stops. To fix the problem I had 
to do a:

sh /etc/netstart ral0 on the AP, and wireless was back, working well, the 
clients could connect again.
While the clients were unable to connect, the card itself on the AP looked fine 
all the time:

$ ifconfig ral0
ral0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
lladdr 00:11:09:9a:9a:7e
priority: 4
groups: wlan
media: IEEE802.11 autoselect hostap (autoselect mode 11b hostap)
status: active
ieee80211: nwid brb.freifunk.net chan 1 bssid 00:11:09:9a:9a:7e 100dBm
inet 10.23.4.56 netmask 0x broadcast 10.23.255.255
inet6 fe80::211:9ff:fe9a:9a7e%ral0 prefixlen 64 scopeid 0x4

When the problem happened, I ran tcpdump -n -i ral0 -y IEEE802_11_RADIO -vvv, 
and saw the output below.

From some answers on misc@, others reported having seen similar problems 
starting to happen between 
4.6 and 4.7. Sthen@ suggested to me to revert revision 1.56 of 
src/sys/net80211/ieee80211_node.c
So I did.

Index: ieee80211_node.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
retrieving revision 1.63
diff -u -p -r1.63 ieee80211_node.c
--- ieee80211_node.c 28 Mar 2011 14:49:40 - 1.63
+++ ieee80211_node.c 13 Jan 2012 17:57:41 -
@@ -936,6 +936,7 @@ ieee80211_needs_rxnode(struct ieee80211c
  switch (wh-i_fc[0]  IEEE80211_FC0_SUBTYPE_MASK) {
  case IEEE80211_FC0_SUBTYPE_BEACON:
  case IEEE80211_FC0_SUBTYPE_PROBE_RESP:
+ rc = 1;
 break;
  default:
 #ifndef IEEE80211_STA_ONLY

So adding this rc=1 on Friday evening, now over the whole weekend, up to this 
morning, my wireless is working stable now,
as it was before with the 4.2. 

The commit log for the 1.56 revision was:

revision 1.56
date: 2010/02/17 18:34:37;  author: damien;  state: Exp;  lines: +1 -2
Do not always create a new node when a beacon or a probe response
is received.  The creation of a new node is already handled in
ieee80211_recv_probe_resp() when necessary.
This avoids creating empty nodes with wrong channels when beacons
are received on the wrong channel (overlapping channels).
Those empty nodes may also prevent the real node from being
discovered because of ieee80211_find_node_for_beacon() filtering.

This should prevent entries of the form:
nwid  chan 3 bssid 00:01:02:03:04:05 0dB 54M
in ifconfig if0 scan output, like reported by Rivo Nurges.


So the change will probably reintroduce the problem that the change was 
supposed to fix, and probably another different fix 
to my problem or the problem above is needed.

I don't know what the real fix could be, but I'm willing to test anything that 
gets thrown at me.
If more information is needed, let me know.

cheers,
Sebastian


OpenBSD 5.1-beta (GENERIC) #0: Fri Jan 13 19:40:36 CET 2012
sebastia@delta-flyer.ds9:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by National Semi (Geode by NSC 
586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
real mem  = 133754880 (127MB)
avail mem = 121548800 (115MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/40/21, BIOS32 rev. 0 @ 0xf7840
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0x9000
cpu0 at mainbus0: (uniprocessor)
cpu0: TSC disabled
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Cyrix GXm PCI rev 0x00
sis0 at pci0 dev 6 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 10, 
address 00:00:24:c3:89:1c
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci0 dev 7 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 10, 
address 00:00:24:c3:89:1d
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci0 dev 8 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 10, 
address 00:00:24:c3:89:1e
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
ral0 at pci0 dev 10 function 0 Ralink RT2560 rev 0x01: irq 11, address 
00:11:09:9a:9a:7e
ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525
gscpcib0 at pci0 dev 18 function 0 NS SC1100 ISA rev 0x00
gpio0 at gscpcib0: 64 pins
NS SC1100 SMI rev 0x00 at pci0 dev 18 function 1 not configured
pciide0 at pci0 dev 18 function 2 NS SCx200 IDE rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: SanDisk SDCFH-002G
wd0: 1-sector PIO, LBA, 1918MB, 3928176 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
geodesc0 at pci0 dev 18 function 5 NS SC1100 X-Bus rev 0x00: iid 6

Re: raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]

2011-12-25 Thread Sebastian Reitenbach 
Hi,

On Monday, December 5, 2011 10:53 CET, Sebastian Reitenbach 
sebas...@l00-bugdead-prods.de wrote: 
 
 On Sunday, December 4, 2011 21:01 CET, Mark Kettenis 
 mark.kette...@xs4all.nl wrote: 
  
   Date: Sun, 4 Dec 2011 15:10:56 +0100
   From: Claudio Jeker cje...@diehard.n-r-g.com
   
   On Sun, Dec 04, 2011 at 01:35:33PM +0100, Sebastian Reitenbach wrote:
On Sunday, December 4, 2011 13:24 CET, Camiel Dobbelaar 
c...@sentia.nl wrote: 
 
 On 4-12-2011 13:01, Sebastian Reitenbach wrote:
  the default maximum size of the tcp send and receive buffer used by 
  the autosizing algorithm is way too small, when trying to get 
  maximum speed with high bandwidth and high latency connections.
 
 I have tweaked SB_MAX on a system too, but it was for UDP.
 
 When running a busy Unbound resolver, the recommendation is too bump 
 the
 receive buffer to 4M or even 8M. See
 http://unbound.net/documentation/howto_optimise.html
 
 Otherwise a lot of queries are dropped when the cache is cold.
 
 I don't think there's a magic value that's right for everyone, so a
 sysctl would be nice.  Maybe separate ones for tcp and udp.
 
 I know similar sysctl's have been removed recently, and that they are
 sometimes abused, but I'd say we have two valid use cases now.
 
 So I'd love some more discussion.  :-)

since they were removed, and there is this keep it simple, and too many
knobs are bad attitude, which I think is not too bad, I just bumped the
SB_MAX value.
If there is consensus that a sysctl would make sense, I'd also look into
that approach and send new patch. 

   SB_MAX is there to protect your system. It gives a upperbound on how much
   memory a socket may allocate. The current value is a compromize. Running
   with a huge SB_MAX may make one connection faster but it will cause
   resource starvation issues on busy systems.
   Sure you can bump it but be aware of the consequneces (and it is why I
   think we should not bump it at the moment). A proper change needs to
   include some sort of resource management that ensures that we do not run
   the kernel out of memory.
  
  But 256k simply isn't enough for some use cases.  Turning this into a
  sysctl tunable like FreeBSD and NetBSD would be a good idea if you ask
  me.  Yes, people will use it to shoot themselves in the foot.  I don't
  care.
 
 So to be able to shoot myself in the foot without the need to compile the 
 kernel, I'll look into adding a sysctl to tweak the maximum size of the 
 buffer. Well, depending on time and how fast I figure out how to do that, 
 might take some time.

here is a first try to add such a sysctl. I called it net.inet.ip.sb-max. A 
better name, under a different hierarchy maybe?
The default value SB_MAX defined in sys/socketvar.h did not changed. I used 
sysctl_int for the sysctl, but not perfectly sure whether this is right? sb_max 
is u_long in sys/kern/uipc_socket2.c, so maybe using sysctl_quad? 
Tested and works for me on i386.

Its my first try in kernel land, and I'm no expert with regard to the network 
stack, so there may be things I should have done better. Please comment and let 
me know.

cheers,
Sebastian

Index: lib/libc/gen/sysctl.3
===
RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
retrieving revision 1.210
diff -u -r1.210 sysctl.3
--- lib/libc/gen/sysctl.3   9 Dec 2011 16:14:54 -   1.210
+++ lib/libc/gen/sysctl.3   25 Dec 2011 13:50:15 -
@@ -1210,6 +1210,7 @@
 .It ip Ta porthilast Ta integer Ta yes
 .It ip Ta portlast Ta integer Ta yes
 .It ip Ta redirect Ta integer Ta yes
+.It ip Ta sb-max Ta integer Ta yes
 .It ip Ta sourceroute Ta integer Ta yes
 .It ip Ta stats Ta structure Ta no
 .It ip Ta ttl Ta integer Ta yes
@@ -1517,6 +1518,9 @@
 .Tn IP
 packets,
 and should normally be enabled on all systems.
+.It Li ip.sb-max
+Maximum size of socket buffers. This value is also used by the TCP
+send and receive buffer autosizing algorithm.
 .It Li ip.sourceroute
 Returns 1 when forwarding of source-routed packets is enabled for
 the host.
Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.162
diff -u -r1.162 sysctl.8
--- sbin/sysctl/sysctl.83 Sep 2011 22:59:08 -   1.162
+++ sbin/sysctl/sysctl.825 Dec 2011 13:50:54 -
@@ -228,6 +228,7 @@
 .It net.inet.ip.porthilast Ta integer Ta yes
 .It net.inet.ip.maxqueue Ta integer Ta yes
 .It net.inet.ip.encdebug Ta integer Ta yes
+.It net.inet.ip.sb-max Ta integer Ta yes
 .It net.inet.ip.ipsec-expire-acquire Ta integer Ta yes
 .It net.inet.ip.ipsec-invalid-life Ta integer Ta yes
 .It net.inet.ip.ipsec-pfs Ta integer Ta yes
Index: sys/kern/uipc_socket2.c
===
RCS file: /cvs/src/sys/kern

Re: raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]

2011-12-05 Thread Sebastian Reitenbach 
On Sunday, December 4, 2011 21:01 CET, Mark Kettenis mark.kette...@xs4all.nl 
wrote: 
 
  Date: Sun, 4 Dec 2011 15:10:56 +0100
  From: Claudio Jeker cje...@diehard.n-r-g.com
  
  On Sun, Dec 04, 2011 at 01:35:33PM +0100, Sebastian Reitenbach wrote:
   On Sunday, December 4, 2011 13:24 CET, Camiel Dobbelaar c...@sentia.nl 
   wrote: 

On 4-12-2011 13:01, Sebastian Reitenbach wrote:
 the default maximum size of the tcp send and receive buffer used by 
 the autosizing algorithm is way too small, when trying to get maximum 
 speed with high bandwidth and high latency connections.

I have tweaked SB_MAX on a system too, but it was for UDP.

When running a busy Unbound resolver, the recommendation is too bump the
receive buffer to 4M or even 8M. See
http://unbound.net/documentation/howto_optimise.html

Otherwise a lot of queries are dropped when the cache is cold.

I don't think there's a magic value that's right for everyone, so a
sysctl would be nice.  Maybe separate ones for tcp and udp.

I know similar sysctl's have been removed recently, and that they are
sometimes abused, but I'd say we have two valid use cases now.

So I'd love some more discussion.  :-)
   
   since they were removed, and there is this keep it simple, and too many
   knobs are bad attitude, which I think is not too bad, I just bumped the
   SB_MAX value.
   If there is consensus that a sysctl would make sense, I'd also look into
   that approach and send new patch. 
   
  SB_MAX is there to protect your system. It gives a upperbound on how much
  memory a socket may allocate. The current value is a compromize. Running
  with a huge SB_MAX may make one connection faster but it will cause
  resource starvation issues on busy systems.
  Sure you can bump it but be aware of the consequneces (and it is why I
  think we should not bump it at the moment). A proper change needs to
  include some sort of resource management that ensures that we do not run
  the kernel out of memory.
 
 But 256k simply isn't enough for some use cases.  Turning this into a
 sysctl tunable like FreeBSD and NetBSD would be a good idea if you ask
 me.  Yes, people will use it to shoot themselves in the foot.  I don't
 care.

So to be able to shoot myself in the foot without the need to compile the 
kernel, I'll look into adding a sysctl to tweak the maximum size of the buffer. 
Well, depending on time and how fast I figure out how to do that, might take 
some time.

Sebastian

raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]

2011-12-04 Thread Sebastian Reitenbach 
Hi,

the default maximum size of the tcp send and receive buffer used by the 
autosizing algorithm is way too small, when trying to get maximum speed with 
high bandwidth and high latency connections.

I tested to get the best speed with a connection between Germany and Canada, 
ping times around 180ms.
On the site in Germany, I have 155MBit Internet uplink, but the card in the 
test box, only negotiated 100MBit, so actually 100MBit uplink to the Internet. 
(Why it only negotiated 100MBit, is not the topic here...)
On the site in Canada, I have even more than 155MBit Internet uplink.

The maximum size of the buffer is defined in sys/sys/socketvar.h:

#define SB_MAX (256*1024)

With this value, I got download speeds, downloading on the Canadian box from 
the host in Germany, average of about 1.5MB/s, which is definitely not optimal.

Doubling the value (512*1024), I got average speeds around 2.5-3MB/s.
Doubling the value again to (1024*1024) I got average speeds of about 5-6MB/s.
Doubling the value again to (2048*1024) I got average speeds of about 8MB/s.

On the same box in Germany, I had a second harddisk with Linux OpenSUSE 11.2 
installed. There, even with tweaking the buffers, I never got more than 4 MB/s 
average transfer speed. But that may be because I did not found the right 
values to use.

The tcp buffer autosizing algorithm is at the end of sys/netinet/usrreq.c.
As far as I understand the comments and the code right, it should be safe to 
raise the value.
The buffer size is scaled up and down, depending on its fill level, and if the 
receiver can ack
packets in a given time. Also, in case of low memory, the buffer is reset to 
small value.
Therefore I think it should also be safe on busy servers with many connections 
on high speed LANs.
But since I'm by far not a network stack expert, I might missing something.

so the patch raises SB_MAX to (2048*1024) which seemed to be the best for my 
use case so far. I also tested higher values, but that did not gained me 
anything. I did not found a good network card that has gigabit, and good 
transfer rates, so I was unable to utilize the full 155MBit on my side here in 
Germany. so the value I propose might still be too small for even faster 
connections.

so please test, comment, or even OK?

cheers,
Sebastian

Index: sys/sys/socketvar.h
===
RCS file: /cvs/src/sys/sys/socketvar.h,v
retrieving revision 1.50
diff -u -r1.50 socketvar.h
--- sys/sys/socketvar.h 4 Jul 2011 22:53:53 -   1.50
+++ sys/sys/socketvar.h 4 Dec 2011 11:29:58 -
@@ -104,7 +104,7 @@
short   sb_flags;   /* flags, see below */
u_short sb_timeo;   /* timeout for read/write */
} so_rcv, so_snd;
-#defineSB_MAX  (256*1024)  /* default for max chars in 
sockbuf */
+#defineSB_MAX  (2048*1024) /* default for max chars in 
sockbuf */
 #defineSB_LOCK 0x01/* lock on data queue */
 #defineSB_WANT 0x02/* someone is waiting to lock */
 #defineSB_WAIT 0x04/* someone is waiting for 
data/space */

Re: raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]

2011-12-04 Thread Sebastian Reitenbach 
On Sunday, December 4, 2011 13:24 CET, Camiel Dobbelaar c...@sentia.nl wrote: 
 
 On 4-12-2011 13:01, Sebastian Reitenbach wrote:
  the default maximum size of the tcp send and receive buffer used by the 
  autosizing algorithm is way too small, when trying to get maximum speed 
  with high bandwidth and high latency connections.
 
 I have tweaked SB_MAX on a system too, but it was for UDP.
 
 When running a busy Unbound resolver, the recommendation is too bump the
 receive buffer to 4M or even 8M. See
 http://unbound.net/documentation/howto_optimise.html
 
 Otherwise a lot of queries are dropped when the cache is cold.
 
 I don't think there's a magic value that's right for everyone, so a
 sysctl would be nice.  Maybe separate ones for tcp and udp.
 
 I know similar sysctl's have been removed recently, and that they are
 sometimes abused, but I'd say we have two valid use cases now.
 
 So I'd love some more discussion.  :-)

since they were removed, and there is this keep it simple, and too many knobs 
are bad attitude, which I think is not too bad, I just bumped the SB_MAX value.
If there is consensus that a sysctl would make sense, I'd also look into that 
approach and send new patch. 


Sebastian

 
 --
 Cam

Re: document ldapd schema files

2010-11-05 Thread Sebastian Reitenbach 
On Thursday, November 4, 2010 21:32 CET, Theo de Raadt 
dera...@cvs.openbsd.org wrote: 
 
  On second thought, I should answer with a little less snark, though I
  think this one attribute sums it up pretty well.
  
  First, some committee sat around and tried to come up with all the
  things needed to describe a person, like license plates and pager
  numbers and who your secretary is.  It's like it's custom built for
  handling the personnel records of IBM management.  They made all this
  nonsense optional thankfully, but who's to say there aren't other
  attributes you need to store in your organization?  Now you're off
  making your own schema.  Adios interop!
  
  Second, the file formats seem purpose designed to be incomprehensible.
  
  Third, just doing something as simple as putting a single user record
  into the db using ldapadd involved an insane amount of typing of magic
  incantations.  This is not entirely the tool's fault, there's just so
  much stuff involved it bubbles up to the user whether they like it
  or not.
  
  On the whole, infinite flexibility is pretty much synonymous with
  infinite complexity.
 
 not enough axe murderers.
 
 note to axe murderers: ietf and other such organizations are purposely
 weak at checking badges at their events, because who would want to go
 to them?  use this to your advangage.  the people attending these
 meetings are generally pretty unfit and move slowly, so you don't need
 a large, long handled axe -- something small will do.
 
 
 
I like that, and probably worth a fortune cookie, starting with a dedicated 
cookie file just for theo! 
OK? ;)


cheers,
Sebastian 

Index: Makefile
===
RCS file: /cvs/src/games/fortune/datfiles/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile26 Sep 2003 03:08:44 -  1.6
+++ Makefile5 Nov 2010 07:23:58 -
@@ -2,9 +2,9 @@
 #  $NetBSD: Makefile,v 1.15 1996/02/29 00:21:16 jtc Exp $
 #  @(#)Makefile8.2 (Berkeley) 4/19/94
 
-SRCS=  fortunes fortunes2 startrek zippy recipes
+SRCS=  fortunes fortunes2 startrek zippy recipes theo
 BLDS=  fortunes.dat fortunes2.dat startrek.dat zippy.dat \
-   fortunes-o fortunes-o.dat recipes.dat
+   fortunes-o fortunes-o.dat recipes.dat theo.dat
 
 # TO INSTALL THE POTENTIALLY OFFENSIVE FORTUNES, UNCOMMENT THE THREE
 # LINES AND COMMENT OUT THE FOURTH LINE.
@@ -31,7 +31,7 @@
${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m 444 ${BLDS} \
${DESTDIR}/usr/share/games/fortune
 
-fortunes.dat fortunes2.dat fortunes2-o.dat limerick.dat startrek.dat zippy.dat 
recipes.dat:
+fortunes.dat fortunes2.dat fortunes2-o.dat limerick.dat startrek.dat zippy.dat 
recipes.dat theo.dat:
${STRFILE} -rs ${.CURDIR}/${.TARGET:R} ${.TARGET}
 
 fortunes-o.dat: fortunes-o
Index: theo
===
RCS file: theo
diff -N theo
--- /dev/null   1 Jan 1970 00:00:00 -
+++ theo5 Nov 2010 07:23:58 -
@@ -0,0 +1,8 @@
+note to axe murderers: ietf and other such organizations are purposely
+weak at checking badges at their events, because who would want to go
+to them?  use this to your advangage.  the people attending these
+meetings are generally pretty unfit and move slowly, so you don't need
+a large, long handled axe -- something small will do.
+
+Theo de Raadt on tech@ answering the thread: document ldapd schema files
+

Re: patch to add RequestHeader directive to httpd mod_headers.c

2010-09-23 Thread Sebastian Reitenbach 
On Wednesday 22 September 2010 11:19:28 pm Landry Breuil wrote:
 On Wed, Sep 22, 2010 at 05:20:04PM +0200, Sebastian Reitenbach wrote:
  Alexander Hall wrote:
   I don't have any actual interest in the change myself, nor the time to
   test it, but now at least the diff has the fixes I expected to see
   regarding my prior concerns.
 
  Anyone else who would test or comment on this one?
  Tested so far by me: telnetting to apache, and see what comes back, so
  the old headers still seem to work for me. Tested the new RequestHeader
  directive in conjunction with mod_proxy configured as reverse proxy.
  Have seen with tcpdump that the headers were sent to the application
  server.

 I've read the diff and i see nothing wrong with it. I suppose you tried
 all set/append/add/unset actions ?
Thanks, and yes, all four work for me as documented, for all three header 
types.


Sebastian


 Can someone more confident in userland doublecheck and okay it ?

 Landry

Re: patch to add RequestHeader directive to httpd mod_headers.c

2010-09-13 Thread Sebastian Reitenbach 
Hi,

thanks for taking a look.

On Sunday 12 September 2010 09:33:44 pm you wrote:
 On 09/12/10 18:20, Sebastian Reitenbach wrote:
  -table *tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);
  +table *tbl;
  +switch (hdr-inout) {
  +case hdrs_out:
  +  tbl = r-headers_out;
  +  break;
  +case hdrs_in:
  +  tbl = r-headers_in;
  +  break;
  +}
  +tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);

 Err... Set tbl above and then set it again?
Ah, after looking at it again, I see. Will provide sth. new when I'm back 
home.


 Also, what's with the indentation?
ugh. yes. will fix that too.


   switch (hdr-action) {
   case hdr_add:
   ap_table_addn(tbl, hdr-header, hdr-value);

Sebastian

Re: patch to add RequestHeader directive to httpd mod_headers.c

2010-09-13 Thread Sebastian Reitenbach 

Hi,

attached a new revision of the patch. Please comment, and let me know 
whether its OK to add or still sth. wrong.


thanks,
Sebastian

Alexander Hall wrote:
 On 09/12/10 18:20, Sebastian Reitenbach wrote:

 -table *tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);
 +table *tbl;
 +switch (hdr-inout) {
 +case hdrs_out:
 +  tbl = r-headers_out;
 +  break;
 +case hdrs_in:
 +  tbl = r-headers_in;
 +  break;
 +}
 +tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);

 Err... Set tbl above and then set it again?

 Also, what's with the indentation?

  switch (hdr-action) {
  case hdr_add:
  ap_table_addn(tbl, hdr-header, hdr-value);






Index: mod_headers.c
===
RCS file: /cvs/src/usr.sbin/httpd/src/modules/standard/mod_headers.c,v
retrieving revision 1.8
diff -u -r1.8 mod_headers.c
--- mod_headers.c21 Aug 2003 13:11:36 -1.8
+++ mod_headers.c13 Sep 2010 16:15:01 -
@@ -59,13 +59,19 @@
/*
 * mod_headers.c: Add/append/remove HTTP response headers
 * Written by Paul Sutton, p...@ukweb.com, 1 Oct 1996
+ * Updated with RequestHeader by Martin Algesten,
+ *   puck...@taglab.com, 13 Jul 2002.
 *
 * New directive, Header, can be used to add/replace/remove HTTP headers.
 * Valid in both per-server and per-dir configurations.
+ * In addition directive, RequestHeader, can be used exactly as Header but
+ * with the difference that the header is added to the request headers 
rather

+ * than the response.
 *
 * Syntax is:
 *
- *   Header action header value
+ *   Headeraction header value
+ *   RequestHeader action header value
 *
 * Where action is one of:
 * set- set this header, replacing any old value
@@ -77,7 +83,7 @@
 * Where action is unset, the third argument (value) should not be given.
 * The header name can include the colon, or not.
 *
- * The Header directive can only be used where allowed by the FileInfo
+ * The directives can only be used where allowed by the FileInfo
 * override.
 *
 * When the request is processed, the header directives are processed in
@@ -112,7 +118,15 @@
hdr_unset = 'u' /* unset header */
} hdr_actions;

+
+typedef enum {
+hdrs_in  = 'i', /* Add header to incoming (request) 
headers */
+hdrs_out = 'o'  /* Add header to outgoing (response) 
headers */

+} hdrs_inout;
+
+
typedef struct {
+hdrs_inout inout;
hdr_actions action;
char *header;
char *value;
@@ -154,7 +168,7 @@
return a;
}

-static const char *header_cmd(cmd_parms *cmd, headers_conf * dirconf, 
char *action, char *hdr, char *value)
+static const char *header_cmd(cmd_parms *cmd, headers_conf * dirconf, 
char *action, char *hdr, char *value, hdrs_inout inout )

{
header_entry *new;
server_rec *s = cmd-server;
@@ -175,6 +189,8 @@
new-do_err = 0;
}

+new-inout = inout;
+
if (!strcasecmp(action, set))
new-action = hdr_set;
else if (!strcasecmp(action, add))
@@ -202,11 +218,23 @@
return NULL;
}

+static const char *outheader_cmd(cmd_parms *cmd, headers_conf * 
dirconf, char *action, char *hdr, char *value)

+{
+header_cmd( cmd, dirconf, action, hdr, value, hdrs_out );
+}
+
+static const char *inheader_cmd(cmd_parms *cmd, headers_conf * dirconf, 
char *action, char *hdr, char *value)

+{
+header_cmd( cmd, dirconf, action, hdr, value, hdrs_in );
+}
+
static const command_rec headers_cmds[] =
{
-{Header, header_cmd, (void *)0, OR_FILEINFO, TAKE23,
+{Header, outheader_cmd, NULL, OR_FILEINFO, TAKE23,
+ an action, header and value},
+{RequestHeader, inheader_cmd, NULL, OR_FILEINFO, TAKE23,
 an action, header and value},
-{ErrorHeader, header_cmd, (void *)1, OR_FILEINFO, TAKE23,
+{ErrorHeader, outheader_cmd, (void *)1, OR_FILEINFO, TAKE23,
 an action, header and value},
{NULL}
};
@@ -217,7 +245,15 @@

for (i = 0; i  headers-nelts; ++i) {
header_entry *hdr = ((header_entry *) (headers-elts))[i];
-table *tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);
+table *tbl;
+switch (hdr-inout) {
+case hdrs_out:
+tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);
+break;
+case hdrs_in:
+tbl = r-headers_in;
+break;
+}
switch (hdr-action) {
case hdr_add:
ap_table_addn(tbl, hdr-header, hdr-value);

Re: patch to add RequestHeader directive to httpd mod_headers.c

2010-09-13 Thread Sebastian Reitenbach 
Again,

as I was pointed out the patch was borked, and actually documentation missing, 
here is a new one, including the documentation.

Sebastian 

On Monday, September 13, 2010 18:26 CEST, Sebastian Reitenbach 
sebas...@l00-bugdead-prods.de wrote: 
 
 Hi,
 
 attached a new revision of the patch. Please comment, and let me know 
 whether its OK to add or still sth. wrong.
 
 thanks,
 Sebastian
 
 Alexander Hall wrote:
   On 09/12/10 18:20, Sebastian Reitenbach wrote:
  
   -table *tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);
   +table *tbl;
   +switch (hdr-inout) {
   +case hdrs_out:
   +  tbl = r-headers_out;
   +  break;
   +case hdrs_in:
   +  tbl = r-headers_in;
   +  break;
   +}
   +tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);
  
   Err... Set tbl above and then set it again?
  
   Also, what's with the indentation?
  
switch (hdr-action) {
case hdr_add:
ap_table_addn(tbl, hdr-header, hdr-value);
  
  
Index: src/modules/standard/mod_headers.c
===
RCS file: /cvs/src/usr.sbin/httpd/src/modules/standard/mod_headers.c,v
retrieving revision 1.8
diff -u -r1.8 mod_headers.c
--- src/modules/standard/mod_headers.c  21 Aug 2003 13:11:36 -  1.8
+++ src/modules/standard/mod_headers.c  13 Sep 2010 17:45:35 -
@@ -59,13 +59,19 @@
 /*
  * mod_headers.c: Add/append/remove HTTP response headers
  * Written by Paul Sutton, p...@ukweb.com, 1 Oct 1996
+ * Updated with RequestHeader by Martin Algesten,
+ *   puck...@taglab.com, 13 Jul 2002.
  *
  * New directive, Header, can be used to add/replace/remove HTTP headers.
  * Valid in both per-server and per-dir configurations.
+ * In addition directive, RequestHeader, can be used exactly as Header but
+ * with the difference that the header is added to the request headers rather
+ * than the response.
  *
  * Syntax is:
  *
- *   Header action header value
+ *   Headeraction header value
+ *   RequestHeader action header value
  *
  * Where action is one of:
  * set- set this header, replacing any old value
@@ -77,7 +83,7 @@
  * Where action is unset, the third argument (value) should not be given.
  * The header name can include the colon, or not.
  *
- * The Header directive can only be used where allowed by the FileInfo 
+ * The directives can only be used where allowed by the FileInfo 
  * override.
  *
  * When the request is processed, the header directives are processed in
@@ -112,7 +118,15 @@
 hdr_unset = 'u' /* unset header */
 } hdr_actions;
 
+
+typedef enum {
+hdrs_in  = 'i', /* Add header to incoming (request) headers */
+hdrs_out = 'o'  /* Add header to outgoing (response) headers */
+} hdrs_inout;
+
+
 typedef struct {
+hdrs_inout inout;
 hdr_actions action;
 char *header;
 char *value;
@@ -154,7 +168,7 @@
 return a;
 }
 
-static const char *header_cmd(cmd_parms *cmd, headers_conf * dirconf, char 
*action, char *hdr, char *value)
+static const char *header_cmd(cmd_parms *cmd, headers_conf * dirconf, char 
*action, char *hdr, char *value, hdrs_inout inout )
 {
 header_entry *new;
 server_rec *s = cmd-server;
@@ -175,6 +189,8 @@
new-do_err = 0;
 }
 
+new-inout = inout;
+
 if (!strcasecmp(action, set))
 new-action = hdr_set;
 else if (!strcasecmp(action, add))
@@ -202,11 +218,23 @@
 return NULL;
 }
 
+static const char *outheader_cmd(cmd_parms *cmd, headers_conf * dirconf, char 
*action, char *hdr, char *value)
+{
+header_cmd( cmd, dirconf, action, hdr, value, hdrs_out );
+}
+
+static const char *inheader_cmd(cmd_parms *cmd, headers_conf * dirconf, char 
*action, char *hdr, char *value)
+{
+header_cmd( cmd, dirconf, action, hdr, value, hdrs_in );
+}
+
 static const command_rec headers_cmds[] =
 {
-{Header, header_cmd, (void *)0, OR_FILEINFO, TAKE23,
+{Header, outheader_cmd, NULL, OR_FILEINFO, TAKE23,
+ an action, header and value},
+{RequestHeader, inheader_cmd, NULL, OR_FILEINFO, TAKE23,
  an action, header and value},
-{ErrorHeader, header_cmd, (void *)1, OR_FILEINFO, TAKE23,
+{ErrorHeader, outheader_cmd, (void *)1, OR_FILEINFO, TAKE23,
  an action, header and value},
 {NULL}
 };
@@ -217,7 +245,15 @@
 
 for (i = 0; i  headers-nelts; ++i) {
 header_entry *hdr = ((header_entry *) (headers-elts))[i];
-   table *tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);
+table *tbl;
+switch (hdr-inout) {
+case hdrs_out:
+tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);
+break;
+case hdrs_in:
+tbl = r-headers_in;
+break;
+}
 switch (hdr-action) {
 case hdr_add:
 ap_table_addn(tbl, hdr-header, hdr-value);
Index: htdocs/manual/mod/mod_headers.html

patch to add RequestHeader directive to httpd mod_headers.c

2010-09-12 Thread Sebastian Reitenbach 

Hi,

my first time I submit a patch which not goes to the ports.

I have a web based groupware port in the queue, that would benefit from 
the patch below. The patch is against mod_headers.c and adds handling of
RequestHeader directive in the apache configuration, in order to 
manipulate the request header instead of the header.


The patch is based one the one I found here:
http://mail-archives.apache.org/mod_mbox/httpd-bugs/200207.mbox/%3c20020713122353.23227.qm...@nagoya.betaversion.org%3e
There are only some style changes, and at the end some small tweaks, 
since the original patch was against a mod_headers.c file unaware of 
ErrorHeader.


Without this patch, it would be necessary to use apache2 from ports.
Patch tested to compile and works for me as expected on i386.

Is this sth. that can go in, needs some tweaks, more testing, or is a 
stupid idea? Any comment welcome.



cheers,
Sebastian

? mod_headers.c.save
Index: mod_headers.c
===
RCS file: /cvs/src/usr.sbin/httpd/src/modules/standard/mod_headers.c,v
retrieving revision 1.8
diff -u -r1.8 mod_headers.c
--- mod_headers.c   21 Aug 2003 13:11:36 -  1.8
+++ mod_headers.c   12 Sep 2010 15:36:01 -
@@ -59,13 +59,19 @@
 /*
  * mod_headers.c: Add/append/remove HTTP response headers
  * Written by Paul Sutton, p...@ukweb.com, 1 Oct 1996
+ * Updated with RequestHeader by Martin Algesten,
+ *   puck...@taglab.com, 13 Jul 2002.
  *
  * New directive, Header, can be used to add/replace/remove HTTP headers.
  * Valid in both per-server and per-dir configurations.
+ * In addition directive, RequestHeader, can be used exactly as Header but
+ * with the difference that the header is added to the request headers 
rather

+ * than the response.
  *
  * Syntax is:
  *
- *   Header action header value
+ *   Headeraction header value
+ *   RequestHeader action header value
  *
  * Where action is one of:
  * set- set this header, replacing any old value
@@ -77,7 +83,7 @@
  * Where action is unset, the third argument (value) should not be given.
  * The header name can include the colon, or not.
  *
- * The Header directive can only be used where allowed by the FileInfo
+ * The directives can only be used where allowed by the FileInfo
  * override.
  *
  * When the request is processed, the header directives are processed in
@@ -112,7 +118,15 @@
 hdr_unset = 'u' /* unset header */
 } hdr_actions;

+
+typedef enum {
+hdrs_in  = 'i', /* Add header to incoming (request) 
headers */
+hdrs_out = 'o'  /* Add header to outgoing (response) 
headers */

+} hdrs_inout;
+
+
 typedef struct {
+hdrs_inout inout;
 hdr_actions action;
 char *header;
 char *value;
@@ -154,7 +168,7 @@
 return a;
 }

-static const char *header_cmd(cmd_parms *cmd, headers_conf * dirconf, 
char *action, char *hdr, char *value)
+static const char *header_cmd(cmd_parms *cmd, headers_conf * dirconf, 
char *action, char *hdr, char *value, hdrs_inout inout )

 {
 header_entry *new;
 server_rec *s = cmd-server;
@@ -175,6 +189,8 @@
new-do_err = 0;
 }

+new-inout = inout;
+
 if (!strcasecmp(action, set))
 new-action = hdr_set;
 else if (!strcasecmp(action, add))
@@ -202,9 +218,21 @@
 return NULL;
 }

+static const char *outheader_cmd(cmd_parms *cmd, headers_conf * 
dirconf, char *action, char *hdr, char *value)

+{
+header_cmd( cmd, dirconf, action, hdr, value, hdrs_out );
+}
+
+static const char *inheader_cmd(cmd_parms *cmd, headers_conf * dirconf, 
char *action, char *hdr, char *value)

+{
+header_cmd( cmd, dirconf, action, hdr, value, hdrs_in );
+}
+
 static const command_rec headers_cmds[] =
 {
-{Header, header_cmd, (void *)0, OR_FILEINFO, TAKE23,
+{Header, outheader_cmd, NULL, OR_FILEINFO, TAKE23,
+ an action, header and value},
+{RequestHeader, inheader_cmd, NULL, OR_FILEINFO, TAKE23,
  an action, header and value},
 {ErrorHeader, header_cmd, (void *)1, OR_FILEINFO, TAKE23,
  an action, header and value},
@@ -217,7 +245,16 @@

 for (i = 0; i  headers-nelts; ++i) {
 header_entry *hdr = ((header_entry *) (headers-elts))[i];
-   table *tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);
+   table *tbl;
+   switch (hdr-inout) {
+   case hdrs_out:
+ tbl = r-headers_out;
+ break;
+   case hdrs_in:
+ tbl = r-headers_in;
+ break;
+   }
+   tbl = (hdr-do_err ? r-err_headers_out : r-headers_out);
 switch (hdr-action) {
 case hdr_add:
 ap_table_addn(tbl, hdr-header, hdr-value);

Re: shared libs and ports, maybe a proposal

2010-07-08 Thread Sebastian Reitenbach 
On Thursday 08 July 2010 02:03:41 pm Matthieu Herrb wrote:
 On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote:
  each time xenocara farts, we get new libs (or less libs).
  in order for updates to work, we *should* propagate those changes to
  @wantlib in each port.

 For the base and xenocara libs, wouldn't it make sense to have some
 modules centralizing the version info (and even some dependencicies) so
 that instead of WANTLIB declaratons you coud have

 .include libX11.dep.mk
 .include libc.dep.mk

 or something similar?

 Then only one central fil would need to be updated when revisions changes.
 And even if libX11 gains new depencies, you would not be reqired to
 add the manually to a zillon of ports's Makefiles.

And that would maybe allow to have ARCH dependent stuff in those files to 
handle availability libs on different archs, i.e. at least VAX doesn't have 
pthread-stubs and xcb, don't know about others.

cheers,
Sebastian