Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 18:31, Glen Barber wrote: > On Sun, Sep 08, 2013 at 11:00:24AM +0200, Dag-Erling Smørgrav wrote: >> Glen Barber writes: >>> The correct workaround (which now I see I should have done before >>> locking head/) is to revert this commit so it can be properly fixed. >> >> Glen, to be fair, the mips boot fails because they're trying to use a >> device before it's ready. > > To be clear, when I sent my last emails, tinderbox was complaining about > build failures (which it did not catch up to the recent head/ > revisions), so at the time I thought head/ was still broken for > arm and mips architectures. > > Sorry for the misunderstanding on my part. delphij corrected me on > this. No worries, thanks! Keep up the good work! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On Sun, Sep 08, 2013 at 11:00:24AM +0200, Dag-Erling Smørgrav wrote: > Glen Barber writes: > > The correct workaround (which now I see I should have done before > > locking head/) is to revert this commit so it can be properly fixed. > > Glen, to be fair, the mips boot fails because they're trying to use a > device before it's ready. To be clear, when I sent my last emails, tinderbox was complaining about build failures (which it did not catch up to the recent head/ revisions), so at the time I thought head/ was still broken for arm and mips architectures. Sorry for the misunderstanding on my part. delphij corrected me on this. Glen pgpx0TW6Ib31m.pgp Description: PGP signature
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 01:31, Glen Barber wrote: > On Sat, Sep 07, 2013 at 05:27:19PM -0700, Adrian Chadd wrote: >> ok. So I can work around this for these MIPS AP images by echoing something >> into /dev/random ? >> > > The correct workaround (which now I see I should have done before > locking head/) is to revert this commit so it can be properly fixed. > > Calling "echo '' >/dev/random" the "KNOB" is insulting. Using a write to /dev/random as a reseed was there from day one (check random(4)), and while it is not the clearest thing on the planet that a reseed unblocks the device, that has always been there by intent. That is how etc/rc.d/initrandom is supposed to work. In checking the man page I've released that connection needs to be clarified. I've (re)set the "seeded" bit, so behaviour is as it was. I'll look for a way to set this bit from the kernel config file. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 01:36, Glen Barber wrote: > Either way, I think this commit needs to be reverted until properly > fixed and tested. The hyperbole is getting a little thick. How about sysctl kern.random.sys.seeded=1 ?? M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
Glen Barber writes:
> The correct workaround (which now I see I should have done before
> locking head/) is to revert this commit so it can be properly fixed.
Glen, to be fair, the mips boot fails because they're trying to use a
device before it's ready. It just so happens that this device is
implemented entirely in software, not in hardware, but it's no different
from trying to read from an empty optical drive. The only thing that
has changed, in practical terms, is that previously if they tried to
read from an empty drive (to continue the analogy) we'd nod and smile
and feed them zeroes, whereas now we wait for someone to insert a disc.
So Mark didn't really break anything here (apart from the build breakage
which has already been fixed), he just made an existing bug visible.
And he's already reverted the *one* line of code that did this, so mips
is now almost as broken as it was before (only almost, because the first
commit also fixed some serious harvesting / entropy estimation bugs).
Anyway, on platforms that support tunables, this should help:
Index: sys/dev/random/randomdev_soft.c
===
--- sys/dev/random/randomdev_soft.c (revision 255371)
+++ sys/dev/random/randomdev_soft.c (working copy)
@@ -102,6 +102,8 @@
#endif
+TUNABLE_INT("kern.random.sys.seeded", &random_context.seeded);
+
/* List for the dynamic sysctls */
static struct sysctl_ctx_list random_clist;
On platforms that don't, we need to figure out a better solution;
possibly Pawel's early harvesting patch, which, while not perfect, at
least introduces a minimum of entropy into Yarrow before boot.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, Sep 07, 2013 at 05:34:14PM -0700, Kevin Oberman wrote: > On Sat, Sep 7, 2013 at 5:31 PM, Glen Barber wrote: > > > On Sat, Sep 07, 2013 at 05:27:19PM -0700, Adrian Chadd wrote: > > > ok. So I can work around this for these MIPS AP images by echoing > > something > > > into /dev/random ? > > > > > > > The correct workaround (which now I see I should have done before > > locking head/) is to revert this commit so it can be properly fixed. > > > > Calling "echo '' >/dev/random" the "KNOB" is insulting. > > > > I'm sorry. The word is spelled "KLUDGE", now "KNOB". It works and is better > than being dead in the water, but is is still spelled "KLUDGE". > Meh, we can create a symlink for KLUDGE -> KNOB in head/ if needed. Either way, I think this commit needs to be reverted until properly fixed and tested. Glen pgpP4qwpEt_wh.pgp Description: PGP signature
Re: random(4) update causes mips compile fail | mips boot fail
I'm sorry. The word is spelled "KLUDGE", now "KNOB". It works and is better than being dead in the water, but is is still spelled "KLUDGE". On Sat, Sep 7, 2013 at 5:31 PM, Glen Barber wrote: > On Sat, Sep 07, 2013 at 05:27:19PM -0700, Adrian Chadd wrote: > > ok. So I can work around this for these MIPS AP images by echoing > something > > into /dev/random ? > > > > The correct workaround (which now I see I should have done before > locking head/) is to revert this commit so it can be properly fixed. > > Calling "echo '' >/dev/random" the "KNOB" is insulting. > > Glen > > -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, Sep 07, 2013 at 05:27:19PM -0700, Adrian Chadd wrote: > ok. So I can work around this for these MIPS AP images by echoing something > into /dev/random ? > The correct workaround (which now I see I should have done before locking head/) is to revert this commit so it can be properly fixed. Calling "echo '' >/dev/random" the "KNOB" is insulting. Glen pgpxZSFw8AxrM.pgp Description: PGP signature
Re: random(4) update causes mips compile fail | mips boot fail
[snip] ok. So I can work around this for these MIPS AP images by echoing something into /dev/random ? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 22:31, Ian Lepore wrote: > Those of us who have to cope with limited systems will fix our config > for those systems; that part of it shouldn't be your problem beyond > providing us with a knob. If there is NO random number generator, then /dev/random blocks. Period. If you don't want to block, don't read /dev/random. If you have an RNG loaded (like Yarrow), the intent is that it will block-until-secure, but you can insta-unblock it by writing to it. The intent is that early in the boot, while running all the /etc/rc.d/* stuff, you write anything you like (hopefully random crud) to the device and it seeds itself with what it gets. At file close after the write, it unblocks. So at the minimum, you can unblock Yarrow by doing $ echo '' > /dev/random ... as soon as the device is active. There is your knob. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 21:38, Ian Lepore wrote: > I keep trying to say this, and I keep getting the feeling that it just > doesn't register with anyone I say it to, like I'm speaking some > language from another planet or something... Sorry. I haven't forgotten this. Right now, for 10.0, the intent is "Fix the bugs first". The all-singing variant is going to follow. > There may be NO entropy of any sort available on an embedded system, and > you cannot block the ability to boot and run such a system just because > you think it's a bad idea to run without sufficient randomness. It's > not your call to make -- it's a decision for the person using or > administering the system. True. But the current fix for this (AKA the status quo) means that things are broken for everyone, and I'm trying to get things "fixed by default" with some kind of workaround for the folks that need it, rather than the other way round. > You must provide a mechanism that disables the blocking behavior. The > mechanism must be either a kernel compile-time config knob (not all > platforms use loader(8) or anything else that can set a tunable var), or > something in the rc system that can unblock /dev/random before anything > else needs it. The latter implies that the kernel itself must not block > before getting to that point in rc processing, even if it needs random > numbers for something (like cooking up a temporary MAC address). Any kind of write to /dev/random (Yarrow) will unblock it. This may be a matter of scripting in /etc/rc.d/. Like "echo '' > /dev/random", and it just needs to happen early enough, i.e. before you do a blocking read. > It's okay to make it hard to do the wrong thing by accident. It's not > okay to make it impossible to do that thing on purpose. Again, true, but please bear in mind that things are suboptimal right now. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 21:42, Adrian Chadd wrote: > We discussed this at the dev summit. Mark asked what we'd like to do. > > Mark - would you mind terribly adding a kernel compile option that controls > that blocking default, so we can flip it on for the ARM/MIPS boards that > don't have a hardware PRNG to start seeding things with? This has some merit; but I need to thing about how to do it. Per-architecture block/no-block defaults are going to get messy unless done properly. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, 2013-09-07 at 22:25 +0100, Mark R V Murray wrote: > On 7 Sep 2013, at 21:42, Adrian Chadd wrote: > > > We discussed this at the dev summit. Mark asked what we'd like to do. > > > > Mark - would you mind terribly adding a kernel compile option that controls > > that blocking default, so we can flip it on for the ARM/MIPS boards that > > don't have a hardware PRNG to start seeding things with? > > This has some merit; but I need to thing about how to do it. Per-architecture > block/no-block defaults are going to get messy unless done properly. > > M I think it's fine to default to blocking (make it hard to do the wrong thing by accident), and then any given kernel config can include an OPTION_WHATEVERYOUCALLIT to disable the blocking and let it work the way it does now. Having a tuneable var with a name related to the config option might be nice too, for platforms that can handle such things. Those of us who have to cope with limited systems will fix our config for those systems; that part of it shouldn't be your problem beyond providing us with a knob. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 20:12, Sean Bruno wrote: > On Sat, 2013-09-07 at 19:56 +0100, Mark R V Murray wrote: >>> Ok. Right now, the mips kernel doesn't build unless I have random >> built >>> in, we were using it as a module previously. >> >> >> I'm testing a fix, but if you want to help out, please move the >> random_null_func() >> from randomdev.c to pseudo_rng.c in sys/dev/random. Patch enclosed. >> >> Thanks! >> >> M > > Closer: > > --- kernel.debug --- > linking kernel.debug > random_adaptors.o: In function `random_sysctl_active_adaptor_handler': > /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x2dc): > undefined reference to `random_get_active_adaptor' > /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x2dc): > relocation truncated to fit: R_MIPS_26 against > `random_get_active_adaptor' > *** [kernel.debug] Error code 1 Nearly there - I saw that too. Proposed fix enclosed. M -- Mark R V Murray rng_fix.patch Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
Hi! On 7 September 2013 13:38, Ian Lepore wrote: > I keep trying to say this, and I keep getting the feeling that it just > doesn't register with anyone I say it to, like I'm speaking some > language from another planet or something... > > There may be NO entropy of any sort available on an embedded system, and > you cannot block the ability to boot and run such a system just because > you think it's a bad idea to run without sufficient randomness. It's > not your call to make -- it's a decision for the person using or > administering the system. > > You must provide a mechanism that disables the blocking behavior. The > mechanism must be either a kernel compile-time config knob (not all > platforms use loader(8) or anything else that can set a tunable var), or > something in the rc system that can unblock /dev/random before anything > else needs it. The latter implies that the kernel itself must not block > before getting to that point in rc processing, even if it needs random > numbers for something (like cooking up a temporary MAC address). > > It's okay to make it hard to do the wrong thing by accident. It's not > okay to make it impossible to do that thing on purpose. > We discussed this at the dev summit. Mark asked what we'd like to do. Mark - would you mind terribly adding a kernel compile option that controls that blocking default, so we can flip it on for the ARM/MIPS boards that don't have a hardware PRNG to start seeding things with? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, 2013-09-07 at 19:40 +0100, Mark R V Murray wrote: > On 7 Sep 2013, at 19:36, Sean Bruno wrote: > > > On Sat, 2013-09-07 at 18:39 +0100, Mark R V Murray wrote: > >> On 7 Sep 2013, at 17:43, Sean Bruno wrote: > >>> trying to enable random on my DIR-825 kernconf I get this on boot: > >>> > >>> Configuration file: /etc/cfg/hostapd.wlan0.conf > >>> Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid "TESTBRUNO" > >>> Entropy device is blocking > >> > >> Please make a change to sys/dev/random/randomdev_soft.c; > >> > >> Around line 82, please change from ".seeded = 0" to ".seeded = 1". > >> > >> If that works, then your report above with the "Entropy device is > >> blocking." > >> is trying to read random numbers before /dev/random is secure; this is a > >> BAD > >> security problem. > >> > >> M > > > > > > Looks like it does indeed work if that is set to 1. > > > > This "DIR-825" config, should be loading random as a module, not built > > into the kernel due to size limitations of the kernel on this board. > > Hmm. I'll set it back to 1, but this is technically a security issue. > I keep trying to say this, and I keep getting the feeling that it just doesn't register with anyone I say it to, like I'm speaking some language from another planet or something... There may be NO entropy of any sort available on an embedded system, and you cannot block the ability to boot and run such a system just because you think it's a bad idea to run without sufficient randomness. It's not your call to make -- it's a decision for the person using or administering the system. You must provide a mechanism that disables the blocking behavior. The mechanism must be either a kernel compile-time config knob (not all platforms use loader(8) or anything else that can set a tunable var), or something in the rc system that can unblock /dev/random before anything else needs it. The latter implies that the kernel itself must not block before getting to that point in rc processing, even if it needs random numbers for something (like cooking up a temporary MAC address). It's okay to make it hard to do the wrong thing by accident. It's not okay to make it impossible to do that thing on purpose. -- Ian > Thanks for the report back, and sorry for the hassles! > > M ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: random(4) update causes mips compile fail | mips boot fail
> Nearly there - I saw that too. > > Proposed fix enclosed. > > M Compile succeeds, booted up and I still see the blocking message and the machine does not post fully. setting sys/dev/random/randomdev_soft.c ".seeded = 1". allows the system to boot properly. Sean signature.asc Description: This is a digitally signed message part
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 19:49, Sean Bruno wrote: > On Sat, 2013-09-07 at 19:40 +0100, Mark R V Murray wrote: >>> Looks like it does indeed work if that is set to 1. >>> >>> This "DIR-825" config, should be loading random as a module, not >> built >>> into the kernel due to size limitations of the kernel on this board. >> >> Hmm. I'll set it back to 1, but this is technically a security issue. >> >> Thanks for the report back, and sorry for the hassles! >> >> M >> -- >> Mark R V Murray > > Ok. Right now, the mips kernel doesn't build unless I have random built > in, we were using it as a module previously. I'm testing a fix, but if you want to help out, please move the random_null_func() from randomdev.c to pseudo_rng.c in sys/dev/random. Patch enclosed. Thanks! M -- Mark R V Murray rng_fix.patch Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 19:36, Sean Bruno wrote: > On Sat, 2013-09-07 at 18:39 +0100, Mark R V Murray wrote: >> On 7 Sep 2013, at 17:43, Sean Bruno wrote: >>> trying to enable random on my DIR-825 kernconf I get this on boot: >>> >>> Configuration file: /etc/cfg/hostapd.wlan0.conf >>> Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid "TESTBRUNO" >>> Entropy device is blocking >> >> Please make a change to sys/dev/random/randomdev_soft.c; >> >> Around line 82, please change from ".seeded = 0" to ".seeded = 1". >> >> If that works, then your report above with the "Entropy device is blocking." >> is trying to read random numbers before /dev/random is secure; this is a BAD >> security problem. >> >> M > > > Looks like it does indeed work if that is set to 1. > > This "DIR-825" config, should be loading random as a module, not built > into the kernel due to size limitations of the kernel on this board. Hmm. I'll set it back to 1, but this is technically a security issue. Thanks for the report back, and sorry for the hassles! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, 2013-09-07 at 19:56 +0100, Mark R V Murray wrote: > > Ok. Right now, the mips kernel doesn't build unless I have random > built > > in, we were using it as a module previously. > > > I'm testing a fix, but if you want to help out, please move the > random_null_func() > from randomdev.c to pseudo_rng.c in sys/dev/random. Patch enclosed. > > Thanks! > > M Closer: --- kernel.debug --- linking kernel.debug random_adaptors.o: In function `random_sysctl_active_adaptor_handler': /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x2dc): undefined reference to `random_get_active_adaptor' /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x2dc): relocation truncated to fit: R_MIPS_26 against `random_get_active_adaptor' *** [kernel.debug] Error code 1 signature.asc Description: This is a digitally signed message part
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, 2013-09-07 at 19:40 +0100, Mark R V Murray wrote: > > Looks like it does indeed work if that is set to 1. > > > > This "DIR-825" config, should be loading random as a module, not > built > > into the kernel due to size limitations of the kernel on this board. > > Hmm. I'll set it back to 1, but this is technically a security issue. > > Thanks for the report back, and sorry for the hassles! > > M > -- > Mark R V Murray Ok. Right now, the mips kernel doesn't build unless I have random built in, we were using it as a module previously. Sean signature.asc Description: This is a digitally signed message part
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, 2013-09-07 at 18:39 +0100, Mark R V Murray wrote: > On 7 Sep 2013, at 17:43, Sean Bruno wrote: > > trying to enable random on my DIR-825 kernconf I get this on boot: > > > > Configuration file: /etc/cfg/hostapd.wlan0.conf > > Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid "TESTBRUNO" > > Entropy device is blocking > > Please make a change to sys/dev/random/randomdev_soft.c; > > Around line 82, please change from ".seeded = 0" to ".seeded = 1". > > If that works, then your report above with the "Entropy device is blocking." > is trying to read random numbers before /dev/random is secure; this is a BAD > security problem. > > M Looks like it does indeed work if that is set to 1. This "DIR-825" config, should be loading random as a module, not built into the kernel due to size limitations of the kernel on this board. Sean signature.asc Description: This is a digitally signed message part
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 17:43, Sean Bruno wrote: > trying to enable random on my DIR-825 kernconf I get this on boot: > > Configuration file: /etc/cfg/hostapd.wlan0.conf > Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid "TESTBRUNO" > Entropy device is blocking Please make a change to sys/dev/random/randomdev_soft.c; Around line 82, please change from ".seeded = 0" to ".seeded = 1". If that works, then your report above with the "Entropy device is blocking." is trying to read random numbers before /dev/random is secure; this is a BAD security problem. M -- Mark R V Murray Entropy device is blocking signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 17:43, Sean Bruno wrote: > with "nodevice random" I can no longer compile for MIPS > --- kernel.debug --- > pseudo_rng.o:(.data+0x3c): undefined reference to `random_null_func' > pseudo_rng.o:(.data+0x44): undefined reference to `random_null_func' > pseudo_rng.o:(.data+0x74): undefined reference to `random_null_func' > pseudo_rng.o:(.data+0x78): undefined reference to `random_null_func' > pseudo_rng.o:(.data+0x84): undefined reference to `random_null_func' > pseudo_rng.o:(.data+0x8c): more undefined references to > `random_null_func' follow > random_adaptors.o: In function `random_sysctl_active_adaptor_handler': > /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x40): > undefined reference to `random_get_active_adaptor' > /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x40): > relocation truncated to fit: R_MIPS_26 against > `random_get_active_adaptor' This is easy enough to fix. Doing a build now. > trying to enable random on my DIR-825 kernconf I get this on boot: > > Configuration file: /etc/cfg/hostapd.wlan0.conf > Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid "TESTBRUNO" > Entropy device is blocking. Can you please see if you can get the output of "sysctl -a | grep random" at that point? M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, 2013-09-07 at 18:34 +0100, Mark R V Murray wrote: > > Configuration file: /etc/cfg/hostapd.wlan0.conf > > Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid > "TESTBRUNO" > > Entropy device is blocking. > > Can you please see if you can get the output of "sysctl -a | grep > random" > at that point? Nope, the system is stalled at that point so there's no interactivity. Sean signature.asc Description: This is a digitally signed message part
random(4) update causes mips compile fail | mips boot fail
with "nodevice random" I can no longer compile for MIPS --- kernel.debug --- pseudo_rng.o:(.data+0x3c): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x44): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x74): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x78): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x84): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x8c): more undefined references to `random_null_func' follow random_adaptors.o: In function `random_sysctl_active_adaptor_handler': /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x40): undefined reference to `random_get_active_adaptor' /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x40): relocation truncated to fit: R_MIPS_26 against `random_get_active_adaptor' trying to enable random on my DIR-825 kernconf I get this on boot: Configuration file: /etc/cfg/hostapd.wlan0.conf Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid "TESTBRUNO" Entropy device is blocking. signature.asc Description: This is a digitally signed message part
