147 replies to this topic

[Ronnie1966]

openpli 7.1-release vuultimo4k

vuultimo4k login: root
ifconfig
root@vuultimo4k:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1D:EC:10:4D:D4
          inet addr:192.168.2.110  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::21d:ecff:fe10:4dd4%lo/64 Scope:Link
          inet6 addr: 2a02:a454:ff52:1:21d:ecff:fe10:4dd4%1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1698055 errors:0 dropped:1151 overruns:0 frame:0
          TX packets:79520 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:462775239 (441.3 MiB)  TX bytes:5931922 (5.6 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1%1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:140 (140.0   TX bytes:140 (140.0

sys0      Link encap:Ethernet  HWaddr 00:1D:EC:10:4D:D4
          inet6 addr: fe80::21d:ecff:fe10:4dd4%lo/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1698055 errors:0 dropped:0 overruns:0 frame:0
          TX packets:79717 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:493340229 (470.4 MiB)  TX bytes:6279512 (5.9 MiB)

[Ronnie1966]

Kan je hier iets mee?

[WanWizard]

Daar is helemaal niks normaals aan, ping snapt al jaren zowel IPv4 als IPv6, en default naar IPv6 als dat er is.

 

Mijn laptop:

[wanwizard@catwoman] $ ping downloads.openpli.org
PING downloads.openpli.org(cdn1.hosting.flexcoders.eu (2001:41d0:801:2000::449)) 56 data bytes
64 bytes from cdn1.hosting.flexcoders.eu (2001:41d0:801:2000::449): icmp_seq=1 ttl=50 time=21.1 ms
^C
--- downloads.openpli.org ping statistics ---

dus als er IPv6 connectiviteit is, dan zal die ook gebruikt worden. Tenzij er ergens iets mis is, en dat lijkt hier het geval te zijn.

[pcman19]

Beste Wanwzizard,

 

Niet iedere versie van ping is default al compitable met alletwee.

Ik heb ook nog aantal centos 7.6 servers draaien.

En die doen met ping alleen ipv4 en met ping6 alleen ipv6.

en als ik het test met google klopt het ook.

De ping versie van openpli doet ook alleen met ping ipv4.

 

root@vuultimo4k-beneden:~# ping google.nl

PING google.nl (216.58.208.99): 56 data bytes

64 bytes from 216.58.208.99: seq=0 ttl=57 time=4.084 ms

^C

--- google.nl ping statistics ---

1 packets transmitted, 1 packets received, 0% packet loss

round-trip min/avg/max = 4.084/4.084/4.084 ms

root@vuultimo4k-beneden:~# ping6 google.nl

PING google.nl (2a00:1450:400e:80b::2003): 56 data bytes

64 bytes from 2a00:1450:400e:80b::2003: seq=0 ttl=57 time=3.758 ms

^C

--- google.nl ping statistics ---

1 packets transmitted, 1 packets received, 0% packet loss

round-trip min/avg/max = 3.758/3.758/3.758 ms

root@vuultimo4k-beneden:~#

Edited by pcman19, 23 August 2019 - 10:24.

[WanWizard]

Kan je hier iets mee?

 

Ja. Het gaat blijkbaar fout als de box een valide IPv6 adres heeft, maar niet met dat adres naar buiten kan.

 

Doe eens een

ping -6 openpli.org

op de box, krijg je dan response?

[pcman19]

Bijdeze:

 

ping -6 openpli.org

PING openpli.org (2001:1b40:4000:5::239:72): 56 data bytes

64 bytes from 2001:1b40:4000:5::239:72: seq=0 ttl=55 time=13.659 ms

64 bytes from 2001:1b40:4000:5::239:72: seq=1 ttl=55 time=13.531 ms

[WanWizard]

Probleem zit hem niet in de connectiviteit, probleem zit hem in het feit dat het downloaden van de updates in Enigma een probleem heeft met die connectiviteit.

 

m.a.w., zodra de box een valide IPv6 adres heeft treed dit probleem blijkbaar op.

 

Dit verklaart ook waarom een "opkg update && opkg upgrade" van de commandline wel werkt, opkg heeft geen probleem met IPv6 transport.

 

Ik zal op mijn router eens SLAAC activeren (ik doe nu alleen DHCPv6) zodat mijn box ook een IPv6 adres krijgt, dan kan ik wat meer zien...

[pcman19]

Wanwizard,

 

Als je vpn wilt ik heb hier een vpn voor je kan je testen op mijn box ls je wilt.

Welke commando gebruiken jullie als ik het via de box zelf doe?

eventueel kunnen we daarmee uitzoeken wat er mis gaat.

Edited by pcman19, 23 August 2019 - 10:33.

[WanWizard]

Merci, maar dat is niet nodig. Ik weet nu wat de oorzaak van het probleem is, nu op zoek naar het probleem zelf...

[pcman19]

Staan de downloads.openpli.org op andere server of loadbalancer?

want het ipv6 adres van downloads.openpli.org is zozieo een anders adres en hij pingt ook niet op ipv6 adres.

Terwijl het ipv4 adres wel netjes pingt.

Edited by pcman19, 23 August 2019 - 10:38.

[pcman19]

WanWizard,

 

denk dat ik het probleem gevonden heb kwa ipv6.

 

Jullie hebben een server bij ovh en bij hertner.

 

Bij ovh ipv6 krijg je netjes een antwoord: 

 

root@vuultimo4k-beneden:~# ping6 downloads.openpli.org

PING downloads.openpli.org (2001:41d0:801:2000::449): 56 data bytes

64 bytes from 2001:41d0:801:2000::449: seq=0 ttl=49 time=15.792 ms

64 bytes from 2001:41d0:801:2000::449: seq=1 ttl=49 time=15.253 ms

64 bytes from 2001:41d0:801:2000::449: seq=2 ttl=49 time=15.201 ms

 

 

Doe je hetzelfde op de hertner ipv6:

 

PING downloads.openpli.org (2a01:4f8:192:12c2::85:221): 56 data bytes

^C

--- downloads.openpli.org ping statistics ---

2 packets transmitted, 0 packets received, 100% packet loss

 

 

Ik ga even testen wat er gebeurd als ik forced van ovh pak of het probleem dan ook speelt.

[WanWizard]

Hmm... Da's een erreur da nie zjuust is... Ik zal het doorgeven aan onze hoster, kunnen ze even kijken.

[pcman19]

Wanwziard,

 

Ik heb inmiddels bevestiging.

 

Zodra ik de ovh ipv6 erin zet loopt hij niet vast.

Pak ik het hertner ipv6 dan loopt hij wel vast.

 

Ik heb het nu tijdelijk verholpen door in de /etc/hosts de ipv6 van ovh te zetten en alles werkt.

[pcman19]

Ik heb zet hier even tijdelijk de oplossing neer voor mensen met ipv6:

 

Ik gebruik zelf nano maar met vi kan het ook.

Mocht nog geen nano hebben: opkg install nano

 

open telnet

nano /etc/hosts

 

voeg deze regel toe:

 

2001:41d0:801:2000::449 downloads.openpli.org

 

En druk crtl +x

 

en dan kan je weer normaal updaten zonder dat je box hangt.

Edited by pcman19, 23 August 2019 - 10:50.

[WanWizard]

Met zegt me dat het gevonden en opgelost is:

~ 
[wanwizard@catwoman] $ ping cdn1.hosting.flexcoders.eu
PING cdn1.hosting.flexcoders.eu(cdn1.hosting.flexcoders.eu (2001:41d0:801:2000::449)) 56 data bytes
64 bytes from cdn1.hosting.flexcoders.eu (2001:41d0:801:2000::449): icmp_seq=1 ttl=50 time=21.2 ms
64 bytes from cdn1.hosting.flexcoders.eu (2001:41d0:801:2000::449): icmp_seq=2 ttl=50 time=22.2 ms
64 bytes from cdn1.hosting.flexcoders.eu (2001:41d0:801:2000::449): icmp_seq=3 ttl=50 time=21.3 ms
^C
--- cdn1.hosting.flexcoders.eu ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 21.236/21.554/22.151/0.454 ms

~
[wanwizard@catwoman] $ ping cdn2.hosting.flexcoders.eu
PING cdn2.hosting.flexcoders.eu(2a01:4f8:192:12c2::85:221 (2a01:4f8:192:12c2::85:221)) 56 data bytes
64 bytes from 2a01:4f8:192:12c2::85:221 (2a01:4f8:192:12c2::85:221): icmp_seq=1 ttl=57 time=39.1 ms
64 bytes from 2a01:4f8:192:12c2::85:221 (2a01:4f8:192:12c2::85:221): icmp_seq=2 ttl=57 time=39.9 ms
64 bytes from 2a01:4f8:192:12c2::85:221 (2a01:4f8:192:12c2::85:221): icmp_seq=3 ttl=57 time=40.1 ms
64 bytes from 2a01:4f8:192:12c2::85:221 (2a01:4f8:192:12c2::85:221): icmp_seq=4 ttl=57 time=39.6 ms
64 bytes from 2a01:4f8:192:12c2::85:221 (2a01:4f8:192:12c2::85:221): icmp_seq=5 ttl=57 time=40.6 ms
^C
--- cdn2.hosting.flexcoders.eu ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 39.066/39.869/40.600/0.527 ms

Wat ik er van begrijp is dat Hetzner een of andere vage mac adres mapping gebruikt om een IPv6 range te koppelen aan een IPv4 adres, en dit was gereset om e.o.a. reden, waardoor het wees naar een niet gebruikt MAC/IPv4 adres.

[pcman19]

Ziet er uit van wel inderdaad:

 

root@vuultimo4k-beneden:~# ping6 downloads.openpli.org

PING downloads.openpli.org (2a01:4f8:192:12c2::85:221): 56 data bytes

64 bytes from 2a01:4f8:192:12c2::85:221: seq=0 ttl=58 time=14.454 ms

64 bytes from 2a01:4f8:192:12c2::85:221: seq=1 ttl=58 time=14.326 ms

^C

--- downloads.openpli.org ping statistics ---

2 packets transmitted, 2 packets received, 0% packet loss

round-trip min/avg/max = 14.326/14.390/14.454 ms

 

en ook met updaten nu hangt die niet meer vast.

Edited by pcman19, 23 August 2019 - 10:56.

[WanWizard]

Mooi, dank voor het terugmelden, en dank voor het debuggen iedereen.

 

Dit geeft maar weer aan dat eens het probleem te reproduceren is, de oplossing zo is gevonden.

[pcman19]

Jup.

Helaas was ik op vakantie anders had ik eerder mee kunnen helpen met debuggen.

 

PS. Mochten jullie nog een derde server erbij willen in nederland laat even weten heb nog wel ruimte in me rack/vps platform.

[WanWizard]

Merci, maar we beheren het niet zelf, alle hosting is uitbesteed (en deels gesponsord).

 

De cdn's staan overigens niet voor niks bij providers als ovh en hetzner, providers zonder bandbreedte restricties en kosten. Je wilt echt niet dat het uit een TB of 95% percentile allocatie moet komen, de cdn's hebben dagelijks momenten dat ze meer dan 300Mbps moeten leveren... Het was nog veel gekker toen we nog dagelijkse beta's hadden... 

[leeuwke]

Bedankt voor het oplossen van dit probleem!