I have seen that taster of user interface of Turris Omnia router and I just wounder that in both WAN and LAN interfaces there is no sign of IPv6 settings.
It is defined for computers to prefer IPv6 over IPv4 when available (by some RFC don’t remember the number from top of my head). And even that there is no such preference defined for user or user settings, it would be good to have IPv6 settings directly in place of respective interface and presumably on top (before IPv4) to reflect importance of IPv6 in “future internet”. It is not an advanced thing, it is the basic thing.
Another thing, in Wi-Fi tab there is a password field. I suppose that it is the WPA-2 PSK, however there are another “safe” AUTH methods, for example I do have RADIUS (EAP) in place. I suppose that Turris is capable of handling that out of the box, OpenWRT can (not out of the box with lite version of hostapd).
I can’t also see VLAN setting on both interfaces and other more advanced stuff. I can only suppose that it is hidden somewhere in Advanced settings, however concerning target audience I suppose to find all the things at its respective interfaces, in system tab (in case of things concerning router itself) or some service tab for non-crucial services like DLNA or whatever. If you are spending 200 bucks on router you probably are advanced user, so advanced tab doesn’t make much of a sense.
Last small thing, you probably want to have a ComboBox for language selection if you want to have ambition on international market.
Would it be possible to place some dummy user interface some where on the web (without no actual settings done on backend, of course)?
Anyway, I wish you a high amount of sales, I’m huge fan of what you are doing. I’ve already bought one box for myself and I’ll try to convince people in our community ISP to use it in production network. I hope that you will be able to go to open market after indiegogo campaign. I know that it is still work in progress, but what is a the better time to shape it a little.
Hello, the user interface you have seen is meant for users who knows almost nothing about how the networks work. Its primary goal is to let those users do the basic setup of their Omnia without much hassle. I hope that’s a sufficient answer for not having there advanced things as radius.
For experienced users there will be another web interface called LuCI. I think if you know OpenWrt you have seen LuCI already. There you can do almost everything and for the rest there is still SSH.
Hello, I didn’t know that in time of posting, then it is OK, I guess to not have there all the options. However the IPv6 thing stays. Even for the networking primer, some sort of IPv6 settings should be present. At least the method used on each interface (WAN: auto, DHCPv6-PD, RA, static; (W)LAN: DHCPv6 stateful/stateless, RA, passthrough). Either way IPv6 settings should be present and should be above IPv4s, simply to show its importance.
Out of the box router also should come with IPv6 enabled and with announcing local IPv6s when no public prefix is detected. Also please don’t ship the router with those lite versions of hostapd and without wpa-suplicant like OpenWRT is. Turris does have enough storage and memory so it shouldn’t be a problem.
I have the same opinion as hunekm concerning IPv6. Many ISP’s say that the users do not ask an IPv6 connectivity and therefore it is needless.
It is time to show the IPv6 is normal, is available for years, offers more possibilities as IPv4 (eg. as much public addresses as I need for all my devices) and users can ask their providers for IPv6. I mean that a basic IPv6 settings should be available in device wizards including very simple ones like the Foris. The device status page included in web based management should be able to display IPv6 details too.
I use IPv6 protocol at my home in EU for 3 years and I plan to buy Turris Omnia (beside other things) because it fully supports IPv6. I do not understand why they all (providers, customers, project managers) pretend the IPv6 either does not exist or it is something uncertain in very far future.
OK, we will think about some ipv6 settings in Foris. Just to clarify the rest I must say ipv6 is enabled by default, and we use the full version of wpad.
Martin, good to hear you will support IPv6. I use OpenWRT for a very long time with dnsmasq and radvd. So I have IPv6 at home. My ISP does not support IPv6 but I have SIXXS tunnel, works very smoothly for a few years now. It would be nice to enable that scenario to not so experienced users.
The IPv6 works out of the box without any configuration required. In case your ISP requires static configuration, you can configure static IPv6 assignment together with IPv4 settings in the Foris web interface. For the LAN setting, there’s actually nothing to set up regarding IPv6, since there is no NAT so no option to choose internal address range.
The only thing that is probably missing is the default firewall settings regarding IPv6. Current setup prevents any unsolicited IPv6 connections from the Internet, which break end-to-end principle. There could be a simple radio switch to change the firewall to partially open (say TCP and UDP ports bigger than 10000) or to fully open IPv6 firewall.
Putting IPv6 settings above IPv4 settings in the web interface will not make IPv6 more widely deployed. Anybody who wants to set up IPv6 can already set it up with current state of management UI.
Actually there should be some settings. Even that for most of the users, default settings should be sufficient (not the firewall issue - that is nasty). There could be cases in which it may fail. There might be for example networks in which customer might obtain only one /64 prefix, then NDP had to be used (even that it is bad idea, that is nothing else end user can do). So generally there are at least 3 cases how router can obtain prefix: SLAAC+NDP, DHCPv6+NDP and DHCPv6-PD.
Next settings could be use of privacy extension: random/semi-random/MAC related addresses. Look for example on Android in which privacy extension is enforced with no setting - huge pain in the ass, especially when you’re trying to establish static routes.
On LAN part you also have got several option how to distribute IPv6 addresses and DNS. Namely: SLAAC (w/o DNS or with), stateless or stateful DHCPv6 or you might want to sub allocate prefix to another router in the network via DHCPv6-PD.
I thing otherwise. By putting IPv6 above IPv4 you are stating priorities. When BFU would see some IPv6 stuff he/she would at least ask what is that. And because some ISP (like your anet) does say that no one is asking for IPv6, so it is not priority. I would even place big red cross on default page with smth like “No IPv6 available, ask your ISP for settings.” This way at least at ISP’s hotline people would know that something like IPv6 exist.
There might be for example networks in which customer might obtain only one /64 prefix, then NDP had to be used (even that it is bad idea, that is nothing else end user can do).
In that case, the ISP should fix its network. NDProxy is nasty hack that does not work very well and should not be supported, because it only makes the whole IPv6 unstable thus rendering bad user experience with IPv6. There is no real reason ISP couldn’t assign enough addresses for any customer. The only usable configuration of CPEs is via DHCPv6-PD or static configuration – former supported out-of-the box, latter available in the Foris web interface.
Next settings could be use of privacy extension: random/semi-random/MAC related addresses.
Why should a router use privacy extension? It barely moves between networks and its address is always detectable using traceroute. I doubt enabling privacy extensions is even possible in OpenWRT.
On LAN part you also have got several option how to distribute IPv6 addresses and DNS. Namely: SLAAC (w/o DNS or with), stateless or stateful DHCPv6 or you might want to sub allocate prefix to another router in the network via DHCPv6-PD.
Out of the box, the router support all address assignment scenarios. Switching to stateless-only or statefull-only is trivially possible via LuCI. And even sub-allocating works out-of-the box Again, trivially configurable via LuCI.
I thing otherwise. By putting IPv6 above IPv4 you are stating priorities. When BFU would see some IPv6 stuff he/she would at least ask what is that. And because some ISP (like your anet) does say that no one is asking for IPv6, so it is not priority. I would even place big red cross on default page with smth like “No IPv6 available, ask your ISP for settings.” This way at least at ISP’s hotline people would know that something like IPv6 exist.
This could be true if we we talking about new batch of say, d-link routers which would be sold in series of billions. This is a router for 3 thousand geeks around the globe, so let’s face the truth, even if every single of them asked their ISP about IPv6 support, it would still be „no one asking for IPv6“.
I believe that current state of IPv6 support is functional, simple and fully logical (apart from the firewall issue). There’s no need to spoil the Foris interface with all functions that are available in LuCI, the reason for the Foris interface is to have something lightweight to do only the essential setup of the router.
No argument on NDP being nasty, however as end user you cannot do much about it. NDP is sort of last resolve how to get native IPv6. For example I’m currently in the network w/o DHCPv6 (only RA). Network administrator never planted to allocate prefixes and no routers should be present in the network. So generally no flaw in design, but I’ve connected router to the network. In such case getting IPv4 is easy by NAT. Getting IPv6 is harder, there are generally 3 ways.
Use NDP for letting RA and ND packets trough. In OpenWRT it doesn’t work even when enabling relay option in LuCI, you had to manually modify dhcp config file and add “option master ‘1’” to get RA in LAN. To get actual forwarding working stable enough, you had to also add static routes in kernel table. NDP sometimes mess up so you are waiting for IPv6 connection to time out before switching back to IPv4. I’ve used BIRD6 for this job, but it might be bit overkill.
You convince network admin to either get DHCPv6-PD working, or to assign you your own /64(+) prefix and let you propagate it through OSPFv3 (static routes are not the option if network admin is not suicidal).
You resign on getting native IPv6 and either get yourself a tunnel or stick with IPv4.
Long story shot, by yourself only solutions 1 and 3 are possible and I personally prefer getting native address over tunneled one. I’m not considering bridging an option because I had to hide devices under the one IEEE 802.1x login and there might be single device limitation on switch port. So even that NDP still has got experimental status in RFC, its support could be vital for some networks. And getting easy UI on its settings would be better than spending several hours studying OpenWRTs mostly outdated documentation about what went wrong (I’m new to OpenWRT so it took me days).
I don’t like privacy extension either so as long it stays turned off, I’m happy about it.
I think that even in Forris user should be given those option, maybe even with some hints for which situation which option would be ideal (more routers in the network → DHCPv6-PD, outdated windows → stateless DHCPv6, etc.).
I think of these settings as essential. I’m not saying that it should be present there as only bunch of abbreviations, no one would understand, but user should be at least able to choose its use case and possibly edit some options if auto detection fails.
Thanks for confirmation that NDProxy (please, don’t mix it with NDP - protocol) is broken and does not work well. Yes, I think it’s much better to have no IPv6 than broken IPv6, and since NDProxy mode is broken, I don’t support it.
You convince network admin to either get DHCPv6-PD working, or to assign you your own /64(+) prefix and let you propagate it through OSPFv3 (static routes are not the option if network admin is not suicidal).
If you’re the one of few users that use a router, the static routing actually works very well. If connecting router is typical usage scenario, then the admin should deploy DHCP-PD.
I think that even in Forris user should be given those option, maybe even with some hints for which situation which option would be ideal (more routers in the network → DHCPv6-PD, outdated windows → stateless DHCPv6, etc.).
As I said every supported address assignment scenario is enabled out of the box, including DHCPv6-PD. They are orthogonal and work in paralel very well. User intervention is only needed only when an user wants to disable something. This is certainly nothing essential to router setup. I personally never found any reason why I should disable any provided address assignment mode.
Note - there has been a lot of work re: IPv6 and mDNS in the Homenet group. Their goal is to have self-configuring connections between multiple routers that may wind up in a home. If all routers speak Homenet, they’ll configure themselves sensibly. If some routers only do NAT (with double-natting in parts of the network), the Homenet routers will do the right thing.
You may not have time to do homenet by the first ship date, but it’s running in OpenWrt now, so I hope you look. You can read more at:
Hello,
The same thing was told me by the provider, but for some reason it doesnt work for me. Ive got IPv6 prefix from ISP, but I am not so sure, where to write it… WAN6 automatically doesnt get IP assigned (as my provider told me, that should be that way - just plug the router in). I have only this in my network config
Could you pass the output of the ifconfig or ip addr sh without those y (at least partialy)? For example the first two parts determine your ISP, not you. If you are worried about privacy, you can rather change some part of address (but not the end of your prefix of course). That way as you have posed, there is no way of telling if there is the prefix given to you by ISP in any of those addresses.
Please post output of:
ip addr sh
ip -6 route sh
So we can determine the GW address. tcpdump of the router advertisement and DHCPv6 would be also helpful.
With the yyyy:yyyy:… address there is nothing we can do.
Thanks for reply. Ive got 2a00:ca8:… prefix from ISP, but none of IPv6 visible on router matches:
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 532
link/ether d8:58:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 89.29.xxxxx/30 brd 89.29.xx.xxx scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::da58:d7ff:xxxx:3904/64 scope link
valid_lft forever preferred_lft forever
fdfe:4a76:xx94::/64 dev br-lan proto static metric 1024
unreachable fdfe:4a76:4994::/48 dev lo proto static metric 2147483647 error -113
fe80::/64 dev br-lan proto kernel metric 256
fe80::/64 dev ifb4eth1 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
I must read about tcpdump first, cant do dump from top of my head unfortunatelly…
The routing table suggest that you are not getting the router advertisement. If the tcpdump wouldn’t show any, it would mean that there is problem in your ISP network.
In such case you should inform them about the situation (no RA) and ask if it is intentional. If so, they should be able to provide you with:
Your inner network prefix (that /62 you wrote about)
Address for your WAN interface (typically /64 within /56 or /48 from which is your /62 allocated)
Address of gateway (in form either fe80:… or from the range of WAN interface address)
For automatic setup parameters would be obtained: 3 - by RA, 2 - by SLAAC (RA) or DHCPv6, 1 - by DHCPv6-PD. However when you will not get RA, it could not proceed with autoconfiguration.
You can theoretically try to guess GW. For example I provide end users with /56 and I do have /48 for AP and VLAN (/44 for AP). So in my case:
User’s prefix: 2001:db8:1230:4500::/56
AP+VLAN prefix: 2001:db8:1230::/48
Prefix for WAN interface of CPEs: 2001:db8:1230::/64
GW’s address: 2001:db8:1230::1/64
If your ISP made you a static assignment and if you guess the GW address (and prefix for WAN), you could get IPv6 working by yourself. In theory.
Again, trivially configurable via LuCI.