1748 replies to this topic

[betacentauri]

All currently by OpenPli supported boxes have IPv6 support enabled:

openpli_master$ find meta* -name "*defconfig*" | xargs grep "CONFIG_IPV6 is"
openpli_master$ 

I build the patch and have tested it with IPv4. It works.

root@et8500:/var/volatile/tmp# netstat -pn
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 ::ffff:192.168.0.123:8001 ::ffff:192.168.0.112:40827 ESTABLISHED 891/enigma2

[athoik]

Usually I do "opkg remove kernel-module-ipv6 --force-depends" on my boxes (it makes telnet login faster).

 

Does this patch works with ipv6 kernel module removed?

 

PS. I do have only IPv4 from my provider.

Edited by athoik, 7 May 2015 - 19:14.

[pieterg]

If I remember correctly, we're building ipv6 support as a module on most(/all?) boxes, so users can choose not to load it, if they're experiencing problems.

 

I'd prefer the os to return an appropriately filled sockaddr struct, depending on the capabilities.

I think getaddrinfo is a cleaner solution, gethostbyname/gethostbyname2 are considered obsolete.

(there's only one thing I don't like about getaddrinfo, which is having to put the port number in a string...)

[WanWizard]

>30% of Belgium  ...  are accessing Google using IPv6, 99% of them natively.

 

I find that a bit on the high side. I happen to have been the government's network and security manager, and member of the government taskforce on IPv6.

 

The two major providers, Belgacom (now Proximus) and Telenet both don't do IPv6 yet, they are still in trial phase. Their new equipment however is all dual-stack and IPv6 enabled, so internally you can communicate on IPv6 using link-local addresses. Most of the Belgian government services are not IPv6 enabled (the self-hosted services of Flemish being the exception), and it has turned out to be difficult to mobilize the ISP's. Some of them were convinced for years (and maybe even now) that CGNAT was the way to go, and some even implemented it to work around the shortage of IPv4 adresses.

 

The issue to addess is that since most devices default to IPv6 on a dual stack, everything slows down, because every IP session setup is tried over IPv6 first (since you have a working stack and a valid address on the interface), before finally realizing there is no connectivity to the outside world, usually after a DNS timeout on the ISP router.

 

For this same reason, most companies have chosen to disable the IPv6 stack on Windows on their internal network. And as long as these companies are not switched internally (and why should they, 10.x.x.x is large enough for most?), these PC's will not do IPv6 when at home too.

 

It's all a big heap of chicken and eggs, and the last 15 years, everyone has tried to avoid having to do anything about this problem. And I wonder why. The older ones amongst us can clearly remember IPX. And switching from IPX to IP was, from a technology point of view, even more complex than v4 to v6. And still we did it, in large networks (in my case a world-wide one), without too many issues...

[pieterg]

I mean something like this (untested)

 0001-socket-use-getaddrinfo.patch   13.2KB   12 downloads

[adri]

Usually I do "opkg remove kernel-module-ipv6 --force-depends" on my boxes (it makes telnet login faster).

 

Does this patch works with ipv6 kernel module removed?

 

PS. I do have only IPv4 from my provider.

Athoik,

 

That is exactly what I have sometimes done, remove kernel-module-ipv6, to gets things connecting again.

Whether it's the fault of the OpenPLI box or my provider isn't really relevant, since I can't easily get the provider to change things.

I also have only IPV4 from the provider and they still can't offer IPV6, despite me asking them multiple times during the last few years.

 

Spacerat already tested with ipv6 modules removed and then it breaks and nothing works.

[adri]

If I remember correctly, we're building ipv6 support as a module on most(/all?) boxes, so users can choose not to load it, if they're experiencing problems.

 

I'd prefer the os to return an appropriately filled sockaddr struct, depending on the capabilities.

I think getaddrinfo is a cleaner solution, gethostbyname/gethostbyname2 are considered obsolete.

(there's only one thing I don't like about getaddrinfo, which is having to put the port number in a string...)

Pieterg,

 

I prefer that solution as well, since it won't break things with ipv6 modules removed or unloaded.

[SpaceRat]

Remove IPv4 and things break as well, so what?
Does anybody care about that problem?

[SpaceRat]

>30% of Belgium  ...  are accessing Google using IPv6, 99% of them natively.

I find that a bit on the high side.

That's what the Google Statistics say:
http://www.google.co...statistics.html

Also note the "per-country-adoption" page:
http://www.google.co...y-ipv6-adoption

Nothing makes me doubt those statistics could be wrong.
The patterns match:


>14% in Germany use IPv6 to access Google
Market shares for Kabel Deutschland and Unitymedia/KabelBW accumulate to 17.8%, out of the leading providers they are the ones that are connecting all or most of their new customers using DS-lite since 2012.
Rest assured that out of the 9.8% "others" also many if not most have to use DS-lite.

