Thanks again for your comments. They're reflected in the new draft: 
https://gist.github.com/richb-hanover/ec88b851c4da074e48003e6fe9276901

> On Jul 29, 2016, at 7:12 AM, Juliusz Chroboczek 
> <[email protected]> wrote:
> 
>> Should the procedure remain silent on the firewall? Or should people
>> just put all interfaces into the lan zone? Or something else?
> 
> Pleae leave it as it is, it's fine.  I'd remove the bits about making E0
> internal, it just confuses things -- if the router has a 4-port switch,
> it's not likely that getting an extra internal interface is likely to be
> a critical feature.

Done.

>>> If I were you, I'd explicitly tell hnetd that the E0 interface is external
>>> ("option mode external"), since I don't trust the edge detection mechanism.
> 
>> I think you mean E1 - that's what the instructions use for the wide area
>> interface.
> 
> It looks like one of us is confused.

It looks like it was me. :-) 

>> And 'option mode external' goes in /etc/config/network?
> 
> Yes, in the interface section.

I have updated E0 /etc/config/network to mention "option 'mode' 'external'"

>> And is there a man page for hnetd that gives other options?
> 
> https://wiki.openwrt.org/doc/uci/network#protocol_hnet_self-managing_home_network_hncp

Added to the External References section along with a link to RFC7788

>>> - before you start hacking, write down the IPv6 link-local address of
>>> the LAN interface, to make sure you can log in;
> 
>> Done. The newest draft also tells people to make backups :-)
> 
> Please tone it down -- no need to frighten people,

Actually, I'm writing this for a less knowledgeable audience. (Me, for example. 
I'm learning as I go along, with your kind assistance :-) 

My goal is to produce an approachable document that has a good balance between 
background information and "Just Do This". I want to produce the "guide" that I 
wish I had when I started with Homenet. That's why I'm also adding in bits of 
knowledge (in the External References, Troubleshooting Procedures, etc.) that 
might help other people get themselves out of trouble.

This is a corollary of your assertion at IETF the other day ("if it’s not 
implemented, it didn’t happen") It's also true that if no one can install it, 
it's not going to be tested in the real world. :-)

> and if things go wrong,
> you just boot into failsafe mode and either fix things or reset the router:
> 
>  https://wiki.openwrt.org/doc/howto/generic.failsafe

This is useful advice. There's now a link to the page in the Troubleshooting 
Procedures. 

<rant> That OpenWrt page is a primary example of the style of documentation I 
abhor. It's enough to make the shields come down over my eyes. Huge blocks of 
text. Starts with a description of what it does ("bypasses all 
configuration...") without initially saying *why* you might want to use it. 
Three alternative methods, giving equal prominence to a) the most common case 
that's easy and will work 99% of the time, b) a super-techie process (packet 
sniffer) and c) using a serial connection that most people don't have. In fact, 
I had never looked at that page until you recommended it, since it was so 
inscrutable, and I wasn't sure it would ever apply to me...</rant>

> Please use "sysupgrade -b backup.tar.gz" to do the backup -- I'd rather
> you didn't mention the web interface at all, I've found it to be more
> hassle than it's worth, and it's not included by default in the snapshot
> (unstable) builds.

I have added sysupgrade to the Backup procedure. But I like to recommend the 
LuCI GUI because:
        a) it gets the backup off the device onto my computer
        b) it date-stamps the backup
        c) it adds the router's name to the filename

>>> - you should review /etc/config/upnpd, and list the interfaces you want
>>> to allow NAT-PMP on.
> 
>> I'm not quite sure how that affects things. Where would NAT-PMP be
>> important in my home net?
> 
> It allows clients to perform port redirection automatically.  Firewalls
> are evil.
> 
> I also add the following to the firewall config:
> 
> config rule
>        option target 'ACCEPT'
>        option src 'wan'
>        option name 'Accept-v6'
>        option family 'ipv6'
>        option dest 'lan'
>        option dest_port '1024-65535'
> 
> Of course, since you've renamed wan and lan, you'll need to tweak the
> relevant tweakanda.

I have added both these to a "Next Steps" section since they're not core to 
switching to hnet. I don't know much about them, and will study them more when 
I get time.

>> And finally, a prosaic question: There is a -wide variety of single
>> quote usage in config files. Are there any places that quotes are
>> mandatory?
> 
> The syntax is the same as the shell's.  Actually, the config files are
> shell script fragments -- 'config' and 'option' are shell functions,
> defined in /lib/functions.sh.
> 
>> What is the best practice here?
> 
> Put single quotes everywhere, it avoids having to think about special
> characters.

Done.

> Thanks again for your work, Rich.
> 
> -- Juliusz

And thank you for your patience. 

Rich
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to