Sziasztok, Kb 2 hete van egy érdekes netes problémám: -Néhány oldal nem töltődik be elsőre, rohadt sokáig tart a címfeloldás. -A Dropbox nem igazán akar működni -Steam kliens sem tudta néha betölteni ugyanazt az oldalt ami a böngészőben simán megjelent. -Paypalra be tudok lépni, de ha valamiért fizetnék, a végtelenségig loadingol -Az ubuntu.hu-ra nem tudok fórumtémát írni, mert sosem megy ki a POST request, a kommenteléssel nincs baj. (mitől olyan speciális az a request?) -Windows alatt a Nod32 "ARP mérgezésre" gyanakszik, de ott betöltenek, és rendesen működnek a weboldalak. (+mi mérgezné a hálózatot, amikor csak én és a router voltunk rajta?) -Deviantarton nem tudom törölni az értesítéseimből az új feltöltött képeket (windows alatt simán megy) -Devil daggers játék nem tudja betöltani a saját pontjaimat/rekordomat, csak a globális játékoslistát -Szobatársam friss telepítésű, agyonkonfigurálatlan Kubuntuján is ugyanezt tapasztalom. A probléma mind Ubuntu 16.04 és 17.04 alatt is fenn áll, és minden böngészőt érint. Amiket eddig csináltam: 1. Kitöröltem a /etc/hosts fileból a blokkolt spamelő és kártékony oldalakat (http://someonewhocares.org/hosts/), csak az alap bejegyzéseket hagytam meg. 2. A network manager konfigjában kikapcsoltam a dnsmasq-ot. 3. Hozzáadtam manuálisan a networkmanagerhez a google és az opendns címeit, ami a kikapcsolt dnsmasq révén bele is szinkronizálódott a resolv.conf-ba. A probléma még mindig fennáll, és mivel az oldalak betöltődnek, épp csak bizonyos requestek nem mennek el, és hibaüzeneteim sincsenek, nem tudom mit lehetne tenni. Mindenesetre linuxos gondnak tűnik a dolog, és látszólag csak engem érint. Az albérletben UPC-s net van, ami gyors, és eddig semmilyen gond nem volt vele. Ugyanígy a hardver is mindig gond nélkül működött. Merre lehet elindulni a keresgéléssel? Ez az egész dolog olyan, hogy a fő domainek működnek, de mintha a POST kérések nem mennének sehova. Ráadásul gondolom ezek a titkosított dolgok. Windows alatt minden működik rendesen. cat /etc/resolv.conf: # 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 nameserver 8.8.8.8 nameserver 8.8.4.4 nameserver 208.67.222.222 cat /etc/NetworkManager/NetworkManager.conf: [main] plugins=ifupdown,keyfile #dns=dnsmasq [ifupdown] managed=false [device] wifi.scan-rand-mac-address=no UPDATE: -Már a steam sem képes bejelentkezni, Windows alatt minden tökéletes. Mivel nem jutottam előbbre, nekiálltam wireshak-kal nézegetni a forgalmat, és az valami kaotikus. Az első 3 képen a steam kliens próbálkozásai vannak, az utolsón ezt a fórumtémát próbálom editálni semmi sikerrel. https://imgur.com/a/1TJIS Mindez az UFW tűzfalat kikapcsolva. A router címe a 0.1 és 0.2-es. A sajátom a 0.16-os. Olyan mintha az elérhetetlennek tűnő és pingelhetetlen 0.2-es IP cím akarna küldeni valamit a gépemre, ami elérhetetlennek tűnik. Valakinek mondakan valamit ezek a hibák? MEGOLDÁS: Találjuk ki a router lelkivilágát, és kérdezzük meg tőle, hogy mekkora legyen az mtu: ping -s1500 -c2 -Mdo 8.8.8.8 A számot csökkentgetve elérünk egy méretet, ami nem dob hibát. Majd kérjük meg szépen Linuxot hogy legyen szíves ezt az MTU-t használni az adott hardveren. sudo ifconfig (eszkozneve) mtu 1432

Szia! A UPC-s nettel kapcsolatban két probléma szokott előfordulni (akár egyszerre is), az egyik a UPC-s DNS szerver hibája, a másik az IPv6 alkalmazása. Az elsőre a megoldás, az 1. DNS szerver a UPC-é, a 2. a Google-é (egyes oldalak, UPC-s alkalmazások nem működnek más DNS szolgáltatóval). A másodikra már telefonos segítség kell a UPC-től (1221, majd vissza kell kérni az IPv4-et). Újabban szokott még gond lenni a https-es kézfogással is, erre még nincs gyógyír. Sajnos a UPC-nél nincs közvetlen kapcsolat a bix-el, nálam ez a helyzet: traceroute to bix.hu (193.239.149.210), 30 hops max, 60 byte packets 1 192.168.0.1 (192.168.0.1) 0.409 ms 0.573 ms 0.735 ms 2 catv-176-63-51-254.catv.broadband.hu (176.63.51.254) 11.795 ms 11.914 ms 21.774 ms 3 catv-89-135-215-94.catv.broadband.hu (89.135.215.94) 11.732 ms 11.751 ms 11.761 ms 4 hu-bud03a-rc1-ae31-2020.aorta.net (84.116.241.130) 30.371 ms 30.299 ms 30.350 ms 5 hu-bud05a-ri1-ae15-0.aorta.net (84.116.137.78) 21.929 ms 21.907 ms hu-bud05a-ri1-ae12-0.aorta.net (84.116.137.2) 21.505 ms 6 r1.bix.iszt.hu (193.188.137.7) 30.941 ms 20.216 ms 20.031 ms 7 bix.hu (193.239.149.210) 19.611 ms 19.545 ms 19.529 ms

@"a mester"#p585807Állítólag valami olyan, hogy egy támadó értelmetlen hostname-ip cím párossal szemeteli tele a a gép caché-t. Én is most hallottam először, és mivel a figyelmeztetés idejében csak az asztali gépem és a router voltak a hálózaton, a routernek vagy a szolgáltatónak lehet valami baja. A netezők szerint ez a Nod32 egy kedvenc fals riasztása, én viszont 10 év alatt most láttam ezt tőle először.

@"ztsoft"#p585808Nekem ugyanez megvan 5 hoppal. Külső ipv4-em is van. A pc-nek is van ipv4 és ipv6 címe.

@"hallgat"#p585809Valószínű, hogy az ARP poisoning támadásra gondolsz. (A hivatkozott blog evvel is foglalkozik.)

@"hallgat"#p585809(Bocsánat, hogy nem guin-kattintgatós-a-módszerem, de) az arp -a szépen felsorolja, milyen címeket tart nyilván a rendszered. Ha csak a routerrel kommunikálsz, akkor ez egyetlen sor lesz.

@"a mester"#p585812Ha valaki feltörte a WiFi kapcsolatom jelszavát - és rajta lóg a routeremen - akkor az arp -a mutatja a kapcsolódott eszköz MAC címét is ?

@"lala2"#p585813Látom, nem érted. Az ARP-tábla azt tartalmazza, hogy a te géped milyen MAC-címekre kell küldjön IP-csomagokat. Attól, hogy a routeredre 42-en fel vannak kapcsolódva, a te ARP táblád csak az átjáród címét fogja tartalmazni. KIVÉVE, HA VALAKI A TE GÉPEDDEL BESZÉLGET. A routerre felcsatlakozott gépek MAC-címét a routerbe belépve, a csatlakozott eszközök listájában tudod megnézni. (És igen, kipróbáltam neked. Megnéztem a klienslistát, majd megpingeltem az egyik klienst, és onnan már benne van én ARP-táblámban is.) Az ARP-táblázat egyébként lejárós fajta: a nem használt címeket egy idő után kidobja, a használtakra meg rá szokott menet közben is nézni, hogy élnek-e még.

@"a mester"#p585814 # arp -a ? (192.168.200.100) at 98:f4:28:cb:7e:36 [ether] on eth0 # ping 192.168.200.104 PING 192.168.200.104 (192.168.200.104) 56(84) bytes of data. 64 bytes from 192.168.200.104: icmp_seq=1 ttl=64 time=101 ms 64 bytes from 192.168.200.104: icmp_seq=2 ttl=64 time=118 ms 64 bytes from 192.168.200.104: icmp_seq=3 ttl=64 time=39.0 ms ^C --- 192.168.200.104 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 39.018/86.275/118.153/34.089 ms # arp -a ? (192.168.200.100) at 98:f4:28:cb:7e:36 [ether] on eth0 hipod (192.168.200.104) at a4:31:35:b6:be:12 [ether] on eth0

@"a mester"#p585814Köszönöm ! :)

Destination unreachable (Fragmentation needed) [Megoldva]

T_chris

hallgatLáma kérdésem lenne ezzel kapcsolatban. A pc-nek is van ipv4 és ipv6 címe. Ha kikapcsolod az ipv6-ot, akkor is két címe marad?

hallgat

T_chrisIgen, letiltottam az ipv6-ot így: http://www.neuraldump.com/2016/11/how-to-disable-ipv6-in-ubuntu-16-04-xenial-xerus/ , újraindítottam a gépet, és úgy tűnik akkor is kap 6-os címet ha nem akarom. Ha kiadom a ‘sudo sysctl -p' parancsot, akkor tűnik el, de semmi nem változik. Úgyanúgy tele vagyok fragmentation needed-del. Nekem az a gyanúm hogy a router nem ad valid MTU-t. (Mind windows és linux alatt 1500-ra van állítva)

a mester

hallgat"a router nem ad valid MTU-t" Azt hogyan kéne adnia?

T_chris

hallgatHa a routerre van kettőslátásunk, akkor miért a gépen, és miért nem azon kapcsolod ki egy próba erejéig az ipv6-ot?

a mester

a mester(Az ilyen MTU-dolgokat az eszközök egy "szolgálati csatornán" szokták megbeszélni egymással. Ha te egy ügyes tűzfallal letiltottad a protokolt -nem ismerted, akkor ne is legyen alapon-, akkor a router tényleg nem tudja megbeszélni a hálókártyáddal a használható MTU értéket.)

hallgat

a mesterTudtommal az egytlen tűzfal a gépen az ufw, amit hiába kapcsolok ki, akkor is marad a probléma. A netes beállításokkal sem szórakoztam semmit, 1 éve használom a rendszert, amikor kb 2 hete elkezdtek nem működni a weboldalak egyes részei, illetve a Steam.

a mester

T_chris" Windows alatt minden tökéletes" . . . . . . . . . . "A Windows megmondja hogy hogyan kell használni. A Linuxnak én mondom meg, hogy hogyan akarom használni. " :)

