1748 replies to this topic

[SpaceRat]

Enable IPv6 for internal streaming, alternatively as patch ...
All credits go to betacentauri!

Attached Files

•  ipv6.diff.txt   2.88KB   9 downloads

[littlesat]

As far I can see this will break ipv4

[SpaceRat]

Why should it?

[littlesat]

For those who don't have ipv4 maybe...?

[SpaceRat]

You claimed it would break IPv4 and I said "Why should it?" ...
... I don't get why you claim so ...

To make it short:
It doesn't.

root@duo2 ~ # netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0 148920 ::ffff:[b]192.168.75.16:8001[/b] ::ffff:[b]192.168.75.20:18617[/b] ESTABLISHED

IPv6 sockets are downward compatible with IPv4 connections unless you set the IPV6_V6ONLY flag to 1/true, which the patch doesn't.

[SpaceRat]

BTW: The guy who did this fix doesn't even have IPv6 himself ...

[adri]

And this also works if no IPV6 is configured on the interface, or the IPV6 module stack has been removed or not loaded?

[SpaceRat]

I'm not sure what would happen IF that ever happens.
busybox works just fine with IPv6-Support enabled on an IPv4-only kernel (It just creates IPv4 sockets instead).

However, an IPv4-only kernel shouldn't exist anymore. Even DM500/DM800HD/DM800se/DM800seV2 can have IPv6-enabled kernels.
Erik Slagter has made the same assumption (= "Kernel HAS to have IPv6 support") elsewhere already.

Just do a

grep -r --include "defconfig" "CONFIG_IPV6 is not set" .

in your meta-brands to check if any box still has no IPv6 support at all.

[SpaceRat]

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]

In a properly setup environment ....

root@duo2 /media/autofs/Arbeitszimmer # netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 Duo2.fritz.box:https    quattro.fritz.box:27254 ESTABLISHED
tcp        0      0 Duo2.fritz.box:8001     quattro.fritz.box:27301 ESTABLISHED
tcp        0    128 Duo2.fritz.box:ssh      quattro.fritz.box:27222 ESTABLISHED
tcp        0      0 Duo2.fritz.box:58597    Igel.fritz.box:10005    ESTABLISHED
tcp        0      0 Duo2.fritz.box:49776    Solo2.fritz.box:8001    ESTABLISHED
tcp        0      0 Duo2.fritz.box:53020    Solo2SE.fritz.box:microsoft-ds ESTABLISHED   

none of the above connections is still using IPv4:

root@duo2 /media/autofs/Arbeitszimmer # netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 2001:4567:affe:0:21d:ecff:fe05:1234:443 2001:4567:affe:0:96de:80ff:fe6c:3456:27254 ESTABLISHED
tcp        0 125164 2001:4567:affe:0:21d:ecff:fe05:1234:8001 2001:4567:affe:0:96de:80ff:fe6c:3456:27301 ESTABLISHED
tcp        0      0 2001:4567:affe:0:21d:ecff:fe05:1234:22 2001:4567:affe:0:96de:80ff:fe6c:3456:27222 ESTABLISHED
tcp        0      0 2001:4567:affe:0:21d:ecff:fe05:1234:58597 2001:4567:affe:0:21e:bff:fe7a:789a:10005 ESTABLISHED
tcp        0      0 2001:4567:affe:0:21d:ecff:fe05:1234:49776 2001:4567:affe:0:21d:ecff:fe00:9abc:8001 ESTABLISHED
tcp        0      0 2001:4567:affe:0:21d:ecff:fe05:1234:53020 2001:4567:affe:0:21d:ecff:fe00:89ab:445 ESTABLISHED

Note that the box is currently streaming both ways

Edited by SpaceRat, 7 May 2015 - 13:13.

[pieterg]

I'm not sure it will work on systems without ipv6 support.

I think switching to getaddrinfo (with appropriate flags) would be a safer solution to enable ipv6 and at the same time keep backward compatibility.

[SpaceRat]

I'm not sure it will work on systems without ipv6 support.

As I'm already said: It definitely doesn't.
On the other side, you aren't building for any legacy (IPv4-only) system.

All machines for which OpenPLi is built have IPv6 and all machines for which "based on OpenPLi" is built should and easily can have it too.
If someone would tell you that OpenPLi is shit because he disabled IPv4 and IPV6 entirely and runs his network IPX/SPX- or AppleTalk-only, you would call him an idiot and ignore him.

Disabling IPv6 in 2015 is about as stupid.

I think switching to getaddrinfo (with appropriate flags) would be a safer solution to enable ipv6 and at the same time keep backward compatibility.

Well, I'm open for better solutions.

[Erik Slagter]

I'm not sure it will work on systems without ipv6 support.

I think switching to getaddrinfo (with appropriate flags) would be a safer solution to enable ipv6 and at the same time keep backward compatibility.

