Would be nice to conceptualise it from config file settings

Talk about Documentation
1

I have an instance of another openwrt router on the network (yun) with a static ip assigned on the router and so in the wan facing router in the dhcp file I actually want the section "domain" not the section "host" to stop the master router pushing a lease renew.... which is blocked and logged.

whereas the documentation describes the section in terms of using luci to set it up and not explaining why you would want domain rather than a host section....

obviously there is a complication in that at the uci layer the actual config files can be whatever you (the designer) like... let alone adding on the luci layer making the uci commands whatever you like..... whereas the config files are actually the root of the systems workings...

the parameters are described well but not at a section level as per what parameters apply for a section...

my theory is keep simple at the rock-solid syntax level of the actual config files! is it a good theory?

or maybe there is another page that describes it I have not seen? so maybe a highlight link to config file actual syntax?

and then talking of conceptualising, like is it a good idea to decrease the rekeying time in a very busy (much higher probability of hacker in vicinity) area, or increase it as it reduces probability of any clever snooping and replays? and come to think of it the lease renew over wifi possibly a weak point.

I think actually logging deauths would be a useful feature maybe that is getting of the documentation topic or maybe there is a way to do it already? That is to say logging a deauth that was not sent by router itself, if that's possible, only place to do it is on the router I think. Kismet logs a spoof but you want to know 100% the router did not inactivity or other reason send it.... signal strength obviously key... kismet may have logged that but need to know signal strength of a router sent death at client probably... its possibly an interactive process, client gets deauth, client double checks it was router sent it..... maybe that's wpa3?

just watched a few viddys of one of the prominent rf hackers on youtube, clever thought processes, lateral thinking!

2

Right, so the dhcp address range errors on yun were the broadcast of a dhcp request on the main router lan hitting the yun as well as main router on ethernet probably... so a valid error in the yun log... maybe some setting missing that blocks that error? but seems a valid error message.

(I have set yun up as allow all through from main router lan, accept, accept, accept, but static address and no dhcp on main lan side but dhcp still running on wifi side that is main firewalled as accept output from yun to wifi but reject all else so a single instance of dhcp picking up the error on lan side as the dhcp request was allowed in?)

and one reason you may need a domain section as well as a host section is the case where you power off the router and not the ethernet clients and they still have their dhcp lease, then you try to do a login to a client via hostname rather than ip but the router (after the reboot) does not know the name without a domain section until the next dhcp renew.

is that what the option dns=1 in the host section is? (like simple explanation is "removes need to define a domain section"?)

edit: yes, just checked the docs and actually I think it is, and adding it from luci sets that option to 1, but the docs do not explain the need for the domain section, nor that domain is a section, which for the case of a static lease you do need, but could define it as a host via luci which sets option dns=1 and it would work, I would rather have it better defined at the config file level.

But actually from a broader perspective if you ever reset the yun and it defaulted to dhcp request on the ethernet, would be better on main router to have a host section that could serve a fixed dhcp request... so really what I am talking about is probably a book on networking based around serious inside knowledge and experience of openwrt. Which might be the best book about networks ever LOL

Some docs that conceptualise the sections like the mpd docs do would helpful I reckon.

Saw a funny comment on some forum about how their router was so secure even they could not use it LOL

Also one of the Linux problems is that it moves so rapidly even best-distro (maybe manjaro) developers cannot keep up and and keep things static enough so it does not resemble that film "dark city".... (which the whole world seems somewhat like at the moment)

3

I wondered if maybe a luci bug, change the gtk rekey period to something, then set it back to blank and it looks like luci will set it to 600 the default but it actually blanks it instead.

I wondered what the rekeyings were... messed with the times and then they went away...

of course could have been a bug/feature in luci at the point I did that, and by carrying settings forward it carried the non set rekey period to later version that actually had a luci fix???

or not?

but yeah, a book on wireless and ethernet and ipv6 from perspective of a knowledgeable tricks expert but also from perspective of securing openwrt would be good!

Is IPV6 a good or a dead (like betamax) idea?

4

IPv6 is a necessity, especially for users outside of the US. It's already reality and in widespread use - alternatives solving the IPv4 address shortage don't exist. Even if someone would find the magic bullet and come up with an alternative design, it would take 10-15 years to become viable (widespread support around the world, replacing existing hardware, upgrading production software), while IPv6 is finally supported universally and works right now.

From my home router:
index
41.67% of the total traffic is IPv6

The missing pieces are some large CDNs not offering some of their services via IPv6 and cellular ISPs dragging behind (but even those are changing, albeit in a rather quirky way - a single /64, really.…?!) - and depending on your region some less 'agile' (to keep it PG-13) residential ISPs. but in general, the groundwork has been laid, it's working, today - only the last push is missing to get rid of IPv4. What's hurting acceptance, is the need to configure both protocols (and with NAT for IPv4, resulting in quite different rule sets) and that you can't do completely without IPv4 support at this point.

5

I can see why India/China may require ipv6, having some 60% of worlds population between them and perhaps only 20% of ipv4 addresses, here my ISP does not provide ipv6, I have turned ipv6 off on all my nodes, though arch seems keen on having an ipv6 address, NAT and local ipv4 address ranges seem to work OK for me.

As for the GTK rekeying, seems openwrt (21.01) defaults to group rekey once a day if you do not enter a value in the field. ? am I right? which is a big difference from a rekey every 600 seconds as the field greyed out value seems to imply is default.

I noticed 21.02 now no longer adds the option dns when setting a static address from luci.

I think a book may actually be very beneficial to openwrt as well as its users.

Anyway I'll stop going on about it maybe I'll have to start writing one.

6

Documentation is a forever challenge with nearly all OSS projects, particularly a very fast-mover like OpenWRT. There is pretty extensive documentation on the wiki and you can certainly expand upon that if you wish.

7

Yeah the documentation is not bad for openwrt! Like you say fast moving stuff is difficult to keep the docs up to date with. I was thinking of a broader book on the aspects of actual use cases, but that's only because I am in a very high traffic area and getting a few wifi problems, so I guess the aspect I am looking at is possibly counter-intelligence/counter-hacker. I am an applications writer and being distracted from that by wifi hassles on the lan, but all my nodes are 2.4ghz and not wpa3 so that is a fundamental weakness. Of course if I had the stock firmware on the router I would not be able to see the timings of the dropouts so it is of itself a kind of an accelerant of distraction LOL.