1748 replies to this topic

[SpaceRat]

Ah, damn.
Forget my last test.
I did it on the wrong machine ... that one has never seen a different patch than yours 8-)

[pieterg]

I guess getaddrinfo should only be used for AF_INETx sockets and not for Unix sockets.

Yes, I feared that would happen.
I was hoping we could share the same code for unix domain sockets, it make things a lot cleaner.
Later this week when I have a bit of time, I'll try a few things, but if I cannot make it work, we should indeed revert the unix domain sockets back to the old code.

[MiLo]

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

I do.

I have a slow internet connection, so I really want that 3% extra bandwidth that IPv4 provides me. So I enforce IPv4 as much as possible, and avoid the one protocol to find them all and in darkness bind them...

Having said that, creating code that runs fine on both stacks isn't hard (allthough the braindead morons that created IPv6 tried to make it needlessly difficult) and I've done that on many occasions. Pieter already gave the correct solution.

[SpaceRat]

And why not simply do a

sysctl -w net.ipv6.conf.eth0.disable_ipv6=1

then?

[Persian Prince]

 

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

I do.

I have a slow internet connection, so I really want that 3% extra bandwidth that IPv4 provides me. So I enforce IPv4 as much as possible, and avoid the one protocol to find them all and in darkness bind them...

Having said that, creating code that runs fine on both stacks isn't hard (allthough the braindead morons that created IPv6 tried to make it needlessly difficult) and I've done that on many occasions. Pieter already gave the correct solution.

 

 

+1 

 

Also all normal users in my country are using IPv4 and even ISPs won't offer IPv6 connections

Edited by Persian Prince, 12 May 2015 - 13:38.

[SpaceRat]

Most internet users still have and use IPv4, that has never been the point.

[peteru]

Most Internet users don't have access to ipv6 at all. Worse still, a large proportion of users have some ipv6 enabled devices but no end to end connectivity. ISPs that do not currently support or offer ipv6 (the vast majority of all the connections in the world) very often supply their customers with modems/routers that have ipv6 enabled and misconfigured. To make things worse, many of these ISPs won't even allow the user to adjust these settings. Instead they lock down the pre-configured router and use remote management features.

 

I've seen instances where a router will quite happily answer DNS queries with ipv6 addresses without having any external ipv6 connectivity. You can guess what happens next. Trying to reach Google or Amazon hosted sites with Firefox results in the browser spinning it's wheels for a while and then failing with a connection reset message. In some instances the only reasonable fix is to actually build some software with ipv6 explicitly disabled. In the above example I ended up running dnsmasq with ipv6 support explicitly turned off.

 

I'm all for ipv6 support, but it needs to be transparently backwards compatible. It should also be possible to disable the use of ipv6 for troubleshooting purposes and as a workaround for misconfigured/malfunctioning environments.

 

BTW: Taking a Euro-centric / German point of view is less than helpful. Same way that North Americans having a US-centric point of view is not helpful either. The Real World ™ is a lot more diverse than what we see in the places where you or I happen to live today. What seems bizarre in one place is quite common elsewhere and vice versa.

[SpaceRat]

Most Internet users don't have access to ipv6 at all. Worse still, a large proportion of users have some ipv6 enabled devices but no end to end connectivity.

The first point here and the next point is the worse part.
You are just trying to solve the problems this creates through the second on your list.

 

ISPs that do not currently support or offer ipv6 (the vast majority of all the connections in the world) very often supply their customers with modems/routers that have ipv6 enabled and misconfigured.

A lot of all providers force the user to use specific routers.
This is a problem also in Germany. It's huge enough that a law against it is planned (I have my doubts politicians really can come up with a law that is properly written to enforce the free choice of routers).

 

To make things worse, many of these ISPs won't even allow the user to adjust these settings. Instead they lock down the pre-configured router and use remote management features.

The worst thing is that this forced equipment breaks IPv6 connectivity even if it is there. While you can operate your own router for IPv4 behind it (By introducing double NAT and other quirks), it's hard to impossible for IPv6 (Those provider supplied junk boxes do not properly do IPv6 prefix delegation or even bridge mode).

 

I've seen instances where a router will quite happily answer DNS queries with ipv6 addresses without having any external ipv6 connectivity.

That's what it is supposed to do.
Proper DNS servers reply to AAAA queries via IPv4 transport and also to A queries via IPv6 transport.

[SpaceRat]

You can guess what happens next.

No, I can't.

 

Trying to reach Google or Amazon hosted sites with Firefox results in the browser spinning it's wheels for a while and then failing with a connection reset message.

This is not caused by the DNS properly resolving hostnames though.
It just "helps" the problem to come up.

