Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
* [Cerowrt-devel] development build 3.10.17-1 released
@ 2013-10-20  5:41 Dave Taht
  2013-10-20  8:35 ` Fred Stratton
  2013-10-20 13:12 ` Fred Stratton
  0 siblings, 2 replies; 18+ messages in thread
From: Dave Taht @ 2013-10-20  5:41 UTC (permalink / raw)
  To: cerowrt-devel

+ 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)

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
  2013-10-20  5:41 [Cerowrt-devel] development build 3.10.17-1 released Dave Taht
@ 2013-10-20  8:35 ` Fred Stratton
  2013-10-20 13:12 ` Fred Stratton
  1 sibling, 0 replies; 18+ messages in thread
From: Fred Stratton @ 2013-10-20  8:35 UTC (permalink / raw)
  To: cerowrt-devel

Works correctly here. Thank you for your efforts.


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)
>


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
  2013-10-20  5:41 [Cerowrt-devel] development build 3.10.17-1 released Dave Taht
  2013-10-20  8:35 ` Fred Stratton
@ 2013-10-20 13:12 ` Fred Stratton
  2013-10-20 13:17   ` David Personette
  1 sibling, 1 reply; 18+ messages in thread
From: Fred Stratton @ 2013-10-20 13:12 UTC (permalink / raw)
  To: cerowrt-devel

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)
>


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
  2013-10-20 13:12 ` Fred Stratton
@ 2013-10-20 13:17   ` David Personette
  2013-10-20 13:41     ` Fred Stratton
  2013-10-21  1:22     ` [Cerowrt-devel] development build 3.10.17-1 released Dave Taht
  0 siblings, 2 replies; 18+ messages in thread
From: David Personette @ 2013-10-20 13:17 UTC (permalink / raw)
  To: Fred Stratton; +Cc: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]

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@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@lists.**bufferbloat.net<Cerowrt-devel@lists.bufferbloat.net>
> https://lists.bufferbloat.net/**listinfo/cerowrt-devel<https://lists.bufferbloat.net/listinfo/cerowrt-devel>
>

[-- Attachment #2: Type: text/html, Size: 3361 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
  2013-10-20 13:17   ` David Personette
@ 2013-10-20 13:41     ` Fred Stratton
  2013-10-20 13:55       ` David Personette
  2013-10-21  1:22     ` [Cerowrt-devel] development build 3.10.17-1 released Dave Taht
  1 sibling, 1 reply; 18+ messages in thread
From: Fred Stratton @ 2013-10-20 13:41 UTC (permalink / raw)
  To: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 3270 bytes --]

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@imap.cc 
> <mailto: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
>         -  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
>     <mailto:Cerowrt-devel@lists.bufferbloat.net>
>     https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>


[-- Attachment #2: Type: text/html, Size: 6388 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
  2013-10-20 13:41     ` Fred Stratton
@ 2013-10-20 13:55       ` David Personette
  2013-10-21  4:11         ` Michael Richardson
  0 siblings, 1 reply; 18+ messages in thread
From: David Personette @ 2013-10-20 13:55 UTC (permalink / raw)
  To: Fred Stratton; +Cc: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 3753 bytes --]

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 <fredstratton@imap.cc> 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 <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
>>> -  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
>
>

