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

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....

hallgat

T_chrisKíváncsiságból megpróbáltam rácsatlakozni a free wifi-re, amit félbehagytam amikor megjelent valami tunneles beállítás. Visszaléptem a saját hálózatra, és eltűnt a másik IP cím, csak a routeré van meg. Fura. A hiba viszont még mindig fenn áll.

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?

ububox

hallgathttp://blog.spakka.net/2016/03/28/trialling-the-ziggo-ipv6-trial/ https://www.speedguide.net/ip/192.0.0.2 a gúgli szerint.

a mester

hallgatA küldött képeden az az egyetlen cím próbál értesíteni téged a topikcímnek választott üzenettel. Destination unreachable (Fragmentation needed)

hallgat

hallgatKorai öröm. Visszajön magától: @:~\ > arp -a gateway (192.168.0.1) at 08:95:2a:dc:80:4e [ether] on wlp3s0 @:~\ > arp -a 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

sömike

hallgatLehet, hogy van egy szoftvered, amely ezen az IP-n keresztül szeretne kommunikálni.

hallgat

sömikeÉs lemásolja a router fizikai címét hozzá?

hallgat

ububoxÚgy tűnik eredetileg is jó úton jártam, de akkor valamiért nem működött. Jelenleg a sudo ifconfig wlp3s0 mtu 1432 paranccsal úgy tűnik használható méretűvé lehet tenni a csomagokat. Még tesztelgetem egy ideig.

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.

sömike

hallgatNem de így be kerülhet az arp -ba

a mester

hallgatWindows alatt meg megy az 1500... Mégiscsak tud valamit az a rendszer, csak neked nem tetszik.

hallgat

hallgatKöszönöm, úgy döntöttem ez a megoldás a végleges :)

sömike

a mesterA windows sokkal okosabb és felhasználóbarátabbbbbbbbbbbbbbb. Mindenki térjen át arra! Most!

a mester

sömikeTérjen vissza...

hallgat

sömikeA windowson is vannak ilyen csomaghibák, de őt nem érdekli a router nyafogása :)

« Előző oldal