My guess is:
The provider enforced junk box also advertises an ULA prefix (fdaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh, probably simply fd00::/64).
That's also the default in OpenWrt.

Some software (e.g. oscam) considers an ULA address to be just as good as a public IPv6 and makes connection attempts using it then.

If you happen to have an OpenWrt driven router, just go to Network -> Interfaces and delete the pre-configured ULA prefix under "Global network options".
This will make OpenWrt stop advertising this prefix on the LAN.
 

I'm all for ipv6 support, but it needs to be transparently backwards compatible. It should also be possible to disable the use of ipv6 for troubleshooting purposes and as a workaround for misconfigured/malfunctioning environments.

I have no problem with that.

Simply issuing
sysctl -w net.ipv6.conf.eth0.disable_ipv6=1
or eth0 replaced with any other interface
will properly do that.

The problem is that this discussion drifted away from perfectly working code to discussions about use of IPv6 world-wide and how it can be damaged through config.

Once again:
For this merge request it was just an API question.
I did never tell you that you all have to switch to IPv6 now.

All I said was that it is perfectly acceptable to use the IPv6/Dual-Stack-aware API for creating sockets as it works for IPv4-only, Dual Stack and IPv6-only networks, while the current API works only for IPv4-only networks.

I do not even have a problem if anyone wants to disable IPv6 on his box, hell, maybe I'll even add that option in OpenATV myself just to make sure people do it right if they do it.

The point is simple:
Those who want or even need to use IPv6 (Which is an increasing number) can not be made liable for some people not being able to configure their network properly.
You can't avoid coding for IPv6/Dual Stack forever just to make the second group happy.

[Persian Prince]

The point is simple:

Those who want or even need to use IPv6 (Which is an increasing number) can not be made liable for some people not being able to configure their network properly.
You can't avoid coding for IPv6/Dual Stack forever just to make the second group happy.

 

 

+1 Agree.

 

We must support IPv6 and IPv4 together but it's up to us whether we want to use v6 or v4.

[SpaceRat]

I've tried both ...

Disabling IPv4 on eth0
Change /etc/network/interfaces from

auto eth0
iface eth0 inet dhcp

to

auto eth0
#iface eth0 inet dhcp

Result after "ifup -f eth0":

root@solo2 ~ # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1D:EC:00:12:34
          inet6 addr: fe80::21d:ecff:fe00:1234/64 Scope:Link
          inet6 addr: 2001:db8:c0c0:0:21d:ecff:fe00:1234/64 Scope:Global
...

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
...

... eth0 is IPv6-only.
Interface "lo" stays Dual Stack to prevent Plugins that try to create IPv4-only sockets from crashing E2.


Disabling IPv6 on eth0 (Revert disabling IPv4 first or you will get "zero stack" )

echo -e '#/bin/sh\nsysctl -w net.ipv6.conf.eth0.disable_ipv6=1' > /etc/network/if-pre-up.d/ipv6; chmod 755 /etc/network/if-pre-up.d/ipv6

Result after "ifup -f eth0":

root@solo2 ~ # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1D:EC:00:12:34
          inet addr:192.168.75.18  Bcast:192.168.75.255  Mask:255.255.255.0
....

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host

... eth0 is IPv4-only.
Interface "lo" stays Dual Stack to prevent Dual Stack sockets from crashing E2.

To re-enable IPv6:

echo -e '#/bin/sh\nsysctl -w net.ipv6.conf.eth0.disable_ipv6=0' > /etc/network/if-pre-up.d/ipv6; chmod 755 /etc/network/if-pre-up.d/ipv6

and do "ifup -f eth0" again.


Fact proven:
There is no reason not to write dual stack code just because you do not want to use the one or the other protocol version.

[Persian Prince]

I've tried both ...

Disabling IPv4 on eth0
Change /etc/network/interfaces from

auto eth0
iface eth0 inet dhcp

to

auto eth0
#iface eth0 inet dhcp

Result after "ifup -f eth0":

root@solo2 ~ # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1D:EC:00:12:34
          inet6 addr: fe80::21d:ecff:fe00:1234/64 Scope:Link
          inet6 addr: 2001:db8:c0c0:0:21d:ecff:fe00:1234/64 Scope:Global
...

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
...

... eth0 is IPv6-only.
Interface "lo" stays Dual Stack to prevent Plugins that try to create IPv4-only sockets from crashing E2.


Disabling IPv6 on eth0 (Revert disabling IPv4 first or you will get "zero stack" )

echo -e '#/bin/sh\nsysctl -w net.ipv6.conf.eth0.disable_ipv6=1' > /etc/network/if-pre-up.d/ipv6; chmod 755 /etc/network/if-pre-up.d/ipv6