[-- Attachment #2: Type: text/html, Size: 7494 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
  2013-10-20 13:17   ` David Personette
  2013-10-20 13:41     ` Fred Stratton
@ 2013-10-21  1:22     ` Dave Taht
  1 sibling, 0 replies; 18+ messages in thread
From: Dave Taht @ 2013-10-21  1:22 UTC (permalink / raw)
  To: David Personette; +Cc: cerowrt-devel

On Sun, Oct 20, 2013 at 6:17 AM, David Personette <dperson@gmail.com> 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.

I usually backup /overlay and restore it carefully after doing a diff.

As for using rc.local here rather than creating a package, Sorry! it was a
"simple expedient"... I'd rather have it work right on boot.

But:

There are a few other things that I'd like to start or restart after
the device has gathered some entropy.  Notably cero is now generating
certs for the web interface but not apparently in a form lighttpd can
parse. (make_certs.sh)

So anyway it seems sane to have a new package deferred_start? to fire
off stuff like that, too, and not do anything in rc.local as part of
the distro.

> --
> 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
>>> -  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
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
  2013-10-20 13:55       ` David Personette
@ 2013-10-21  4:11         ` Michael Richardson
  2013-10-21  9:26           ` David Personette
  0 siblings, 1 reply; 18+ messages in thread
From: Michael Richardson @ 2013-10-21  4:11 UTC (permalink / raw)
  To: David Personette; +Cc: cerowrt-devel


David Personette <dperson@gmail.com> wrote:
    > 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.

How do I see/delete the mark in the /overlay that marks the file in the /rom as
deleted? 

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
  2013-10-21  4:11         ` Michael Richardson
@ 2013-10-21  9:26           ` David Personette
  2013-10-21 12:22             ` David Personette
  0 siblings, 1 reply; 18+ messages in thread
From: David Personette @ 2013-10-21  9:26 UTC (permalink / raw)
  To: Michael Richardson; +Cc: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

FYI: direct changes to the /overlay aren't noticed by the kernel, you have
to reboot first. I can't say that I'm an expert, I've just poked around at
it. I just deleted the whole directory (IE: rm -rf
/overlay/etc/uci-defaults). Upon reboot the entire directory is reverted to
the contents of /rom.

-- 
David P.


On Mon, Oct 21, 2013 at 12:11 AM, Michael Richardson <mcr@sandelman.ca>wrote:

>
> David Personette <dperson@gmail.com> wrote:
>     > 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.
>
> How do I see/delete the mark in the /overlay that marks the file in the
> /rom as
> deleted?
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails
>    [
>
>

[-- Attachment #2: Type: text/html, Size: 1881 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
  2013-10-21  9:26           ` David Personette
@ 2013-10-21 12:22             ` David Personette
  2013-10-21 13:50               ` [Cerowrt-devel] development build 3.10.17-2 released Fred Stratton
  0 siblings, 1 reply; 18+ messages in thread
From: David Personette @ 2013-10-21 12:22 UTC (permalink / raw)
  To: Michael Richardson; +Cc: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

I'm not sure what's changed but 3.10.17-2 is working for me, so far.

Was anyone paying attention to nftables (iptables replacement)? I just saw
that it was merged into net-next. On the LTS 3.10.x it won't have any
impact for now, and apparently there's a backwards compatibility utility to
still process iptables rules...

-- 
David P.


On Mon, Oct 21, 2013 at 5:26 AM, David Personette <dperson@gmail.com> wrote:

> FYI: direct changes to the /overlay aren't noticed by the kernel, you have
> to reboot first. I can't say that I'm an expert, I've just poked around at
> it. I just deleted the whole directory (IE: rm -rf
> /overlay/etc/uci-defaults). Upon reboot the entire directory is reverted to
> the contents of /rom.
>
> --
> David P.
>
>
> On Mon, Oct 21, 2013 at 12:11 AM, Michael Richardson <mcr@sandelman.ca>wrote:
>
>>
>> David Personette <dperson@gmail.com> wrote:
>>     > 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.
>>
>> How do I see/delete the mark in the /overlay that marks the file in the
>> /rom as
>> deleted?
>>
>> --
>> ]               Never tell me the odds!                 | ipv6 mesh
>> networks [
>> ]   Michael Richardson, Sandelman Software Works        | network
>> architect  [
>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
>> rails    [
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2847 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-2 released
  2013-10-21 12:22             ` David Personette
@ 2013-10-21 13:50               ` Fred Stratton
  2013-10-21 14:46                 ` David Personette
  0 siblings, 1 reply; 18+ messages in thread
From: Fred Stratton @ 2013-10-21 13:50 UTC (permalink / raw)
  To: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]

I have installed this build, but cannot access the web interface. Am 
presently trying to determine how to reinstall the configuration file 
from the cli, other than item by item, so I can attempt to rebuild the 
build from within. Have reverted to earlier build for now to regain 
internet access.


On 21/10/13 13:22, David Personette wrote:
> I'm not sure what's changed but 3.10.17-2 is working for me, so far.
>
> Was anyone paying attention to nftables (iptables replacement)? I just 
> saw that it was merged into net-next. On the LTS 3.10.x it won't have 
> any impact for now, and apparently there's a backwards compatibility 
> utility to still process iptables rules...
>
> -- 
> David P.
>
>
> On Mon, Oct 21, 2013 at 5:26 AM, David Personette <dperson@gmail.com 
> <mailto:dperson@gmail.com>> wrote:
>
>     FYI: direct changes to the /overlay aren't noticed by the kernel,
>     you have to reboot first. I can't say that I'm an expert, I've
>     just poked around at it. I just deleted the whole directory (IE:
>     rm -rf /overlay/etc/uci-defaults). Upon reboot the entire
>     directory is reverted to the contents of /rom.
>
>     -- 
>     David P.
>
>
>     On Mon, Oct 21, 2013 at 12:11 AM, Michael Richardson
>     <mcr@sandelman.ca <mailto:mcr@sandelman.ca>> wrote:
>
>
>         David Personette <dperson@gmail.com
>         <mailto:dperson@gmail.com>> wrote:
>             > 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.
>
>         How do I see/delete the mark in the /overlay that marks the
>         file in the /rom as
>         deleted?
>
>         --
>         ]               Never tell me the odds!                 | ipv6
>         mesh networks [
>         ]   Michael Richardson, Sandelman Software Works        |
>         network architect  [
>         ] mcr@sandelman.ca <mailto:mcr@sandelman.ca>
>         http://www.sandelman.ca/        |   ruby on rails    [
>
>
>


[-- Attachment #2: Type: text/html, Size: 6411 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-2 released
  2013-10-21 13:50               ` [Cerowrt-devel] development build 3.10.17-2 released Fred Stratton
@ 2013-10-21 14:46                 ` David Personette
  2013-10-21 15:39                   ` Fred Stratton
  0 siblings, 1 reply; 18+ messages in thread
From: David Personette @ 2013-10-21 14:46 UTC (permalink / raw)
  To: Fred Stratton; +Cc: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

If you made a config backup, you can restore it by scp'ing it to your
router, and extracting it in /.

IE: 'cd / && tar xvzf /root/backup-cerowrt-2013-10-06.tar.gz'

-- 
David P.


On Mon, Oct 21, 2013 at 9:50 AM, Fred Stratton <fredstratton@imap.cc> wrote:

>  I have installed this build, but cannot access the web interface. Am
> presently trying to determine how to reinstall the configuration file from
> the cli, other than item by item, so I can attempt to rebuild the build
> from within. Have reverted to earlier build for now to regain internet
> access.
>
>
> On 21/10/13 13:22, David Personette wrote:
>
>  I'm not sure what's changed but 3.10.17-2 is working for me, so far.
>
>  Was anyone paying attention to nftables (iptables replacement)? I just
> saw that it was merged into net-next. On the LTS 3.10.x it won't have any
> impact for now, and apparently there's a backwards compatibility utility to
> still process iptables rules...
>
> --
> David P.
>
>
> On Mon, Oct 21, 2013 at 5:26 AM, David Personette <dperson@gmail.com>wrote:
>
>> FYI: direct changes to the /overlay aren't noticed by the kernel, you
>> have to reboot first. I can't say that I'm an expert, I've just poked
>> around at it. I just deleted the whole directory (IE: rm -rf
>> /overlay/etc/uci-defaults). Upon reboot the entire directory is reverted to
>> the contents of /rom.
>>
>> --
>> David P.
>>
>>
>> On Mon, Oct 21, 2013 at 12:11 AM, Michael Richardson <mcr@sandelman.ca>wrote:
>>
>>>
>>> David Personette <dperson@gmail.com> wrote:
>>>     > 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.
>>>
>>>  How do I see/delete the mark in the /overlay that marks the file in the
>>> /rom as
>>> deleted?
>>>
>>> --
>>> ]               Never tell me the odds!                 | ipv6 mesh
>>> networks [
>>> ]   Michael Richardson, Sandelman Software Works        | network
>>> architect  [
>>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
>>> rails    [
>>>
>>>
>>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

[-- Attachment #2: Type: text/html, Size: 7204 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-2 released
  2013-10-21 14:46                 ` David Personette
@ 2013-10-21 15:39                   ` Fred Stratton
  2013-10-21 16:38                     ` Fred Stratton
  0 siblings, 1 reply; 18+ messages in thread
From: Fred Stratton @ 2013-10-21 15:39 UTC (permalink / raw)
  To: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 3235 bytes --]

OK. I would have untarred in /tmp and mv'd files one by one otherwise.

Your route sounds better.

Thank you.

On 21/10/13 15:46, David Personette wrote:
> If you made a config backup, you can restore it by scp'ing it to your 
> router, and extracting it in /.
>
> IE: 'cd / && tar xvzf /root/backup-cerowrt-2013-10-06.tar.gz'
>
> -- 
> David P.
>
>
> On Mon, Oct 21, 2013 at 9:50 AM, Fred Stratton <fredstratton@imap.cc 
> <mailto:fredstratton@imap.cc>> wrote:
>
>     I have installed this build, but cannot access the web interface.
>     Am presently trying to determine how to reinstall the
>     configuration file from the cli, other than item by item, so I can
>     attempt to rebuild the build from within. Have reverted to earlier
>     build for now to regain internet access.
>
>
>     On 21/10/13 13:22, David Personette wrote:
>>     I'm not sure what's changed but 3.10.17-2 is working for me, so far.
>>
>>     Was anyone paying attention to nftables (iptables replacement)? I
>>     just saw that it was merged into net-next. On the LTS 3.10.x it
>>     won't have any impact for now, and apparently there's a backwards
>>     compatibility utility to still process iptables rules...
>>
>>     -- 
>>     David P.
>>
>>
>>     On Mon, Oct 21, 2013 at 5:26 AM, David Personette
>>     <dperson@gmail.com <mailto:dperson@gmail.com>> wrote:
>>
>>         FYI: direct changes to the /overlay aren't noticed by the
>>         kernel, you have to reboot first. I can't say that I'm an
>>         expert, I've just poked around at it. I just deleted the
>>         whole directory (IE: rm -rf /overlay/etc/uci-defaults). Upon
>>         reboot the entire directory is reverted to the contents of /rom.
>>
>>         -- 
>>         David P.
>>
>>
>>         On Mon, Oct 21, 2013 at 12:11 AM, Michael Richardson
>>         <mcr@sandelman.ca <mailto:mcr@sandelman.ca>> wrote:
>>
>>
>>             David Personette <dperson@gmail.com
>>             <mailto:dperson@gmail.com>> wrote:
>>                 > 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.
>>
>>             How do I see/delete the mark in the /overlay that marks
>>             the file in the /rom as
>>             deleted?
>>
>>             --
>>             ] Never tell me the odds!   | ipv6 mesh networks [
>>             ]   Michael Richardson, Sandelman Software Works        |
>>             network architect  [
>>             ] mcr@sandelman.ca <mailto:mcr@sandelman.ca>
>>             http://www.sandelman.ca/        |   ruby on rails    [
>>
>>
>>
>
>
>     _______________________________________________
>     Cerowrt-devel mailing list
>     Cerowrt-devel@lists.bufferbloat.net
>     <mailto:Cerowrt-devel@lists.bufferbloat.net>
>     https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>


[-- Attachment #2: Type: text/html, Size: 11233 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-2 released
  2013-10-21 15:39                   ` Fred Stratton
@ 2013-10-21 16:38                     ` Fred Stratton
  2013-10-21 17:18                       ` David Personette
  0 siblings, 1 reply; 18+ messages in thread
From: Fred Stratton @ 2013-10-21 16:38 UTC (permalink / raw)
  To: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 3757 bytes --]

Your suggestion worked as expected, but could not get luci up and 
running. Do wonder if this is related to the aforementioned 
non-functionality of the lightweight web server, which is accessed 
initially.


On 21/10/13 16:39, Fred Stratton wrote:
> OK. I would have untarred in /tmp and mv'd files one by one otherwise.
>
> Your route sounds better.
>
> Thank you.
>
> On 21/10/13 15:46, David Personette wrote:
>> If you made a config backup, you can restore it by scp'ing it to your 
>> router, and extracting it in /.
>>
>> IE: 'cd / && tar xvzf /root/backup-cerowrt-2013-10-06.tar.gz'
>>
>> -- 
>> David P.
>>
>>
>> On Mon, Oct 21, 2013 at 9:50 AM, Fred Stratton <fredstratton@imap.cc 
>> <mailto:fredstratton@imap.cc>> wrote:
>>
>>     I have installed this build, but cannot access the web interface.
>>     Am presently trying to determine how to reinstall the
>>     configuration file from the cli, other than item by item, so I
>>     can attempt to rebuild the build from within. Have reverted to
>>     earlier build for now to regain internet access.
>>
>>
>>     On 21/10/13 13:22, David Personette wrote:
>>>     I'm not sure what's changed but 3.10.17-2 is working for me, so far.
>>>
>>>     Was anyone paying attention to nftables (iptables replacement)?
>>>     I just saw that it was merged into net-next. On the LTS 3.10.x
>>>     it won't have any impact for now, and apparently there's a
>>>     backwards compatibility utility to still process iptables rules...
>>>
>>>     -- 
>>>     David P.
>>>
>>>
>>>     On Mon, Oct 21, 2013 at 5:26 AM, David Personette
>>>     <dperson@gmail.com <mailto:dperson@gmail.com>> wrote:
>>>
>>>         FYI: direct changes to the /overlay aren't noticed by the
>>>         kernel, you have to reboot first. I can't say that I'm an
>>>         expert, I've just poked around at it. I just deleted the
>>>         whole directory (IE: rm -rf /overlay/etc/uci-defaults). Upon
>>>         reboot the entire directory is reverted to the contents of /rom.
>>>
>>>         -- 
>>>         David P.
>>>
>>>
>>>         On Mon, Oct 21, 2013 at 12:11 AM, Michael Richardson
>>>         <mcr@sandelman.ca <mailto:mcr@sandelman.ca>> wrote:
>>>
>>>
>>>             David Personette <dperson@gmail.com
>>>             <mailto:dperson@gmail.com>> wrote:
>>>                 > 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.
>>>
>>>             How do I see/delete the mark in the /overlay that marks
>>>             the file in the /rom as
>>>             deleted?
>>>
>>>             --
>>>             ] Never tell me the odds!     | ipv6 mesh networks [
>>>             ]   Michael Richardson, Sandelman Software Works      
>>>              | network architect  [
>>>             ] mcr@sandelman.ca <mailto:mcr@sandelman.ca>
>>>             http://www.sandelman.ca/        |   ruby on rails    [
>>>
>>>
>>>
>>
>>
>>     _______________________________________________
>>     Cerowrt-devel mailing list
>>     Cerowrt-devel@lists.bufferbloat.net
>>     <mailto: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


[-- Attachment #2: Type: text/html, Size: 12992 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-2 released
  2013-10-21 16:38                     ` Fred Stratton
@ 2013-10-21 17:18                       ` David Personette
  2013-10-21 18:23                         ` Dave Taht
  0 siblings, 1 reply; 18+ messages in thread
From: David Personette @ 2013-10-21 17:18 UTC (permalink / raw)
  To: Fred Stratton; +Cc: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 3626 bytes --]

I hadn't tried the web interface... I only use it for updates (since the
command line sysupgrade is broken) and to create config backups.

-- 
David P.


On Mon, Oct 21, 2013 at 12:38 PM, Fred Stratton <fredstratton@imap.cc>wrote:

>  Your suggestion worked as expected, but could not get luci up and
> running. Do wonder if this is related to the aforementioned
> non-functionality of the lightweight web server, which is accessed
> initially.
>
>
>
> On 21/10/13 16:39, Fred Stratton wrote:
>
> OK. I would have untarred in /tmp and mv'd files one by one otherwise.
>
> Your route sounds better.
>
> Thank you.
>
> On 21/10/13 15:46, David Personette wrote:
>
>  If you made a config backup, you can restore it by scp'ing it to your
> router, and extracting it in /.
>
>  IE: 'cd / && tar xvzf /root/backup-cerowrt-2013-10-06.tar.gz'
>
> --
> David P.
>
>
> On Mon, Oct 21, 2013 at 9:50 AM, Fred Stratton <fredstratton@imap.cc>wrote:
>
>>  I have installed this build, but cannot access the web interface. Am
>> presently trying to determine how to reinstall the configuration file from
>> the cli, other than item by item, so I can attempt to rebuild the build
>> from within. Have reverted to earlier build for now to regain internet
>> access.
>>
>>
>> On 21/10/13 13:22, David Personette wrote:
>>
>>  I'm not sure what's changed but 3.10.17-2 is working for me, so far.
>>
>>  Was anyone paying attention to nftables (iptables replacement)? I just
>> saw that it was merged into net-next. On the LTS 3.10.x it won't have any
>> impact for now, and apparently there's a backwards compatibility utility to
>> still process iptables rules...
>>
>> --
>> David P.
>>
>>
>> On Mon, Oct 21, 2013 at 5:26 AM, David Personette <dperson@gmail.com>wrote:
>>
>>> FYI: direct changes to the /overlay aren't noticed by the kernel, you
>>> have to reboot first. I can't say that I'm an expert, I've just poked
>>> around at it. I just deleted the whole directory (IE: rm -rf
>>> /overlay/etc/uci-defaults). Upon reboot the entire directory is reverted to
>>> the contents of /rom.
>>>
>>> --
>>> David P.
>>>
>>>
>>> On Mon, Oct 21, 2013 at 12:11 AM, Michael Richardson <mcr@sandelman.ca>wrote:
>>>
>>>>
>>>> David Personette <dperson@gmail.com> wrote:
>>>>     > 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.
>>>>
>>>>  How do I see/delete the mark in the /overlay that marks the file in
>>>> the /rom as
>>>> deleted?
>>>>
>>>> --
>>>> ]               Never tell me the odds!                 | ipv6 mesh
>>>> networks [
>>>> ]   Michael Richardson, Sandelman Software Works        | network
>>>> architect  [
>>>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
>>>> rails    [
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>
>
>
> _______________________________________________
> Cerowrt-devel mailing listCerowrt-devel@lists.bufferbloat.nethttps://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

[-- Attachment #2: Type: text/html, Size: 11954 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-2 released
  2013-10-21 17:18                       ` David Personette
@ 2013-10-21 18:23                         ` Dave Taht
  0 siblings, 0 replies; 18+ messages in thread
From: Dave Taht @ 2013-10-21 18:23 UTC (permalink / raw)
  To: David Personette; +Cc: cerowrt-devel

Yea, that wasn't a release.

As a general rule the quality of my builds goes down exponentially
after 9PM. The timestamp on that build was 22:17.



On Mon, Oct 21, 2013 at 10:18 AM, David Personette <dperson@gmail.com> wrote:
> I hadn't tried the web interface... I only use it for updates (since the
> command line sysupgrade is broken) and to create config backups.

You can fix this bug by commenting out mod_simple_vhost in
/etc/lighthttpd/*.conf or waiting til I fix it in -3.

It is actually my hope sysupgrade is fixed in -2, but we'll see. Other
stuff in -2 was basic support for package signing, more entropy from
the wireless driver (courtesy felix), and some (non-working) mods to
finally support https in the config interface.

> --
> David P.
>
>
> On Mon, Oct 21, 2013 at 12:38 PM, Fred Stratton <fredstratton@imap.cc>
> wrote:
>>
>> Your suggestion worked as expected, but could not get luci up and running.
>> Do wonder if this is related to the aforementioned non-functionality of the
>> lightweight web server, which is accessed initially.
>>
>>
>>
>> On 21/10/13 16:39, Fred Stratton wrote:
>>
>> OK. I would have untarred in /tmp and mv'd files one by one otherwise.
>>
>> Your route sounds better.
>>
>> Thank you.
>>
>> On 21/10/13 15:46, David Personette wrote:
>>
>> If you made a config backup, you can restore it by scp'ing it to your
>> router, and extracting it in /.
>>
>> IE: 'cd / && tar xvzf /root/backup-cerowrt-2013-10-06.tar.gz'
>>
>> --
>> David P.
>>
>>
>> On Mon, Oct 21, 2013 at 9:50 AM, Fred Stratton <fredstratton@imap.cc>
>> wrote:
>>>
>>> I have installed this build, but cannot access the web interface. Am
>>> presently trying to determine how to reinstall the configuration file from
>>> the cli, other than item by item, so I can attempt to rebuild the build from
>>> within. Have reverted to earlier build for now to regain internet access.
>>>
>>>
>>> On 21/10/13 13:22, David Personette wrote:
>>>
>>> I'm not sure what's changed but 3.10.17-2 is working for me, so far.
>>>
>>> Was anyone paying attention to nftables (iptables replacement)? I just
>>> saw that it was merged into net-next. On the LTS 3.10.x it won't have any
>>> impact for now, and apparently there's a backwards compatibility utility to
>>> still process iptables rules...
>>>
>>> --
>>> David P.
>>>
>>>
>>> On Mon, Oct 21, 2013 at 5:26 AM, David Personette <dperson@gmail.com>
>>> wrote:
>>>>
>>>> FYI: direct changes to the /overlay aren't noticed by the kernel, you
>>>> have to reboot first. I can't say that I'm an expert, I've just poked around
>>>> at it. I just deleted the whole directory (IE: rm -rf
>>>> /overlay/etc/uci-defaults). Upon reboot the entire directory is reverted to
>>>> the contents of /rom.
>>>>
>>>> --
>>>> David P.
>>>>
>>>>
>>>> On Mon, Oct 21, 2013 at 12:11 AM, Michael Richardson <mcr@sandelman.ca>
>>>> wrote:
>>>>>
>>>>>
>>>>> David Personette <dperson@gmail.com> wrote:
>>>>>     > 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.
>>>>>
>>>>> How do I see/delete the mark in the /overlay that marks the file in the
>>>>> /rom as
>>>>> deleted?
>>>>>
>>>>> --
>>>>> ]               Never tell me the odds!                 | ipv6 mesh
>>>>> networks [
>>>>> ]   Michael Richardson, Sandelman Software Works        | network
>>>>> architect  [
>>>>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
>>>>> rails    [
>>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
       [not found] <5264020C.2030203@imap.cc>
  2013-10-20 16:18 ` Fred Stratton
@ 2013-10-20 16:25 ` Fred Stratton
  1 sibling, 0 replies; 18+ messages in thread
From: Fred Stratton @ 2013-10-20 16:25 UTC (permalink / raw)
  To: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 5323 bytes --]


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 <fredstratton@imap.cc 
> <mailto:fredstratton@imap.cc>> 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
>>     <fredstratton@imap.cc <mailto: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
>>             -  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
>>         <mailto:Cerowrt-devel@lists.bufferbloat.net>
>>         https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>
>
>     _______________________________________________
>     Cerowrt-devel mailing list
>     Cerowrt-devel@lists.bufferbloat.net
>     <mailto:Cerowrt-devel@lists.bufferbloat.net>
>     https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>




[-- Attachment #2: Type: text/html, Size: 13373 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Cerowrt-devel] development build 3.10.17-1 released
       [not found] <5264020C.2030203@imap.cc>
@ 2013-10-20 16:18 ` Fred Stratton
  2013-10-20 16:25 ` Fred Stratton
  1 sibling, 0 replies; 18+ messages in thread
From: Fred Stratton @ 2013-10-20 16:18 UTC (permalink / raw)
  To: cerowrt-devel

[-- Attachment #1: Type: text/plain, Size: 5324 bytes --]



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 <fredstratton@imap.cc 
> <mailto:fredstratton@imap.cc>> 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
>>     <fredstratton@imap.cc <mailto: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
>>             -  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
>>         <mailto:Cerowrt-devel@lists.bufferbloat.net>
>>         https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>
>
>     _______________________________________________
>     Cerowrt-devel mailing list
>     Cerowrt-devel@lists.bufferbloat.net
>     <mailto:Cerowrt-devel@lists.bufferbloat.net>
>     https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>




[-- Attachment #2: Type: text/html, Size: 13377 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2013-10-21 18:23 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-20  5:41 [Cerowrt-devel] development build 3.10.17-1 released Dave Taht
2013-10-20  8:35 ` Fred Stratton
2013-10-20 13:12 ` Fred Stratton
2013-10-20 13:17   ` David Personette
2013-10-20 13:41     ` Fred Stratton
2013-10-20 13:55       ` David Personette
2013-10-21  4:11         ` Michael Richardson
2013-10-21  9:26           ` David Personette
2013-10-21 12:22             ` David Personette
2013-10-21 13:50               ` [Cerowrt-devel] development build 3.10.17-2 released Fred Stratton
2013-10-21 14:46                 ` David Personette
2013-10-21 15:39                   ` Fred Stratton
2013-10-21 16:38                     ` Fred Stratton
2013-10-21 17:18                       ` David Personette
2013-10-21 18:23                         ` Dave Taht
2013-10-21  1:22     ` [Cerowrt-devel] development build 3.10.17-1 released Dave Taht
     [not found] <5264020C.2030203@imap.cc>
2013-10-20 16:18 ` Fred Stratton
2013-10-20 16:25 ` Fred Stratton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox