[Cerowrt-devel] development build 3.10.17-1 released

[Fred Stratton]

What do you mean by 'overlay/etc/rc.local'?

I have used 2 backup configurations, one with iptables rules in 
rc.local, and one with no uncommented text, other than 'exit 0'.

Both show the same problem.

I have previously operated this Mac with a wired connection. I was 
thinking this was a 10.8.5 problem prior to your comment.


On 20/10/13 14:17, David Personette wrote:
> 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.
>
> -- 
> David P.
>
>
> On Sun, Oct 20, 2013 at 9:12 AM, Fred Stratton <fredstratton at imap.cc 
> <mailto:fredstratton at imap.cc>> wrote:
>
>     Spoke too soon . Machine running OS X 10.8.5 cannot obtain
>     wireless DHCP lease. Machine running 10.7.5 has no problem.
>
>
>     On 20/10/13 06:41, Dave Taht wrote:
>
>         + sync with openwrt
>         + dnsmasq 2.67rc4
>         + get_cycles() and /dev/random fixes
>         + mild firewall changes
>         + actually sort of tested
>         -  sysupgrade still busted
>         - didn't package the jitter rng
>
>         The simple expedient of putting a script in /etc/rc.local to
>         restart
>         pimd, minissdpd, and dnsmasq 60 seconds after boot appears to
>         get us a
>         working dhcp/dns on the wifi interfaces once again.
>
>         dnsmasq wasn't busted, it was how it interfaces to netifd. the
>         march
>         down to something deployable resumes with rc4.
>
>         This is the first test that I know of, of some of the RNG fixes
>         upstream, notably the mips code does the right thing with a highly
>         optimized "get_cycles()".
>
>         There are two changes to the firewall code
>
>         1) There has been a long-standing error in not blocking port 161
>         (snmp) from the outside world. It is now blocked by default.
>
>         Although I am not aware of any exploits of this (besides the
>         information leakage) I would recommend blocking this port by
>         default
>         on your existing builds, also, or disabling the snmp daemon
>         entirely
>         if you do not use it.
>
>         2) Usage of the "pattern matching syntax" on various firewall
>         rules.
>
>         Instead of 3 rules for se00,sw00,sw10, and 4 for
>         gw00,gw10,gw01,gw11
>         there are now 1 rule for s+ and one rule for gw+
>
>         This does not show up in the web interface correctly. I'd also
>         like to
>         get to a more efficient rule set for the blocked ports,
>         perhaps with
>         ipset...
>
>         ...
>
>         It's sort of my hope that with these fixes that the march
>         towards a
>         stable release can resume, and we get some fresh shiny new
>         bugs out of
>         this.
>
>         Upcoming next are a revised version of pie, more random number
>         fixes,
>         and I forget what else.
>
>
>         3)
>
>
>     _______________________________________________
>     Cerowrt-devel mailing list
>     Cerowrt-devel at lists.bufferbloat.net
>     <mailto:Cerowrt-devel at lists.bufferbloat.net>
>     https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20131020/9a1eaced/attachment-0002.html>