Zaphod Beeblebrox | 23 Oct 06:08 2014

IPv6 provisioning for a FreeBSD ISP.

Besides the fact that the ngX interfaces appear to have a quirk (or maybe
it's mpd5 or quagga) where remote hosts can't talk to services residing on
the ngX host, A FreeBSD machine with mpd5 and quagga that talk to
freeradius and PostgreSQL serves as a really nice small ISP package.

I already support ipv6 for many users (and have, for some time) using
static gif tunnels.  This works, but it is annoyingly suboptimal.

Now my ISP doesn't allocate addresses from a pool.  I don't care that
people effectively have static addresses.  managing the addresses isn't
difficult and the average user is nailed up more than 98% of the time.  So
I assign a static IPv4 address in PostgreSQL.  Freeradius reads this and
sends it to mpd5 --- which hands out the static addresses ... and even
routed ipv4 netblocks via ipcp (or ipv4cp).

IPv6 works over my pppoe<-->l2tp links.  I can set static addresses on the
ngX connections at both ends, The traffic is passed.  What stops me from
implementing this is the equivalent of the
PostgreSQL->freeradius->mpd5->ipcp communication of the addresses and
settings.  mpd5 doesn't seem to have any builtin handling of the ipv6
addresses and I don't see what other solution will properly hand out static
addresses (and routed networks).

How is this supposed to go together?  DHCP6 doesn't seem to acknowledge
that the user has already logged in via l2tp/ppp.  rtsold doesn't seem to
address static addressing.
freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"
(Continue reading)

Outback Dingo | 23 Oct 01:05 2014

Launchd ported / released to the wilds for FreeBSD

A working port of Launchd to FreeBSD has been released and can be found on

We have also supplied the codebase to the openlaunchd efforts.

Its a but dated but does still work on 8/9/10 and CURRENT.

freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"

Julian H. Stacey | 21 Oct 16:51 2014

DOC obstructs encryption export again - Non USA crypto base again ?

How can FreeBSD best re-segregate crypto components of its repository again,
ready to move crypto components outside the USA, as USA DOC imperils again ?

FreeBSD is now SVN based, we were CVS last time,  Any new issues to solve  ?
Can smooth transition be planned before, in case of risk of USA DOC action ?

Last time FreeBSD used South Africa; if that's not viable, 
FreeBSD based servers elsewhere are available (including in .EU).
    "US government fines Intel's Wind River over crypto exports"

    "Now, as Techdirt notes, the conflict between government
    regulation and the tech industry is moving onto the renal
    original turf of the first crypto wars of the late 90s - the
    export of strong encryption."

    "For those who lived through the late 90's cryptowars, it's
    beginning to feel like history is repeating itself."
    "maybe the decision to keep GnuPG infrastructure out of the US
    - even after the lifting of the export restrictions - was not too bad."

USA Dept. of Commerce were obstructive idiots even back in the early 1980s: 
  (DOC obstructed delivery of Unix systems with crypt binary (not
  source), though British Unix source licencees, associates, &
  even the communist East were all in possesion of crypt.c source
(Continue reading)

Willem Jan Withagen | 19 Oct 00:39 2014

tip has -n and cu not


is there any particular reason why tip has the -n flag to disable escape
handeling, but cu does not?

Reason for the question:
Looking for a way to get external access to bhyve consoles connected to
I'd like to use cu as "shell" to make it possible to give user access to
a /dev/nmdmXXXB port thru ssh. And this is the only thing that user is
able to do.... And without the -n flag, cu allows all kinds of nasty
escape tricks.

freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"

Jonathan de Boyne Pollard | 19 Oct 02:52 2014

nosh version 1.9

nosh version 1.9 is out.  If you've not heard of it, here's the blurb:


If you also read the worked example, make sure that you read all of the 
way to the bottom.  (-:  If you want to read more, there's a whole Guide 
in the package, and lots of manual pages.

There's now a command for converting FreeBSD /etc/rc.conf{,.local} 
preset information (the *_enable variables) to service bundle preset 
information.  For kicks, I've also added a small shim for the OpenBSD 
"rcctl" command that they're busy inventing.  It's worth noting that 
OpenBSD 5.6 now specifies that /etc/rc.conf{,.local} doesn't have shell 
expansions and isn't necessarily sourced by a shell, which is change 
that I welcome with open arms.  I will be looking at conversion of 
OpenBSD *_flags variables; but the big thing that remains in this area 
is a utility that pushes all of the other variables, apart from 
*_enable, into envdirs in the appropriate service bundles, which is 
going to be a tedious one-by-one slog because sometimes the variable 
names don't match the service names, as you no doubt know.

I set myself a task of converting to service bundles all but two of the 
157 non-target scripts that I found in a stock FreeBSD /etc/rc.d/ .  
I've reached 85.  A lot of the remaining scripts are complex, often 
one-shot, shell scripts onto the side of which the rc.d start/stop 
system has been bolted, with varying degrees of success.  If you are 
interested in helping, one of the things that would help greatly is 
factoring out the meat of some of these into helper commands of some 
kind, reducing the lopsided hulks to something more like (say) 
/etc/rc.d/rpcbind .  (I can supply a list.)  As reciprocal payment in 
(Continue reading)

Konstantin Belousov | 18 Oct 18:53 2014

Re: Fwd: Questions with the in_cksumdata() function in sys/amd64/amd64/in_cksum.c

On Sat, Oct 18, 2014 at 07:29:12AM -0400, John Baldwin wrote:
> Do you have any thoughts on this?  On modern Intel CPUs with the hardware 
> prefetcher this would seem to be a waste, so I wonder how useful this is
> in practice.
I would be not surprised if this manual prefetching by explicit reads
causes slowdown of the function.  I suspect it could confuse hardware
prefetcher by breaking the linear pattern, or the patch could break
the logic of the limited forward-looking oracle by reading too far
from the current linear read tip.

Also, it could confuse the data flow engine if the register allocator
is unable to see that the read value is needed not right now, and cause
unneeded stall while next cache line is fetched.

Sure, all my speculations are pure garbage until confirmed by
measurements with pmc, but I think that the patch below must be
benchmarked to confirm any value it provides as well. My opinion is,
we should either remove the manual prefetch, or do it with PREFETCHLX
instructions only, instead of real read.

> ----------  Forwarded Message  ----------
> Subject: Questions with the in_cksumdata() function in 
> sys/amd64/amd64/in_cksum.c
> Date: Friday, September 26, 2014, 10:51:36 PM
> From: btw <at>
> To: freebsd-hackers <freebsd-hackers <at>>
> Hi All,
(Continue reading)

Jeremie Le Hen | 17 Oct 00:15 2014

struct bintime


I need to get microseconds from a struct bintime.  I found
bintime2timeval() in sys/time.h which more or less does this, but I
don't understand how the computation works.

Can someone explain it to me please?

static __inline void
bintime2timeval(const struct bintime *_bt, struct timeval *_tv)

        _tv->tv_sec = _bt->sec;
        _tv->tv_usec = ((uint64_t)1000000 * (uint32_t)(_bt->frac >> 32)) >> 32;


Jeremie Le Hen
jlh <at>
freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"

Wojciech Puchar | 16 Oct 14:19 2014

help with backlight control and memory

bought new laptop. it's lenovo B590

most things works fine. but brightness control keys doesn't work after 
FreeBSD is loaded. they work before it.

i don't ask for a solution but any point to start. What should i check?

is it ACPI tables problem (kernel shows some errors).

Other question - can amount of memory dedicated to GFX card be changed? 
There is no option in BIOS setup to do this. and i have lots of memory 
wasted as you may see below.

Copyright (c) 1992-2014 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.1-BETA1 #4: Wed Oct 15 23:56:56 CEST 2014
     root <at> laptop:/usr/src/sys/amd64/compile/laptop amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: Intel(R) Celeron(R) CPU 1005M  <at>  1.90GHz (1895.73-MHz K8-class CPU)
   Origin = "GenuineIntel"  Id = 0x306a9  Family = 0x6  Model = 0x3a  Stepping = 9
   AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
   AMD Features2=0x1<LAHF>
   Structured Extended Features=0x281<FSGSBASE,SMEP,ERMS>
   TSC: P-state invariant, performance statistics
real memory  = 2147483648 (2048 MB)
(Continue reading)

Matthias Apitz | 13 Oct 11:20 2014

gmake && file time precision of 1 second


I have a large project where a shell script fires up
gmake runs in subdirs as:

for dir in src norm print ....; do 
   cd $dir
   cd ..

in each subdir *.c are compiled to *.o and the resulting *.o are ar'ed
into all the same lib.a; based on normal Makefile rules like:

SRCS = f1.c f2.c
OBJS = $(SRCS:.c=.o)

	$(CC) -c ... $*.c

lib.a:: $(OBJS)
	$(AR) $ <at>  $(OBJS)

after moving to a faster server it turned out that gmake sometimes forget
to ar the *.o into the lib; I investigated it and it turned out that the
*.o files have the same modification time (in seconds) as the target
lib.a (which was produced/updated in the last directory worked on) and
gmake thinks that the lib.a is uptodate.

(Continue reading)

Michael W. Lucas | 10 Oct 23:58 2014

GBDE not protecting the user

[Tried questions <at> , no answer, and the code contains things I just
cannot trigger.]


Been playing with GBDE a while, trying to make it protect me.

One of the features of GBDE is that it should "provide tangible
feedback" that the data has been destroyed. (See PHK's paper at, section 4.1.)

The man page doesn't mention how to make GBDE whine, so what the heck,
let's make it tell me the keys are destroyed.

Creating GBDE devices is very simple.

# gbde init /dev/gpt/encrypted -L /etc/encrypted.lock

I created a filesystem, mounted it, put files on it, unmounted.

There's two operations to wipe out a GBDE: nuke and destroy. Nuke
looks like the right thing. I nuke all the keys:

# gbde nuke gpt/encrypted -l /etc/encrypted.lock -n -1
Enter passphrase:
Opened with key 0
Nuked key 0
Nuked key 1
Nuked key 2
Nuked key 3
(Continue reading)

Navdeep Parhar | 10 Oct 23:08 2014

panic in ivy_rng_store() when compiled with -O0

I built my kernel + modules (head as of today) with -O0 and now it 
panics during boot.  I did bump up KSTACK_PAGES significantly so that's 
not the problem.  I'm going to take out the RNG device next and see if I 
can get past this.


Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer	= 0x20:0xffffffff814ac661
stack pointer	        = 0x28:0xfffffe01ed6c6930
frame pointer	        = 0x28:0xfffffe01ed6c6960
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 14 (rand_harvestq)
[ thread pid 14 tid 100017 ]
Stopped at      ivy_rng_store+0x31:     movq    %rdi,(%rdi)
db> bt
Tracing pid 14 tid 100017 td 0xfffff800042c84c0
ivy_rng_store() at ivy_rng_store+0x31/frame 0xfffffe01ed6c6960
random_ivy_read() at random_ivy_read+0x78/frame 0xfffffe01ed6c6990
live_entropy_sources_feed() at live_entropy_sources_feed+0x73/frame 
random_kthread() at random_kthread+0x224/frame 0xfffffe01ed6c6a30
fork_exit() at fork_exit+0x14a/frame 0xfffffe01ed6c6ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01ed6c6ab0
--- trap 0, rip = 0, rsp = 0xfffffe01ed6c6b70, rbp = 0 ---
(Continue reading)