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.

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.

Thank you.


On 20/10/13 14:55, David Personette wrote:
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 <[email protected] <mailto:[email protected]>> 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
    <[email protected] <mailto:[email protected]>> 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
        [email protected]
        <mailto:[email protected]>
        https://lists.bufferbloat.net/listinfo/cerowrt-devel




    _______________________________________________
    Cerowrt-devel mailing list
    [email protected]
    <mailto:[email protected]>
    https://lists.bufferbloat.net/listinfo/cerowrt-devel





_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to