hallgat

T_chrisA routeren nem találok ipv6 tiltást sehol, már végigkotorásztam az összes menüt. A kettőslátás ilyen (most hogy próbaképp frissítettem 16.04-ről 17.10-re): gateway (192.168.0.1) at 08:95:2a:dc:80:4e [ether] on wlp3s0 ? (192.168.0.2) at 08:95:2a:dc:80:4e [ether] on wlp3s0

hallgat

a mesterAzt nem én mondtam neki hogy romoljon el :) Ha én lettem volna, tudnám hogy mit kell visszaírni :)

a mester

hallgatMegmondtad, hogyan _akarod_ használni. Ő meg azt jelzi, hogy úgy nem megy.

sömike

hallgatFrissítettél, vagy tiszta telepítés? Nem mindegy.

hallgat

a mesterEddig nem volt rá szükségem hogy a netet b*sztassam. Karmic Koala után 3 év volt mire használhatóvá tették, azóta nem volt gondom vele egészen 2 héttel ezelőttig. Találtam némi szakirodalmat, csak nem tudom őket összerakni/amit próbáltam, nem oszt, nem szoroz.

hallgat

hallgatA nagy kommenteket sem küldi el... https://askubuntu.com/questions/189752/cant-connect-to-certain-https-sites https://mellowd.co.uk/ccie/?p=5662 https://boredwookie.net/blog/m/mtu-mismatch-and-tcp-retransmissions https://bbs.archlinux.org/viewtopic.php?id=123480