Result after "ifup -f eth0":

root@solo2 ~ # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1D:EC:00:12:34
          inet addr:192.168.75.18  Bcast:192.168.75.255  Mask:255.255.255.0
....

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host

... eth0 is IPv4-only.
Interface "lo" stays Dual Stack to prevent Dual Stack sockets from crashing E2.

To re-enable IPv6:

echo -e '#/bin/sh\nsysctl -w net.ipv6.conf.eth0.disable_ipv6=0' > /etc/network/if-pre-up.d/ipv6; chmod 755 /etc/network/if-pre-up.d/ipv6

and do "ifup -f eth0" again.


Fact proven:
There is no reason not to write dual stack code just because you do not want to use the one or the other protocol version.

 

 

Seems ok and maybe with some skin design and python coding somebody could put 2 nice iOS buttons in network section so users could change them just like this :

 

 v4v6.jpg   35.07KB   6 downloads

 

 

And yes dual stack code would be the best in my opinion.

Edited by Persian Prince, 13 May 2015 - 13:44.

[SpaceRat]

I already had Components/Network.py open for edit ...

But:
I decided not to make any changes there yet, as that could end up being ATV-only then.
If we change something there, it should at least become a de-facto standard for distros that share the PLi heritage.

I was considering different additional key sets for each interface:

a.)
ipv4_enable=true|false
ipv6_enable=true|false

Probably the worst choice. If some other plugin not being aware of those creates a complete config set from scratch, both would be considered false and the interface would end up zero stacked.


b.)
ipv4_disable=true|false
ipv6_disable=true|false

A bit better, because not setting these keys would end with dual stack enabled, as it is now.
However, like a it allows user configs with both stacks disabled which have the same effect as disabling the adapter entirely

c.)
A tri-state
proto=ds|ipv6|ipv4

Only the cases proto=ipv6 and proto=ipv4 would need handling:
If key proto gets handled, it would disable ipv4 when proto=ipv6 or it would disable ipv6 when proto=ipv4.
Not handling key "proto" at all (or a setting of proto=ds) would result in Dual Stack on 99% of all boxes (As most have IPv6 enabled kernels), just like it is now.

[pieterg]

I have adapted the patch from pieterg.
 
@Pieterg: I have adapted 2 procedures.
1. eServerSocket::eServerSocket(std::string path, eMainloop *ml)
 I don't use getaddrinfo. I create proper addrinfo with path and pass it to startListening
 
2. eUnixDomainSocket::connectToPath
I wanted to do the same as in 1 in this procedure. But in eSocket::connect ::connect was executed and failed all the time with "No such file or directory". I didn't find a solution, so I reverted to old code. Perhaps you have an idea why it fails.

The connect was actually fine (manually filling addrinfo with the path).
But in the past we didn't log connect errors, because we silently try to connect to paths which might not exist (tpm socket, capmt socket).
So I removed the connection error log for unix domain sockets.

However, there was another issue on the unix domain socket server side, with inet_pton (which does not support AF_LOCAL either).
inet_aton returns a pointer to a null character, where inet_pton returns a NULL pointer.
I worked around that by using the fixed client address string "(local)" in case of AF_LOCAL.

[pieterg]

All seems fine now, I've pushed the commit. If we've overlooked something we'll soon find out I guess.

[Taapat]

@pieterg in eServerSocket variable res is unused: http://sourceforge.n...rsocket.cpp#l78

Attached Files

•  0001-serversocket-remove-unused-variable-res-in-eServerSo.patch   716bytes   13 downloads

[ims]

All seems fine now, I've pushed the commit. If we've overlooked something we'll soon find out I guess.

big problem ... after run EPGRefresh box crashes ... today I woke up due it on 6:00, when box crashed and then turned TV...

Same on all boxes ...  same crashlog as here http://forums.openpl...og/#entry491405

[Taapat]

I can confirm, for me, on non mipsel receiver is exactly the same problem:

lib/base/ebase.cpp:155 ASSERTION notifiers.find(fd) == notifiers.end() FAILED!

Edited by Taapat, 16 May 2015 - 09:15.

[ims]

it seems, problem is after several zaps ( and EPGRefresh make it, of course )... now I can reproduce it always after cca 10 zaps. 

When I reverted this patch https://sourceforge....8fdd490ba07f21/, all is ok again

 

 

it is strange ... it reminds me long time existing problem on single core boxes (XP1000 and et4000) ... after severals zap (10-20) this box cannot playback AVI files.

Edited by ims, 16 May 2015 - 09:23.

[littlesat]

Does is only crash with EPGRefresh?... so should the structured solution likely be in EPGRefresh?