Doesn't really matter if you're not using the whole thing. Instead of thinking of it as a /12, think of it as 16 /16s, and you just use as many or as few as you want. It's my go-to range because it's roomy enough for anything and uncommon enough not to collide with some system's defaults.
I particularly stay away from 192.168.0/1.x because every time you plug a brand-new consumer-grade device into your network that's what it grabs before you have a chance to change it.
But honestly that is pretty much it, if we add 192.168.100.0/24 which cable-modems use for their admin/diagnostic access. So we have /16 - 3 which seems pretty okay since we effectively only will collide with other OpenWrts 
+1; I nowadays always try to attach to these in isolation first instead of adding them directly to the network (in spite of using 192.168.42.0/24)
Right, but if I'm already on that network on my laptop's wifi, and I plug a new router into an ethernet port on that laptop in order to configure it, I've got the same problem -- I've got to deal with the collision when I set up the ethernet port to talk to the new device. That or turn off the wifi which means I can't look stuff up or download firmware or whatever.
cerowrt was actually 172 and 42 based being as that seemed the cleanest place to put it. 42 is definately a lucky number for us. Also, I STRONGLY support mdns functionality by default, and would like very much the unicast extension for it be adopted.
i don't know to what extent homenet and hnetd ended up usable. However, this standard, at least, exists: https://datatracker.ietf.org/doc/html/rfc8375
Yes, stopped doing that, that's what I mean with "in isolation", WiFi off, just ethernet.
Yepp, that said most none routers nowadays are defaulting to DHCP which mostly does the right thing. TOS the turris derivative/add-on to OpenWrt helpfully logs and informs me when new MAC addresses show up, so I know what
See forgot all about the first octet... only 42 stuck with me, because it obviously is the correct answer.
172.42 is not in the private space though. it's 172.16 to 172.31
I guess you could do 172.16.42.0/24 but I still dislike the idea of using a single number as default, randomly distributing them is a way better solution.
Small poll of those who read this thread...
What devices on your LAN actually really and truly REQUIRE an ipv4? (for example Tp-link cheapest switches do not offer ipv6 administration, PS4 network requires ipv4...)
Try to make a list off the top of your head, I'm interested in why we couldn't just drop ipv4 entirely.
172.30.42.1/27 because we routed the wifi links and wanted to test CIDR.
ipv4 only:
my digiloggers power strip. Several esp32 devices. My mp3 player. My sony stereo.
I do think attempting an ipv6 only build and environment a good idea as to test transition technologies and especially if you also have a BDSM fetish, it's a real win.
hi everybody, fq codel more power for gigabit connection
i has installed the script of @ka2107
seems very good
config queue
option interface 'wan'
option verbosity '5'
option qdisc_advanced '1'
option qdisc_really_really_advanced '1'
option egress_ecn 'NOECN'
option squash_ingress '1'
option squash_dscp '1'
option debug_logging '1'
option ingress_ecn 'ECN'
option linklayer 'ethernet'
option overhead '44'
option download '56000'
option upload '16000'
option qdisc 'fq_codel'
option script 'fq_codel_plus_layer_cake.qos'
option iqdisc_opts ''
option eqdisc_opts 'egress diffserv4'
option enabled '1'
root@OpenWrt:~# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1518 ta rget 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
Sent 3698612244 bytes 6894406 pkt (dropped 0, overlimits 0 requeues 56)
backlog 0b 0p requeues 56
maxpacket 7590 drop_overlimit 0 new_flow_count 31447 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev lan1 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan2 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan3 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan4 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 8008: dev wan root refcnt 2 bandwidth 16Mbit diffserv4 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 44
Sent 895410286 bytes 2078081 pkt (dropped 1842, overlimits 1259268 requeues 0)
backlog 0b 0p requeues 0
memory used: 252640b of 4Mb
capacity estimate: 16Mbit
min/max network layer size: 28 / 1500
min/max overhead-adjusted size: 72 / 1544
average network hdr offset: 14
Bulk Best Effort Video Voice
thresh 1Mbit 16Mbit 8Mbit 4Mbit
target 18.2ms 5ms 5ms 5ms
interval 113ms 100ms 100ms 100ms
pk_delay 0us 437us 131us 1.2ms
av_delay 0us 42us 7us 208us
sp_delay 0us 4us 5us 4us
backlog 0b 0b 0b 0b
pkts 0 1114714 188 965021
bytes 0 734478305 16920 163685573
way_inds 0 7695 0 60408
way_miss 0 25603 188 817
way_cols 0 0 0 0
drops 0 1842 0 0
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 0 1 0 0
bk_flows 0 1 0 0
un_flows 0 0 0 0
max_len 0 18168 90 6056
quantum 300 488 300 300
qdisc ingress ffff: dev wan parent ffff:fff1 ----------------
Sent 835334681 bytes 1263195 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev br-lan root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc htb 1: dev ifb4wan root refcnt 2 r2q 10 default 0x10 direct_packets_stat 0 direct_qlen 32
Sent 903494515 bytes 1262437 pkt (dropped 649, overlimits 192137 requeues 0)
backlog 0b 0p requeues 0
qdisc fq_codel 110: dev ifb4wan parent 1:10 limit 1001p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
Sent 903494515 bytes 1262437 pkt (dropped 649, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 14590 drop_overlimit 0 new_flow_count 201329 ecn_mark 0
new_flows_len 1 old_flows_len 5
root@OpenWrt:~#
anyone tell me is the good result ?
In my opinion, what's needed to make OpenWrt more approachable for the average user is an initial configuration wizard. Zero-config would be even better, but such a wizard would at least put OpenWrt on par with commercial solutions. Steps would include:
An optional easy to use on/off switch style setup for a few key packages users might want to use (with their own wizards as needed). Might include wireguard, adblocker, samba, some sort of graphical statistics, etc.
Bonus points for mobile apps that can do any or all of this
Throw in automated or semi-automated updates and you're really competed with the ease of use of many commercial products.
Yes to any sort of hardware offload for shaping or whatever is needed to handle 1 Gbps!
Maybe enable band steering or make it easier to use?
I had a fairly dispiriting discussion with Ted Lemon, who said that the biggest problems with hncpd were:
I actually think ipv4 these days is the real sadomasochists dream. It's so broken, who doesn't love NAT on the router behind NAT on the customer premises ISP device behind CG-NAT at the central office and a ban on your IP because the CG-NAT public IP has been doing "Naughty things" to Amazon or Startpage or craigslist or your favorite gaming server (because even "normal" things when 10,000 people are aggregated behind a single IP looks like a DDoS). Not to mention port forwarding for games, or installing UPnP daemons to automatically punch holes in your firewall and let the bad guys bots in. Not to mention that the address space is so dense that you get about 1000 probes an hour to various ports? Also the magic of STUN and SIP/SDP and collisions between your LAN and the corporate LAN you're VPNing into, and on and on and on.
Let's face it, if you have an Ipv6 only LAN and are talking to IPv6 services what happens is there is no NAT anywhere, as soon as you plug a device in it knows where the router is, who the DNS is, and makes itself an IP address which is guaranteed not to conflict with anything else on the network. Interactive streams flow end-to-end effortlessly, and typically your device automatically churns through privacy addresses making it at least marginally more complex to track individual devices. When you have to talk to ipv4 endpoints is the pain point, but as with T-Mobile it actually can work extremely well to let the ISP invest in some beefy devices to handle NAT64.
The biggest problem is the stuff like the sony stereo or the "smart" TV or the TP-Link 8 port switches or whatever that still aren't operating in the 21st century. Heck even my Amcrest cameras have IPv6 support.
Welcome to my life. I'm on fiber, but my (small) ISP hasn't had the courage (or knowledge or time) to turn up IPv6.
So I can't use Hurricane Electric's tunnelbroker because of the CGNAT, and I had to stand on my head to get a static IPv4 address... Sigh.
Nevermind previous post (deleted), I figured it out.
As for giving the new or average user a better experience: Make a list of the good and the bad of other OEM/vendor GUI and features. Maybe we can try and combine those into "one perfect GUI". For the experienced/power user, they can always SSH into the router and use the CLI.
That last option is actually what I really missed in the Mikrotik RouterOS implementation.
But to get a better GUI, what I personally am missing is good documentation about how to add/code add-ons. As example: I would like to add a luci-protoco for XFRM devices. But I need to spend too much time looking at the code for let's say a GRE implementation to figure out how to do that...which means: I actually don't do it and use the CLI myself.
All of my iot devices. Cameras, smart bulbs, and vacuum cleaner don't use IPv6.
Also the tp-link managed switches and the Siemens SIP phone.
It does seem like it's largely "things". It's annoying too because things are precisely the stuff that really needs to start using IPv6. My grandstream SIP ATA handles IPv6 nicely. All my smart bulbs etc are ZigBee.
To put some counter to this, most of the stuff has acceptable solutions by now. And one thing IPv4 has going for it is that it is much easier to reason about it. For example google's insistence to not implement dhcpv6 is causing issues, with dhcpv6 upgrades would be much easier and sites that want central management/IP assignment could still do so.
Then we have the issues around "privacy addresses" (both helpful and not so helpful) that partly interfere with port rules in the firewall. (And it can be argued whether the default for IPv6 should be block or accept/forward all remotely initiated connections).
Interestingly, as if things would not be confusing enough the main OSes deal quite differently with privacy extensions...
I do not disagree that Ipv6 is required for the future, but for may/most home networks IPv4 is plenty sufficient, with NAT being admittedly the one big issue.
But that is also a boon, as it makes tracking by IP address harder. That is where IPv6 privacy extensions seem to shine, with their short life times, except the hypothetical tracker can simply ignore the interface identifier part of the address and use the fact that the prefix typically is at least as stable as IPv4 address assignments were (even CG-NAT tries to keep users on the same public IP address). If your ISP recycles prefixes like IPv4 addresses before IPv6 is not offering that much over public dynamic IPv4s, no?
If you want the firewall to block based on port numbers you have the same issue with IPv6, no? The firewall will need to be configured to allow remote connections in for games to work (admittedly without the need for port-remapping that is a bit easier).
Unless you decided to distribute that information via DHCPv6, IIRC android devices will ignore that...
Which is a thread model that did not exist with IPv4 as effectively the external IP address was more of a "prefix" than "interface ID" , but for home networks with few devices that still allows quite successful tracking (the privacy extensions only really fix the optimistic/naive initial SLAAC approach of encoding the network MAC address into the interface ID).
IMHO IPv6 suffers a bit from second system syndrome... be that as it may it is unavoidable and its warts are being addressed (stable privacy addresses).