Kun avaan koneen ja Firefoxin, kestää yleensä yli minuutin, että nimenselvitys nettiosoitteissa toimii. Ulkopuoliset IP-osoitteet vastaavat kyllä pingiin, mutta mikään tekstimuotoinen osoite ei toimi. Esim. googlen nimipalvelin, jonka olen Soneran nimipalvelinten lisäksi lisännyt käsin verkkoasetuksiin tämän ongelman takia, vastaa pingiin, mutta nimenselvitys ei silti toimi kuin pienen viiveen jälkeen. Windows 10:ssä samalla koneella kaikki nettiosoitteet toimivat heti kun kone on käynnistynyt. Miksi näin? Mitä voin tehdä, jotta tuo toimisi niin kuin pitääkin, eli heti? Mielestäni ei pitäisi olla mitään oikeaa syytä, miksi Ubuntu toimii noin oudosti, kun reititinkin on aina päällä.
Nimipalvelimeen ei saada yhteyttä
OngelmiaRiittää
20479
0Äänestä
Muut lukivat myös
Ketjusta on poistettu 2 sääntöjenvastaista viestiä.
Odottaa vastausta
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Vastaukset 20
Vanhimmat
Kirjoitapa tulosteet:
ifconfig
route
ping google.fi
cat /etc/resolv.conf
Jotta voimme haarukoida jossakin määrin ongelmaa.
Laittaa reitittimeen ne Soneran nimipalvelimet ja sitten laittaa ne muiden koneiden DNS palvelimet osoittamaan reitittimeen. Aika suuri todennäköisyys, että reitittimessä on paikallinen DNS palvelin.
Reitittimessä ei tietenkään ole paikallinen DNS-palvelin, vaan Soneran. Sieltähän se reititin hakee IP:n ja muut verkkoasetukset automaattisesti DHCP:llä.
Eli reititin hakee DHCP:llä operaattorilta verkkoasetukset, mutta hakeeko Ubuntu asetukset reitittimeltä DHCP:llä? Windows ilmeisesti hakee, jos sen kanssa ei ole ongelmia.
Mitä /etc/network/interfaces sanoo aiheesta?
Kyllä, reitittimessä on DHCP-palvelin ja Ubuntu hakee sieltä asetukset.
/etc/network/interfaces sanoo seuraavaa:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
ifconfig sanoo seuraavaa heti käynnistyksen jälkeen:
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.101 netmask 255.255.255.0 broadcast 192.168.0.255
ether ------- {VERKKOKORTIN MAC-OSOITE txqueuelen 1000 (Ethernet)
RX packets 614 bytes 145951 (145.9 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 569 bytes 64267 (64.2 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf7200000-f7220000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 682 bytes 48107 (48.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 682 bytes 48107 (48.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Eli eipä tuossa ole mitään muuta kuin sisäverkon ip-avaruutta, niin kuin pitääkin.
Kyllä monissa reitittimissä on ihan oma DNS palvelin että ei tarvitse Soneralta saakka kysellä osoitteita. Että sen kun laittaa vaan reitittimen kyselemään nimet Soneralta ja muut laitteet reitittimeltä. Tarkoittaa sitä, että jos jollain laitteella kysyy nimeä ja se jää reitittimen muistiin niin samaa kun kysellään uudestaan toiselta laitteelta niin löytyy suoraan lähempää reitittimestä.
Niinhän tuo toimi alunperin, eli ne, asetukset mitä DHCP antoi, olivat käytössä (reitittimen IP siis DNS:nä). Aloin määrittelemään käsin noita Soneran ja Googlen nimipalvelimia tuon viiveen takia, mutta se ei selvästikään auttanut ongelmaan, koska sama ongelma on edelleen.
Mutta jos koneelle on asetettu DNS-palvelin, niin se asetus ohittaa reitittimen asetuksen. Olisiko yhteydessäsi jotain vikaa. Reititin kannattaa ainakin uudelleenkäynnistää.
Minä käynnistelin aluksi tuota reititintä, koska yhteydet ei toimineet. Sitten ongelmienselvittelyn kautta selvisi, että verkkoyhteydessä tai reitittimessä ei ole mitään vikaa, koska pingit menee läpi ja Windowsissa kaikki toimii heti oikein, kun Windowsiin boottaa. Vika on siis Ubuntussa, koska Ubuntussa tämä vika ilmenee ja se ilmeni ennen kuin asetin DNS-asetukset käsin. Eli niillä samoilla DHCP:n antamilla asetuksilla, joilla olen jo vuosikausia Windowsilla ja Macillä yhdistänyt HETI nettiin. Niissäkään ei siis ole se ongelma.
Itseasiassa ongelma näyttäisi olevan myös niin, että jos en yhdistä Firefoxilla nettiin, vaan pelailen esimerkiksi pelejä Ubuntussa ja sitten vaikka tunnin päästä avaan Firefoxin, se kestää sen päälle minuutin, ennen kuin mikään sivusto aukeaa tekstimuotoisella osoitteella. Tarvitaan siis jokin sovellus, joka tarvii DNS-pavelinta, ennen kuin nimipalvelintiedot päivittyy pienellä viiveellä. Mikä Ubuntussa on sellainen asetus, joka tuon viiveen aiheuttaa? Eihän tuossa ole mitään järkeä!
"/etc/network/interfaces sanoo seuraavaa:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback"
Samat asetukset on minullakin, ja kone toimii ihan hyvin käytettäessä langatonta wlania kännykän jakamana.
En tiedä auttaisiko sitten jos lisäisi tuonne vielä:
# The primary network interface
auto <sovitin>
iface <sovitin> inet dhcp
Tuo <sovitin> riippuu sitten koneesta, itselläni on näköjään tuossa Ubuntu servussa toinen nimeltään "enp0s3", ja toinen on "enp0s8". Yleensä nuo on kait "eth0", "eth1" jne.
todennäköinen syy hidastelulle on reititin. Itsellä se ei antanut nimipalvelimen ip-osoitteita, jos adsl-yhteys ei ollut päällä, pelkän sisäverkon ip:n - ja eihän se yleensä ole, kun virrat väännetään pc:lle ja modeemille yhtä aikaa päälle eli myös se haki asetuksensa dhcp:llä. Tästä seurasi bootti-ongelmia, koska ubuntussa käynnistys oletuksena rakentuu niin(jos eetteri dhcp), että asetukset voi hakea modeemilta ja netti on "valmis palvelemaan". Eli korjaa resolv.conf:iin palveluntarjoajan dns-osoitteet manuaalisesti. Poista rasti "vaadi yhteydelle IP-v4 osoite" - tämä saa sen odottamaan - ja editoi /etc/network/interfaces:iin rivi muotoon "iface enpXXX inet dhcp". ja "auto enpXXX". Pitäisi alkaa toimimaan, joskaan takuita en anna. Jos jotain vaikka vielä unohtui mainita..?
Resolv.confia ei kannata editoida, koska kaikki muutokset kirjoitetaan yli seuraavalla bootilla kuitenkin. Näin lukee resolv.confissa:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
Katselinkin tuota uudestaan ja löysin /etc/dhcp/dhclient.conf:sta ainakin lisätyn rivin:
option domain-name-servers x.x.x.x
-eli oiskohan tämä nyt se oikea korjaus
Ja näyttäs olevan myös määritelty kiinteä dns-osoite reitittimen conffiin.. tiedä sitten kumpi korjaus on se toimiva.
Suomi24 on paska
Nyt selvisi, mikä tuon aiheutti. Olin disabloinut ipv6:n, koska apt-get -asennukset oli toooooodella hitaita. Tuolla siitä aiheesta:
http://www.techrepublic.com/article/how-to-fix-the-slow-apt-get-update-issue-on-linux-machines/
Nyt kun enabloin ipv6:n uudelleen, nimipalvelut löytyvät heti, eikä mitään viivettä ole. On tämä kyllä outo ongelma, kun ipv6:n enabloinnnin jälkeen apt-get-asennukset toimii taas normaalisti ja nimenselvitykset myös.
Eihän telialla(soneralla) ipv6 pitäisi edes toimia, jotkut saaneet toimimaan tunneloimalla, m utta onko siitä hyötyä?
https://yhteiso.telia.fi/t5/Kiinteat-nettiyhteydet-ja/IPv6-ja-taloyhtiolaajakaista/td-p/108180
Eipä tuo minun reititinkään tue ipv6:sta, eli outoa on todellakin. Miten se voi alkaa toimimaan normaalisti ipv6:n enabloimalla, vaikka ipv6 ei ole edes käytössä missään kohtaa verkkoa?
Minulla oli ubuntu gnomessa sama apt-hitaus. Vaihdoin suomen palvelimen pääpalvelimeen niin jopa rupes toimimaan. Ubuntussa ei ole ollut hidastelua.
Hotspot shield ei taaskaan toimi.
Mikähän änkyttää taas, onko firefox vai hotspot shield:n tiimi?