At some point you will have to choose to use either an AF_INET or AF_INET6 socket. An AF_INET6 won't be available on a non-ipv6 kernel. An AF_INET socket won't accept a sockaddr6_in struct.

 

IOW I don't think it's possible to add IPv6 support transparently in runtime.

 

FWIW if you ask me, I'dsay IPv6 in kernel is mandatory. There is no reason to not enable it. And then simply use an AF_INET6/sockaddr6_in everywhere. @Littlesat, an AF_INET6 socket can accept IPv4 connections without a problem. Default Linux configuration is to work 100% dual stack. The administrator can turn off that feature, and that's probably why the code in patch (re-)enables that feature for the specific socket.

 

BTW I've have had two commonly used applications that fail to work on non-IPv6-enabled kernels, even though no IPv6 is actually used. I think it's time to move on to AF_INET6.

[SpaceRat]

BTW I've have had two commonly used applications that fail to work on non-IPv6-enabled kernels, even though no IPv6 is actually used.

One should note that one of those (or the third ...) is Samba.
Actually the only machine for which this is worth mentioning at all is the Raspberry Pi where the Raspbian devs decided not to include the ipv6 kernel module by default (For whatever non-existant reason).

I think it's time to move on to AF_INET6.

Indeed.
We got IPv6-enabled kernel configs even for the old 266 MHz sh4 boxes.

[pieterg]

I'm not sure it will work on systems without ipv6 support.
I think switching to getaddrinfo (with appropriate flags) would be a safer solution to enable ipv6 and at the same time keep backward compatibility.

At some point you will have to choose to use either an AF_INET or AF_INET6 socket. An AF_INET6 won't be available on a non-ipv6 kernel. An AF_INET socket won't accept a sockaddr6_in struct.

getaddrinfo will return ipv6 when supported, and ipv4 when ipv6 support is lacking.
It returns an addinfo struct with ai_family set to either AF_INET or AF_INET6, so we don't have to choose.

BTW I've have had two commonly used applications that fail to work on non-IPv6-enabled kernels, even though no IPv6 is actually used.

Bad programming
There's no need to create another commonly used application which will fail

[Erik Slagter]

So it this way or see it like AF_INET6 is the modern way (for over 15 years now) to describe an create both IPv4 and IPv6 sockets.

[SpaceRat]

These examples for coding sockets ...
http://long.ccaba.up...s/eva/ipv6.html
... list three ways for coding sockets:

1. IPv4-only (Which is definitely deprecated)
2. Dual Stack sockets (But depending on IPv6 kernel support, though you do not need to have an IPv6 enabled network!)
3. Portable code (Which would work on legacy kernels too, if I get that concept right)

Option 3 might sound the cleanest, but on the other hand as Erik pointed out there is no reason not to enable IPv6 in kernel and thus there is no real forcing reason for it or against option 2.
Option 2 has the charme that it might remind people to revise the kernel config

Ignorant people coding IPv4-only cause much more harm than a dual stack socket ever could:
I can point you at monster threads about problems with IPv4-only junk (On the other hand, there are people that pay me 150 EUR to solve them, so I must be an idiot not to become part of the problem rather than providing the solution).
But you will have a hard time finding the opposite, i.e. where someone needs to turn IPv6-enabled code to legacy shit for a good reason.

Even though the code in the patch does not work on IPv4-only kernels, it's not really a problem, because that scenario has to be a pure academical thought in 2015.
Like: "It wouldn't have worked 18yrs ago."

Edited by SpaceRat, 7 May 2015 - 14:29.

[adri]

In a properly setup environment ....

root@duo2 /media/autofs/Arbeitszimmer # netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 Duo2.fritz.box:https    quattro.fritz.box:27254 ESTABLISHED
tcp        0      0 Duo2.fritz.box:8001     quattro.fritz.box:27301 ESTABLISHED
tcp        0    128 Duo2.fritz.box:ssh      quattro.fritz.box:27222 ESTABLISHED
tcp        0      0 Duo2.fritz.box:58597    Igel.fritz.box:10005    ESTABLISHED
tcp        0      0 Duo2.fritz.box:49776    Solo2.fritz.box:8001    ESTABLISHED
tcp        0      0 Duo2.fritz.box:53020    Solo2SE.fritz.box:microsoft-ds ESTABLISHED   

none of the above connections is still using IPv4:

