[VU+ Solo2] Disable IPv6?

[antiks]

Hi,

What is the correct method for fully disabling IPv6 on an OpenViX box? I'd normally do this via sysctl on a standard Linux box but I thought it was best to ask in case there is a specific method for OpenViX.

Thanks!

 

[Photovoltaic]

Bump - Because I have exactly the same Question. Mine's an Xtrend ET-10000 but the same point applies.

 

[SpaceRat]

Why would you want to do this?

 

[abu baniaz]

Why would you want to do this?

See this thread:
http://www.world-of-satellite.com/showthread.php?55139-Possibly-Hacked-box-Some-Security-help-needed

Pretty sure it was the wrong setting in his config file. He never posted his file , but says he fixed it.

 

[SpaceRat]

The proper way to do it would be to add a line like

net.ipv6.conf.eth0.autoconf = 0

at the end of /etc/sysctl.conf

Replace "eth0" with the interface actually used, e.g. "wlan0" when using WiFi.
Duplicate the line if multiple interfaces are used.

Do not replace "eth0" with "default" or "all" or even destroy the box by uninstalling the IPv6 kernel module, because a growing amount of tools/plugins uses Dual Stack/IPv6 sockets to communicate, so at least localhost will need to keep it's IPv6.


But note:
There is generally no reason to disable IPv6 at all.
Either you got IPv6 and then it's fine to assign an IPv6 address to the box too or you didn't got IPv6 and then the box won't get an IPv6 address either.

In special, there are two valid reasons why one would want to do that anyways:

• The router being used can forward IPv6 and has no firewall for IPv6, letting all IPv6 packets pass. Years ago some Asus routers did that, but no current router model should do that.
  
  Don't be confused just because IPv6 addresses are public:
  Even with a public IPv6, it's still a FORWARD from the router's point of view and even the shittiest routers do conntrack and only let anwer packets pass, just like they do for IPv4 (IN: REJECT, OUT: ACCEPT, FORWARD: REJECT plus CONNTRACK to accept incoming packets that are answers to outgoing ones).
  
  In fact, on those shit routers there are bigger problems to get single ports on single machines opened (forwarded) for IPv6, especially when you get dynamic prefixes.
• You have no IPv6 connectivity to the outside but can't get your router convinced not to announce an ULA prefix (An IPv6 starting with fcXX: or fdXX: )
  
  Some programs with crappy code will try to reach global unicast IPv6 addresses just because they see we got an ULA (but no own global unicast address), causing delays when waiting for this connection to fail.

For all other problems, I would highly prefer if we could get a bug report, so that the real problem can get fixed, rather than using ugly hacks to workaround them.

 

[SpaceRat]

BTW:

One of the programs with minor quirks is Media Portal.

Videos stored on Google Video abuse a quirk inside the calling URL:
To bypass the check "Play video only for the user who uploaded it", they include a token valid for an IPv6 address inside the URL for the comparison.
In theory this check would fail for any other IPv6 and for any IPv4, but thanks to some quirk on Google Video, it will accept any IPv4 instead (= skip the IP check).
However, once you try to access the video using IPv6, the check is performed and fails (Because you aren't accessing using the IPv6 the token inside the URL is valid for).

One can cheat around this:
1. Do a lookup of redirector.googlevideo.com on the shell:

root@duo2 ~ # nslookup redirector.googlevideo.com
Server:    192.168.75.1
Address 1: 192.168.75.1 link.box

Name:      redirector.googlevideo.com
Address 1: 2a00:1450:4001:810::200e fra15s09-in-x0e.1e100.net
Address 2: 216.58.214.46 fra15s09-in-f46.1e100.net

2. Add a line reading

216.58.214.46 redirector.googlevideo.com

replacing "216.58.214.46" with whatever IPv4 the resolve in step 1 came out with to /etc/hosts

That way, redirector.googlevideo.com won't be looked up on DNS servers anymore, but the IP(v4) stored in /etc/hosts will be used instead.
As a result, you will be accessing the Google Video Redirector using IPv4 without having to disable IPv6 entirely.

 

[SpaceRat]

If you are unsure if your router lets IPv6 traffic pass (FORWARDs it) unfiltered, you can use this online check: http://www.ipv6scanner.com/

Just paste the IPv6 of your box and do a scan for common server ports.
Unless you actually have configured any IPv6 forwards, all ports should come out red (no answer at all) or orange (filtered).

If you get green lights for the commonly installed services of an E2 box (Port 21 = ftp, Port 22 = ssh, Port 23 = telnet, Port 80 = Web-Interface, Port 445 = SMB/Samba) without having defined explicit forwards for them, you really should temporarily disable IPv6 on your box (and any other device in your network).
Temporarily because you can re-enable it once you have thrown the router out of the window and got a new one, because if it's behaving that crappy, it most definitely has other bugs too!

 

[SpaceRat]

The proper way to do it would be to add a line like

net.ipv6.conf.eth0.autoconf = 0

at the end of /etc/sysctl.conf

... while doing some development work on the network part, I found out that this only works in theory ...
It should/would work on "real" Linux systems, but there is a bug in oe-a core which breaks this functionality.

I have changes in oe-a core on my to-do list that will
- restore this functionality
- enable more sophisticated settings¹ in /etc/network/interfaces

For a quick fix, execute these two commands on the box via ssh or telnet:

update-rc.d -f networking remove
update-rc.d -f networking start 10 2 3 4 5 . stop 80 0 1 6 .

That will restore the sysctl.conf functionality.

Ceterum censeo SysVinit esse delendam!

1. The more sophisticated settings will allow per interface configuration for:
   IPv6 ...
   • ... using SLAAC only (That's what we currently forcibly have)
   • ... using DHCPv6 only (Which is what OpenWrt/LEDE routers do out of the box)
   • ... using SLAAC+stateless DHCPv6
   • ... using SLAAC+stateful DHCPv6
   • ... manually configured (Effectively disabling it if no manual configuration is made)
   ... and IPv4 ...
   • ... using dhcp (The current default and recommended setting)
   • ... using static
   • ... manually configured (Effectively disabling it if no manual configuration is made)
   ... and any combination of these IPv6+IPv4 settings.

 

[dr_funk]

I'm having a similar problem with my Duo 2, and it seems to be as a result of my ISP not supporting IPV6. All DNS lookups have a 9 second delay until I run the Network Wizard, after which the delay is fixed and the box runs normally again for several hours (or a reboot) after which the 9 second delay returns.

I tried the steps that @SpaceRat outlined above: executing the two commands via SSH and adding the line at the end of /etc/sysctl.conf, but there was no improvement, before or after a reboot.

I looked at /etc/resolv.conf after a reboot and noticed that the first nameserver entry appears to be an IPV6 address, ending in eth0, which makes sense as I'm using the LAN port. The following two lines are the nameservers I added myself. If I run the Network Wizard and reopen resolv.conf, then I can see that the first IPV6 namserver has been removed and the delay issue is fixed. Unfortunately, as I already mentioned, the IPV6 nameserver entry and the 9 second delay reappear after several hours or a reboot.

I attempted a crude hack by making resolv.conf read-only, but that was overwritten after a reboot, and the IPV6 entry returned again.

Any suggestions?

 

[birdman]

Any suggestions?

A Google search indicates adding:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

at the end of [FONT=courier\ new]/etc/sysctl.conf[/FONT]. (So you'd have to add it again after any re-flash).

 

[dr_funk]

Fantastic! Looks like the problem is solved. No delay issue now, even after a reboot. Interestingly, the IPV6 entry is still there in /etc/resolv.conf, but I guess the box is now ignoring it due to IPV6 being disabled.

Many thanks!