<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-forward-container">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Well, I have never before seen such a clear explanation of router
firmware configuration. I had expected the script to be launched
from rc, not rc.local. The latter, however, might be regarded as
good practice, and, if rc is derived unchanged from OpenWrt, might
make code maintenance much easier.<br>
<br>
I reinstated the script in rc.local to launch /etc/fixdaemons,
overwritten as you say by the /overlay/etc/rc.local I had
introduced, and all wireless connected machines have reacquired
ipv4 DHCP addresses, in addition to the ipv6 addresses they
possessed.<br>
<br>
Thank you.<br>
<br>
<br>
<div class="moz-cite-prefix">On 20/10/13 14:55, David Personette
wrote:<br>
</div>
<blockquote
cite="mid:CAMybZqxHiZDjvq1H2166vd9grRyGNi5M575uVu91CDkf7PKc8g@mail.gmail.com"
type="cite">
<div dir="ltr">The actual CeroWRT is a RO filesystem, with
modifications stored in an overlay. you can see the original
file with no customizations in /rom. /overlay is mounted
"over" the ROM. If nothing has been changed the /rom file is
read, if you have made a change, then it's read from the
overlay. A change that you can make is deleting a file that
exists on the /rom image, and that can be stored on the
overlay as well (the file will be not be visible in the merged
/). You can purge changes that you have made by removing the
corresponding file(s) and/or directory(s) in the /overlay
filesystem.<br>
<div>
<div class="gmail_extra"><br clear="all">
<div>-- <br>
David P.</div>
<br>
<br>
<div class="gmail_quote">On Sun, Oct 20, 2013 at 9:41 AM,
Fred Stratton <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:fredstratton@imap.cc" target="_blank">fredstratton@imap.cc</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> What do you
mean by 'overlay/etc/rc.local'?<br>
<br>
I have used 2 backup configurations, one with
iptables rules in rc.local, and one with no
uncommented text, other than 'exit 0'.<br>
<br>
Both show the same problem.<br>
<br>
I have previously operated this Mac with a wired
connection. I was thinking this was a 10.8.5 problem
prior to your comment.
<div>
<div class="h5"><br>
<br>
<br>
<div>On 20/10/13 14:17, David Personette wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I have a laptop running 10.8.5
that's working. I had to remove the
/overlay/etc/rc.local file and reboot before
Dave's /etc/fixdaemons would show up. My
saved configuration was stopping it from
working.<br>
<div>
<div class="gmail_extra"><br clear="all">
<div>-- <br>
David P.</div>
<br>
<br>
<div class="gmail_quote">On Sun, Oct 20,
2013 at 9:12 AM, Fred Stratton <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:fredstratton@imap.cc"
target="_blank">fredstratton@imap.cc</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> Spoke too
soon . Machine running OS X 10.8.5
cannot obtain wireless DHCP lease.
Machine running 10.7.5 has no
problem.
<div><br>
<br>
On 20/10/13 06:41, Dave Taht
wrote:<br>
</div>
<div>
<div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> +
sync with openwrt<br>
+ dnsmasq 2.67rc4<br>
+ get_cycles() and /dev/random
fixes<br>
+ mild firewall changes<br>
+ actually sort of tested<br>
- sysupgrade still busted<br>
- didn't package the jitter
rng<br>
<br>
The simple expedient of
putting a script in
/etc/rc.local to restart<br>
pimd, minissdpd, and dnsmasq
60 seconds after boot appears
to get us a<br>
working dhcp/dns on the wifi
interfaces once again.<br>
<br>
dnsmasq wasn't busted, it was
how it interfaces to netifd.
the march<br>
down to something deployable
resumes with rc4.<br>
<br>
This is the first test that I
know of, of some of the RNG
fixes<br>
upstream, notably the mips
code does the right thing with
a highly<br>
optimized "get_cycles()".<br>
<br>
There are two changes to the
firewall code<br>
<br>
1) There has been a
long-standing error in not
blocking port 161<br>
(snmp) from the outside world.
It is now blocked by default.<br>
<br>
Although I am not aware of any
exploits of this (besides the<br>
information leakage) I would
recommend blocking this port
by default<br>
on your existing builds, also,
or disabling the snmp daemon
entirely<br>
if you do not use it.<br>
<br>
2) Usage of the "pattern
matching syntax" on various
firewall rules.<br>
<br>
Instead of 3 rules for
se00,sw00,sw10, and 4 for
gw00,gw10,gw01,gw11<br>
there are now 1 rule for s+
and one rule for gw+<br>
<br>
This does not show up in the
web interface correctly. I'd
also like to<br>
get to a more efficient rule
set for the blocked ports,
perhaps with<br>
ipset...<br>
<br>
...<br>
<br>
It's sort of my hope that with
these fixes that the march
towards a<br>
stable release can resume, and
we get some fresh shiny new
bugs out of<br>
this.<br>
<br>
Upcoming next are a revised
version of pie, more random
number fixes,<br>
and I forget what else.<br>
<br>
<br>
3)<br>
<br>
</blockquote>
<br>
</div>
</div>
<div>
<div>
_______________________________________________<br>
Cerowrt-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Cerowrt-devel@lists.bufferbloat.net"
target="_blank">Cerowrt-devel@lists.bufferbloat.net</a><br>
<a moz-do-not-send="true"
href="https://lists.bufferbloat.net/listinfo/cerowrt-devel"
target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Cerowrt-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
<a moz-do-not-send="true"
href="https://lists.bufferbloat.net/listinfo/cerowrt-devel"
target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
<br>
</div>
<br>
</body>
</html>