From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0CDDF21F1E3 for ; Sun, 20 Oct 2013 06:55:58 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so5489487wes.18 for ; Sun, 20 Oct 2013 06:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zX2Zp/oHvNnSRqd7uVbsj3rzb5LV8YefE4LMe0R3sv0=; b=hxHRl2r2Giz+g/6EFv22PhsZqLaPp+iPN8dhER6qBQP9R5HCbj4OlMfPGkpHBZNZsb Bx1zXmcsV0sZP2hTTjgnFdccPOAcQxR/FhVReKohpdzn/pAi5zxEsLgUCCdhPlbEtTgD 7aJU1brSeZbsTRw8t3DbYtjI2QzmCLzW8VR/uGtN6tkPTMWiq1nHoVP/k2dqVSa06VMT Vs9VADY7gZ2wkW0D51BWk9KfW/UVUo/Inds64/qHHdvw1NfrqSEwAMic3N60MI1CIsfi ei+Fft82wQdcAFoVKyMRQx7Yu4l5FeebP6ixbFVeURNHWp73W0Gsl9EbjT7DxOU3AM/G 0KHg== X-Received: by 10.180.89.42 with SMTP id bl10mr6003770wib.47.1382277356832; Sun, 20 Oct 2013 06:55:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.92.70 with HTTP; Sun, 20 Oct 2013 06:55:36 -0700 (PDT) In-Reply-To: <5263DD9D.4070604@imap.cc> References: <5263D6D0.6090800@imap.cc> <5263DD9D.4070604@imap.cc> From: David Personette Date: Sun, 20 Oct 2013 09:55:36 -0400 Message-ID: To: Fred Stratton Content-Type: multipart/alternative; boundary=f46d04447e2fd5cf0104e92c861d Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] development build 3.10.17-1 released X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 13:56:00 -0000 --f46d04447e2fd5cf0104e92c861d Content-Type: text/plain; charset=UTF-8 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. -- David P. On Sun, Oct 20, 2013 at 9:41 AM, Fred Stratton wrote: > 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 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@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > --f46d04447e2fd5cf0104e92c861d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 rea= d from the overlay. A change that you can make is deleting a file that exis= ts on the /rom image, and that can be stored on the overlay as well (the fi= le 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.

--=C2=A0
David P= .


On Sun, Oct 20, 2013 at 9:41 AM, Fred St= ratton <fredstratton@imap.cc> wrote:
=20 =20 =20
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 wa= s stopping it from working.

--
David P.


On Sun, Oct 20, 2013 at 9:12 AM, Fred Stratton <fredstratton@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
- =C2=A0sysupgrade 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 t= o 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" o= n 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@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-= devel



_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


--f46d04447e2fd5cf0104e92c861d--