hallgat

sömike16.04 tiszta telepítés volt. Ott jöttek elő a gondok, de a 17.10-es laptopon is ugyanaz a baj. A laptopon viszont legalább a Steam tud kapcsolódni. A 16.04-es pc-n is működött egy ideig, majd "elromlott", mint minden más. Tegnap elegem lett belőle, így 2 frissítéssel frissítettem 17.10-re, minden settingből a csomagtelepítő verzióját elfogadva.

hallgat

hallgatAz ifconfig legalább már kiírja az mtu méretet, 16.04 alatt azt sem csinálta meg. Ugyanúgy 1500 mint Windowson.

sömike

hallgatCsak kíváncsiságból: Mi a routered neve/típusa? Amit én próbálnék: firmware upgrade/downgrade a routeren.

hallgat

sömikeValami technicolor nevezetű vacak amit a UPC ad, és a főbérlőé. Egyszer volt, hogy magától újraindult. Tegnap visszareseteltem gyári beállításokra, de nem segített semmit.

a mester

Valaki utólag hozzáírt a nyitókérdéshez. Kell azt később észrevenni? Miféle cím az a 192.0.0.2? Az kicsoda?

hallgat

a mesterGőzöm nincs. Visszaállítottam a gyári beállításokra a routert, én vagyok az egyetlen DHCP kliens is, de az a cím megint ott van. Más UPC-s usereknek csak egyet ír az arp -a?

hallgat

a mesterMost esett le hogy nem a 192.168.0.2-őt kérdezted. Gőzöm nincs hogy mi a 192.0.0.2. Pingelhetetlen. Nem valami hálózati üzengetős cím?

sömike

hallgatSzerintem azzal a Reset-tel nem lehet elérni a kívánt hatást. Azt csak a UPC tudja resetelni normálisan. Fel kell venni velük a kapcsolatot.

T_chris

hallgatUpc? Akkor a másik cím esetleg nem lehet, hogy a UPC Wi-free szolgáltatáshoz tartozik, és azt wan oldalról piszkálgatja igény esetén a szolgáltató? Tényleg csak vaktában lövöldözök ezután....

ububox

hallgat"Egyszer volt, hogy magától újraindult." Vagy a rencergazdától aki megpróbálja megakadályozni hogy megakadályozd a működést, de te vagy a gyorsabb. :) Ügyfélszolgálat és kigyün az ember és hozza az új készüléket.

hallgat

hallgatHost Name MAC-cím IP-cím Connected Type RSSI Elévül Unknown 08:95:2A:DC:80:4E 192.168.0.2 Unknown N/A *** STATIC IP ADDRESS ** Ez mindig ott van, valahonnan reset után is visszakerül. (pedig az ip cím osztás 10-ről indul.)

« Előző oldal Következő oldal »