The leading provider with 42.3% market share is the one going to switch over from POTS/ISDN (with IPv4-only internet) to VoIP (With Dual Stack internet)
- most of his lines until the end of 2016 (That's next year, not in a decade or so!)
- all users at the most until the end of 2018

The provider "1&1" is on most cases just a reseller of the market leader. Lines that are resale from the market leader are already Dual Stack enabled.
o2 with 7.4% will turn into a pure reseller during the POTS/ISDN->VoIP switchover by agreement ...

Any doubt the 14% are exaggerated?
I rather guess the numbers would be mich higher even, if there was less IPv4-only junk like E2 out there, because Google can only count setups with working IPv6 connectivity and not those with setups borked to IPv4 only.

So why should I doubt that Belgium really has a minimum of ~30% IPv6 availability if the numbers for Germany are also reproducable correct?


Also keep in mind:
For the worldwide statistics, the interesting point isn't that IPv6 usage is at a disappointing 5.4% but that IPv6 usage grew from 2012 to now by a whopping >500%.


 

I happen to have been the government's network and security manager, and member of the government taskforce on IPv6.

You love to note that eh?
I have shaked hands with the former president of the Federal Republic of Germany, Johannes Rau, and with the former Federal Minister of Labour and Social Affairs, Norbert Blüm.
In addition, I have watched the Ministery of Silly Walks multiple times.

So what?

Since then, we have deported the largest part of our government from Bonn in Germany to Berlin in West-Poland, Johannes Rau died and we became the first nation with a neutrum as chancellor.

[SpaceRat]

Some of them were convinced for years (and maybe even now) that CGNAT was the way to go, and some even implemented it to work around the shortage of IPv4 adresses.

The one doesn't contradict the other.
Nobody ever planned to make a cold cut "IPv4 off -> IPv6 on".

Tele Columbus for example uses CGNAT as well. But they do so in addition to IPv6.
Glasfaser Deutschland also uses CGNAT, but with 6rd on top (Not the best choice, but compared to DS-lite also not the worst).

I have yet to see any provider roll out IPv6-only, they all also provide some kind of transition method for IPv4.
But all IPv4 transition methods have in common that they break incoming connectivity or that this aspect is that complicated to set up that it doesn't get offered to the customers.

That's why users depend on working IPv6 support on their devices.

 

The issue to addess

... by the users that fucked up their setup ...
 

is that since most devices default to IPv6 on a dual stack, everything slows down, because every IP session setup is tried over IPv6 first (since you have a working stack and a valid address on the interface), before finally realizing there is no connectivity to the outside world, usually after a DNS timeout on the ISP router.

There is no connection attempt being made if the target is a public AAAA and you only got link local addresses yourself.

The opposite is the case:
More and more users are experiencing network problems and slowdowns when servers appear to be IPv6-ready but arent't.

You can't make those users the benchmark that break everything up and try to maintain compatibility with broken setups by adding more and more faults.
Instead you have to ensure proper operation in a properly set up environment.

As the E2 box can handle IPv6 and the web interface can be connected via IPv6, dynamically created streaming URLs with target IPv6 addresses or target IPv6-only hostnames inside work (With this patch or using the streamproxy) and even must work, because that's the proper behaviour.

Without the patch, things are majorly fucked up:
You can connect the webif, grab a streaming link and it will blatantly fail, although the user made no single mistake.


 

It's all a big heap of chicken and eggs, and the last 15 years, everyone has tried to avoid having to do anything about this problem. And I wonder why. The older ones amongst us can clearly remember IPX. And switching from IPX to IP was, from a technology point of view, even more complex than v4 to v6. And still we did it, in large networks (in my case a world-wide one), without too many issues...

There we come to a point where we agree.

And the conclusion has to be:
Go out of the way for people that aren't ignorantly breaking their setups.
The current strategy of making bad admins happy is an increasing PITA for people that want to go on or even have to.
And the second group is constantly growing.

If necessary, enforcing IPv6 by changing
CONFIG_IPV6=m
to
CONFIG_IPV6=y
is more an option than to keep things broken, just to allow two people to continue breaking up their network without instant failure.

You wouldn't make UBIFS a module either on a box using it.

BTW:
Dream has by far passed us all.
They have worked heavily on dealing with the real problem, which is "lack of IPv6 support".

And website operators start to learn that IPv6 enabled web servers also solve more problems (e.g. customers not coming back when their IPv4 transition mechanism makes browsing the web using IPv4 a bad experience) than they cause. Install IPvFox or IPvFoo and you will notice more and more websites becoming available using IPv6.

Users like adri or athoik aren't left alone, they can be helped. But they shouldn't be allowed to be the reason for a much larger group of users experiencing problems in properly set up environments.
This thread "Using an E2 receiver with IPv6" doesn't have >4800 hits without reason.

[SpaceRat]

Has anyone tested pieterg's patch?

As long as it works I don't care about how it's done, it just has to be done.

The thing I noticed ...

The patch is implementing something ...

+#ifdef AI_ADDRCONFIG
+	hints.ai_flags = AI_PASSIVE | AI_NUMERICSERV | AI_ADDRCONFIG; /* only return ipv6 if we have an ipv6 address ourselves, and ipv4 if we have an ipv4 address ourselves */
+#else
+	hints.ai_flags = AI_PASSIVE | AI_NUMERICSERV; /* we have only IPV4 support, if AI_ADDRCONFIG is not available */
+#endif

... that gets removed in multiple patches on openembedded elsewhere.

AI_ADDRCONFIG doesn't seem to be available everywhere, so
no AI_ADDRCONFIG = no IPv6
doesn't seem to be a safe assumption.
But I might be wrong.

[malakudi]

Adding IPv6 support is nice and should be included in enigma2, but enigma2 code should work with IPv6 disabled in the kernel, for many reasons - one of them being choice. It should also run with IPv4 disabled if possible too.

 

Having said that, my experience for IPv6 only setup is really bad. Except google and some more sites, the content available for IPv6 only setup is minimal. In my business I have setup many SOHO installations with 2 or more internet links, using fail-over/load balance. This is easily done with IPv4 and NAT. With IPv6, well, it can't be done, full stop (unless you persuade your ISPs to do BGP peering with a SOHO installation - unlikely).

The problem with IPv6 is that those that really need it (ISPs) cannot enforce it and those that have to implement it in order to have a critical mass (content providers) usually don't care. Here in Greece, two ISPs offer dual-stack, but even on those two ISPs, some of their major sites (for OTENet, www.otenet.gr) don't offer IPv6 AAAA records.

I am afraid that IPv6 will never "take off". We will keep having CGNAT and those that really need a true IPv4 address (most people just surf the net and they don't care) will have to pay a few $$/€€ more and get their real IPv4 address - same shit like was happening to get a static ip.

[littlesat]

I think it is more important how thinks are done than simply pushing stuff with a disclaimer "it works for me".

 

At this moment I do not have a IPV6 environment so I'm not able to test Pieterg's suggestion.... Probably Pieterg is not able to test it as he has the same situation I have... .... So when someone with a IPV6 environment is able to test it???

[WanWizard]

As usual, you remain the stubborn German you are, Spacerat. You are right, the rest of the world is wrong, and everyone has to change to your way of thinking.

 

Whatever setup a user (or a company) has, and whatever the reason behind it, you will have to accept that it is there. Right or wrong. And you have to take it into account if you write software for hunderds of thousands of users, globally.

 

Fact remains that most recent OS installs by default come with a dual stack, and have an IPv6 link-local address. And fact remains that most broadband routers either don't do IPv6 at all, or do it, but either it's not configured, or their ISP doesn't provide an IPv6 connection.You can like it or not, but you'll have to live with it. Probably for years to come.

 

It's all very nice you have seem to have an idea of what you're doing, and get IPv6 through a tunnel even if your ISP doesn't support it. But you're a minority.

 

And it's great that Google sees IPv6 connections. It is an IPv6 pioneer, and on the receiving end of a large percentage of all connections. If you look at the amount of services available on the internet, and the poor number of them that have IPv6 connectivity, then you can only conclude that IPv4 isn't gone yet. And will not be for a very long time.

[SpaceRat]

At this moment I do not have a IPV6 environment so I'm not able to test Pieterg's suggestion.... Probably Pieterg is not able to test it as he has the same situation I have... .... So when someone with a IPV6 environment is able to test it???

As the point is "It has to work in an environment w/o IPv6 addresses" (And I have never said any different), testing it in your IPv4-only environment is a valid and even necessary test.

[pieterg]

AI_ADDRCONFIG doesn't seem to be available everywhere, so
no AI_ADDRCONFIG = no IPv6
doesn't seem to be a safe assumption.
But I might be wrong.

That's just the comments. (And my assumption there might be wrong)
But the code doesn't draw any conclusions based on the availibility of the flag, it just adds it when it is defined, because it speeds up things on broken setups.

(I don't intend to purposely break things, applications should not dictate policies imho)

[SpaceRat]

As usual, you remain the stubborn German you are, Spacerat. You are right, the rest of the world is wrong, and everyone has to change to your way of thinking.

No.
You are stubborn.
Google is wrong, IANA is wrong, ARIN is wrong, RIPE is wrong, APNIC is wrong, LACNIC is wrong, AVM is wrong, Cisco is wrong, everybody is wrong.

Just not that one former employee of the Belgium government (Does Belgium have a government at the moment, btw?).

 

Whatever setup a user (or a company) has, and whatever the reason behind it, you will have to accept that it is there. Right or wrong. And you have to take it into account if you write software for hunderds of thousands of users, globally.

Catching up user errors is nice ... as long as you do not need to break things in proper setups for it.

You can neither catch up the problems of people assigning fixed IPv4s to their boxes through /etc/network/interfaces
I've seen all so many setups break due to this silly configuration but it's nearly impossible to get that suggestion out of this world.
Be it, do it if you want, but nobody has ever cared about e.g. forcibly setting up a DNS server in such an environment if the user does it wrong.
Everybody is free to f*ck up his setup as much as he wants. But there can't be a demand for developers preventing the negative results of broken configs if that would break legit proper configs.


Why the hell the difference, just because you hate me?
E2 currently wouldn't work without an IPv4-stack so where is the difference in requiring a non-crippled TCP/IP stack?

I tell you: Because it was "SpaceRat" who posted that patch here.
I should have said nothing and just wait for betacentauri ...

 

Fact remains that most recent OS installs by default come with a dual stack, and have an IPv6 link-local address. And fact remains that most broadband routers either don't do IPv6 at all, or do it, but either it's not configured, or their ISP doesn't provide an IPv6 connection.

And fact is, it works without a problem <Full stop>.

 

You can like it or not, but

... Windows comes in exactly that configuration and works very well.
Users that get IPv6 can use it without a problem and users w/o do not have any disadvantage due to it.

But probably Microsoft is also wrong. That's why their operating system is such a big failure and runs on only 2% of all comuters.

Debian also comes Dual Stack be default, its Samba also requires that IPv6 is still there even if unused.
But Debian is also wrong.
The only clever dev is you.


Everything has been said, just not by everybody yet.
For me it's needless to continue wasting my time here.

You got the fix.
Apply it, come up with something better or let it be.

Preferably do it the OpenPLi-style:
1. Claim you do not have the time to develop fixes yourself (while having enough time for this bullshit discussion)
2. Beg for fixes from the oe-a and others who spend their time more useful
3a. Ignore the fixes
3b. Talk them to death
4. Claim nobody has provided you a patch
5. Call me an idiot

I don't care.
OpenPLi users can't be helped anymore.

bye.

Edited by SpaceRat, 8 May 2015 - 11:09.

[WanWizard]

You don't read. And as usual you get angry when you don't get your way.

 

If you have a dual stack Windows PC, and a broadband router that is also dual stack, but the WAN connection is IPv4 only, you WILL have problems.

 

When you want to connect (to let say Google), the DNS request will return AAAA records, and the PC will attempt to connnect on IPv6. Which will fail. And only after a long timeout it will switch to IPv4. The PC isn't aware that there is no route out of the LAN on IPv6.

 

And this is the reason why most people, consumers and businesses, disable the IPv6 stack in Windows if their network is not (end-to-end) IPv6 enabled.

 

Again, you can call this anything you want, fact remains it is there, and it is there to stay for quite some time.

 

And ignoring it because you think it's not right is sticking your head in the sand, and not helping all our users that are in that same position.

[malakudi]

Just for you I did the test:
No it doesn't work anymore if one forcibly removes IPv6 support.

But IMHO that's no problem:
The question should rather be if enigma2 is already ready for removing the almost legacy IPv4 stack and not the current IPv6 stack.

 

Spacerat, the problem with the diff you provided is exactly what I quote above. "But IMHO that's no problem". Well, it is a problem, IPv4 stack is not "legacy" but it is what is now used everywhere. IPv6 might be "current" as specification but what is the percentage of usage in IPv6 globally?

 

So, you can either provide a patch that doesn't brake enigma2 on IPV4 only kernels or accept the fact that the OpenPLi team cannot break current working setups just because "IMHO that's not problem".

 

In Windows I can disable ipv6 completely and I can expect all programs I am using to still work.

 

edit: If I remember well, the correct way handling both IPv6 and IPv4 protocol is sockaddr_storage. That structure can hold either ipv6 or ipv4 data, and you just do casting to sockaddr_in or sockaddr_in6. (RFC2553)

Edited by malakudi, 8 May 2015 - 12:24.

[adri]

 

BTW:
Dream has by far passed us all.
They have worked heavily on dealing with the real problem, which is "lack of IPv6 support".

 

 

At least Dream did a proper solution.

In the latest OE 2.2, there is a simple checkbox to completely disable all IPV6 on their STB.