root@duo2 /media/autofs/Arbeitszimmer # netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 2001:4567:affe:0:21d:ecff:fe05:1234:443 2001:4567:affe:0:96de:80ff:fe6c:3456:27254 ESTABLISHED
tcp        0 125164 2001:4567:affe:0:21d:ecff:fe05:1234:8001 2001:4567:affe:0:96de:80ff:fe6c:3456:27301 ESTABLISHED
tcp        0      0 2001:4567:affe:0:21d:ecff:fe05:1234:22 2001:4567:affe:0:96de:80ff:fe6c:3456:27222 ESTABLISHED
tcp        0      0 2001:4567:affe:0:21d:ecff:fe05:1234:58597 2001:4567:affe:0:21e:bff:fe7a:789a:10005 ESTABLISHED
tcp        0      0 2001:4567:affe:0:21d:ecff:fe05:1234:49776 2001:4567:affe:0:21d:ecff:fe00:9abc:8001 ESTABLISHED
tcp        0      0 2001:4567:affe:0:21d:ecff:fe05:1234:53020 2001:4567:affe:0:21d:ecff:fe00:89ab:445 ESTABLISHED

Note that the box is currently streaming both ways

 

Spacerat,

 

Your properly setup environment seems to have global IPV6 addresses, which are probably coming from a RadV or DHCP6 daemon on your router?

There are few consumer ISP's who offer full IPV6 connectivity to their users even in 2015.

In a normal home environment, the only IPV6 addresses would be automatic local-link fe80:* addresses. 

I have prevously removed all the IPV6 modules from OpenPLI, because some communications where NOT working properly from the STB, with only a local-link address assigned and no IPV6 support in the rest of the house, including the ISP router.

 

I think this will be the default environment for many OpenPLI users, who don't install and maintain their own home network, but just have a router or cable modem from their ISP.

 

Adri.

[SpaceRat]

Your properly setup environment seems to have global IPV6 addresses, which are probably coming from a RadV or DHCP6 daemon on your router?

Yepp.
It's a 6in4 tunnel.

 

There are few consumer ISP's who offer full IPV6 connectivity to their users even in 2015.

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

During the next 2.5 yrs this ratio will quickly exceed 50% in Germany, when T-Online (Which alone has 50% market share) forcibly switches its customers from POTS and ISDN to VoIP.
The new lines will have Dual Stack.

Multiple other providers simply have no other choice than to provide IPv6 to their customers, as they do not have enough public IPv4 addresses for all (new) customers:

• Kabel Deutschland
• Unitymedia/KabelBW
• Glasfaser Deutschland
• M-Net
• Tele Columbus
• ...

In fact, for me the only serious use for streaming over the network would be certain Glasfaser Deutschland lines as servers:
They can - at 200 MBit/s symetrical - stream one or multiple HD streams across the net. VDSL 25/5 or VDSL 50/10 can do shit.
But for that to work one needs IPv6 ... because each Glasfaser Deutschland reseller has a whopping 1024 IPv4 addresses to spread across their customers ...

 

In a normal home environment, the only IPV6 addresses would be automatic local-link fe80:* addresses.

Which work anyways.
The SpeedPort routers that T-Online/Deutsche Telekom sells will even resolve local hostnames to those link local IPv6 addresses.
That means - as IPv6 capable clients prefer IPv6 over IPv4 - the first contact will always be tried using those.

Which in turn means: Having IPv6 capable machines (Of which the hostnames get resolved to IPv6 addresses) with the server daemons being IPv4 only will cause fall-backs all the time and for some programs even connection failures.

 

I think this will be the default environment for many OpenPLI users, who don't install and maintain their own home network, but just have a router or cable modem from their ISP.

People had 17 yrs to prepare for IPv6.

As now more and more providers can not provide "full" IPv4 connectivity anymore, resulting in millions of people (That's not exaggerated) getting limited by IPv4-only junk, the focus should go away from keeping up compatibility with a handful of broken deprecated installations towards at least catching up.
It's no longer 5 to 12 for IPv6 support, it's a quarter past 12.

ATM the insurrection still takes place at the ISP forums, as some people still do not understand their provider can't bake IPv4 addresses (Since 2012).
Give them one year at the most and they will come here and to other developers and ask why they have left them quirking in their boots that long.

Sorry, but broken setups can not be considered anymore.

For OpenATV we have merged the patch and just revert it at build time for the remaining three machines for which the kernel doesn't build properly and thus has no IPv6.
The same machines will be dropped in OpenATV 5.0 anyways as the kernel can't deal with other changes too.

Time has come to say bye-bye to your wood gasifier driven car.

Edited by SpaceRat, 7 May 2015 - 16:20.

[SpaceRat]

PS:
In a properly set up network - even IPv4-only - Dual Stack sockets do work.
The patch was even developped inside such a network!
That's the point.

Get a Vu+ using OpenPLi and you already get the same kind of socket inside Erik's streamproxy.
And nobody has complained about that aspect of it yet.

Dual Stack sockets work for 99.99% of all setups, IPv4-only would work for only 95% (incl. another 5% where it imposes limitations).
Keeping compatibility with the 0.01% that f*cked it up effectively means nothing else but f*cking up things too.

Edited by SpaceRat, 7 May 2015 - 16:31.