[megoldva (remélem)] Fedora 19 (64bit) hálókártya él, kapcsolat él - internet nincs

Red Hat, Fedora, CentOS

Sziasztok

Fedora 19 (64bit) alatt nem sikerül életre kelteni az internetet. A hálókártya egy alaplapi történet, rtl8101e, a realtek oldaláról leszedett driver forgatása után látszólag gond nélkül működik. A hálózaton DHCP kioszt mindent, de ha kézzel állítom be akkor is úgy tűnik megvan a kapcsolat. ping-elni a routert tudom. DNS-nél hasalhatna el, de a "ping google.com" is gond nélkül működik. Viszont ha pl.: "curl -Iv google.com"-al, vagy sima "yum update"-el próbálkozom, már timeout-al megáll. Böngészők is, természetesen. Proxy nincs.
Próbáltam "netstat -F"-et, és adtam volna hozzá getaway-t, "route add default gw 192.168.1.1", de minden maradt a régiben. "tail -f /var/log/messages"-ben semmi árulkodó, em1 link up hasonlóak. Gyanakodtam a tűzfalra, "systemctl stop firewalld.service" nem hozott eredményt. SELinux kikapcsolva.Tömör összefoglaló: 


[root@localhost r8101-1.024.00]# ifconfig
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.93  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::ef0b:ff:fe00:e000  prefixlen 64  scopeid 0x20<link>
        ether ed:0b:00:00:e0:00  txqueuelen 1000  (Ethernet)
        RX packets 634  bytes 64576 (63.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 148  bytes 14186 (13.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 45  base 0xe000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@localhost r8101-1.024.00]# ping index.hu
PING index.hu (217.20.130.97) 56(84) bytes of data.
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=1 ttl=60 time=17.7 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=2 ttl=60 time=11.5 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=3 ttl=60 time=11.1 ms
^C
--- index.hu ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 11.198/13.504/17.791/3.034 ms
[root@localhost r8101-1.024.00]# yum update
Betöltött bővítmények: langpacks, refresh-packagekit
Hiba: Cannot retrieve metalink for repository: fedora/19/x86_64. Please verify its path and try again

Nem nagyon ismerem a fedora-t (még), abban kérnék segítséget, hogy mit kellene nézzek, mi okozhatja ezt. Lehet, hogy a kézzel forgatott driver a gond, szúrjak az alaplapba valami más hálókártyát? (windowsra újraindítva gond nélkül megy minden)

szerk: A megoldás sírvaröhögős: meg kell változtatni a mac address-t valamire, ami nem a gyári. Az ask.fedora-n is feltett kérdésre (köszönet zoltanh kollégának a közreműködésért) írta valaki, hogy bug van a kártya firmwarejében, és eredeti mac-el ezt csinálja. A címet megváltoztatva, majd újracsatlakozva minden működött, lefutott a yum update, és a böngészőben is megjelentek az oldalak.

A "megoldva" utáni "remélem" arra vonatkozik, hogy valaki írta a hozzászólásokban, hogy neki is volt hasonló, de stabilitási gondjai is voltak, "remélem" ott is "csak" a hibás fw okozta. Ha ez történne, akkor is marad a megoldva, mert beleteszek egy másik kártyát, ezt letiltom és jónapot...

Köszönöm mindenkinek a segítségét.

  • 9187 megtekintés

( Dacr (nem ellenőrzött) | 2013. 08. 29., cs – 10:21 )

Ha pingul és feloldódik a célállomás, akkor a kártya elméletileg teszi a dolgát, DNS van.
IPv6-ot próbáld meg letiltani első körben, szokott néha zavart okozni.

Konzol, root:

ellenőrzöl előszor:

ifconfig

Tiltasz:

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

ellenőrzöl:

ifconfig

Ez a reboot után elvész, de első körben arra jó lesz, hogy meglesd, használ-e neki.
De egyébként az /etc/sysctl.conf-ba is beteheted a két sort (sysctl parancs nélkül) és akkor tartós lesz.
Ha az IPv6 tiltás nem segít, akkor lehet tovább keresgélni.

:( Sajnos nem, a működik az ipv6 tiltásra vonatkozik csak. Most csinálom a messages/dmesg-es/lspci-os paste-okat, tegnap kimentettem, mindjárt postolom, csak nem hagynak itt élni... (nem tudom mi van ma, munkahelyen egész nap dolgozni kell, eszem megáll... :D )

( zoltanh | 2013. 08. 29., cs – 11:29 )

Szia

Első körben én is az ipv6 tiltását javasolnám, ill. arra lennék kiváncsi milyen yum pluginjaid vannak. Mivel alapvetően nincs tükör keresés beállítva, sokszor segít az is hogyha első körben yum-plugin-fastest-mirror plugint hozzáadod, ha megy. DE: a timeoutos részről nem tudnál fpaste.org-ra küldeni valamit és belinkelni ide vagy lőni egy képet?
Amúgy magyar fedora közösség IRC-je a freenode-on van, és bárki bármikor jöhet ha kérdezni szeretne, plusz van egy g+ csatorna is.

Tervezem hozzáadni ezt a plugint is, de mivel nincs net, update-elni sem tudom, még a kernel is az ami a telepítőn volt. Meg aztán, a curl-t nem befolyásolja gondolom.

Mit küldjek a timeout-ról? messages-t? a 'curl -Iv google.com' kimenete valami olyasmi, hogy 'retrieving <ip cim>.....' aztán timeout, eközben nézett 'tail -f /var/log/messages'-ben nem történik semmi..

szerk: köszönöm, amint megoldottam hogy legyen internet, be fogok nézni. :)

( saabi v | 2013. 08. 30., p – 10:54 )

A klasszikusokat senki sem javasolja?
- netstat -rn
- service iptables off

Ez a gép az amit most használok, csak egy másik, új hdd-n van ez a rakoncátlan rendszer, a régivel bootolva minden rendben, bár az nem linux. Ezért férek hozzá a fájlokhoz.

A DHCP-t állítgattam automatikusra, kézire (olyan beállításokkal, ami minden itt minden gépen jó), de nem változott semmi. Kapcsolat van, ip-t kap, dns-van -> net nincs.

Megnézted a logot, itt mit nem sikerült lefordítania a dkms-nek?

Aug 29 17:49:12 localhost dkms_autoinstaller[288]: Error! Bad return status for module build on kernel: 3.9.5-301.fc19.x86_64 (x86_64)
Aug 29 17:49:12 localhost dkms_autoinstaller[288]: Consult /var/lib/dkms/r1000/1.06-2.el4.rf/build/make.log for more information.

Aztán lehet, valamit félreértek, de a log szerint 192.168.1.105 lesz a címed, az ifconfig szerint 192.168.1.106, de lehet, ezek nem összetartozó dolgok időben. Az ifconfig helyett inkább így próbáld:

ip addr show

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az a dkms-hiba attól volt hogy találtam egy driver-t, amiről azt gondoltam hogy jó lesz, valahol a neten írták hogy jó a kártyámhoz, nem is értettem mert leírása szerint meg nem, mindegy, azt próbáltam telepíteni, de nem működött, ezt az error-t a konzolon is kiírta. Ezt követően töltöttem le a realtek-től azt, amit kézzel fordítottam, ami megy(?) most is. Ez a log csütörtöki, pénteken csináltam egy friss telepítést, ott már meg sem próbáltam ezt az rpm-et, de net továbbra sem lett, szóval gondolom nem okozott semmit.

Az ip-cím variálás nem tartozik össze, próbálgattam másikkal, hátha valamit elfelejtett elfelejteni, vagy valami, de bármire állítottam nem használt. A DHCP 100 alattiakat oszt ki, fixre meg 100 fölöttieket szoktunk, ezt próbáltam - eredménytelenül.

Azt próbáltad, hogy wireshark-kal nézed a forgalmat? Hátha kiderül, mi nem működik. Arra figyelj, hogy a user, aki indítja a wiresharkot, legyen benne a wireshark csoportba, mert különben jogosultsági problémáid lesznek.

Számomra az a fura, hogy ha a hardware nem menne, akkor pingelni sem lehetne, ha lehet pingelni, akkor megy a hardware, s nem világos, miért nincs net. Névfeloldásod szemmel láthatóan van. Habár... eszembe jutott egy nyakatekert dolog. Mi van akkor, ha caching only nameservert futtatsz, s sikerült azt elérned, hogy a cache-ből van névfeloldásod, de egy idő után további külső névszervert már nem tudsz elérni? Nem túl valószínű, csak nincs ötletem és kapálózok... :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hogy ne csak icmp legyen tesztelve, kipróbálhatnál karakter átküldést localhost-on legalább netcat-tel. Jobb lenne másik gépre.

1) nc -l -p 9999

2) echo hello | nc 127.0.0.1 9999

Ha ez megy, akkor a GUI-nál van valami szívás.

elinks-el vagy lynx-el próbáltál oldalt betölteni?

Megnézem ezt is hétfőn.

Közben annyi történt, hogy kaptam egy olyan tippet is (köszönet zoltanh közreműködésének), hogy elképzelhető hogy firmware-bug van a nic-ben, a mac címmel kapcsolatban. Ha megváltoztatom a mac címet, lehet jó lesz. Ez lesz az első, amit megnézek majd, remélem beválik. Ráguglizva a "ed:0b:00:00:e0:00" címre, vannak érdekes találatok...

:) Igen, ezért nem adtam fel én sem, ennek mennie kell, ha egyszer működik.

Megoldódott, az ask.fedora-n írt megoldás vezetett eredményre, a mac address csere. Updateltem a témanyitót, ott leírtam. Most már csak apróságok vannak, csinálok dkms-package-t a gyári driverből, meg ilyesmik, de ha más nem lesz, úgy tűnik rendben van. (az általad talált centos-es repoban lévő sajnos függőségek miatt nem működött, de amúgy is alacsonyabb verziószámú, lehet még ez is számít valamit, ezek után nem lepődnék meg...)

Ha MAC csere lett a megoldás, akkor nem lehet hogy mégsem a gépeden volt a gond, hanem a routeredben (ha van)? És azzal a MAC-kel beragadt valami IP érték amit DHCP előtte osztott ki vagy bármi egyéb?

Tehát olyat nem próbáltál, hogy router reboot (ha van)?

Furcsa ez megoldásnak.

"nem lehet hogy mégsem a gépeden volt a gond, hanem a routeredben (ha van)?"
Mivel multicast MAC volt a gép interfészén, így vajmi kevés esélye van annak, hogy a routerrel lett volna gond. Multicast forráscím nem alkalmazható.

"Furcsa ez megoldásnak."
Megoldásnak nem furcsa. Az a furcsa, hogy ilyen előállhat. De ha már előállt, akkor vagy MAC csere, vagy - amennyiben lehetséges - firmware csere.

Elképzelhető hogy igazad van, nem vitatom. A routert nem tudom újraindítani, bár nyilván van, sőt, ha írnék az "illetékes elvtársnak" egy levelet hogy pl.: este 23:00 után indítsa újra, gondolom megtenné, de nem vagyok benne biztos hogy sokat segített volna. Meg persze eszembe sem jutott ilyesmi. :)

Ha újabb gondokat okozna, erre is figyelni fogok.

( log69 | 2013. 08. 30., p – 11:15 )

Lehet hülyeség, de feltéve egy elinks-et és azzal megnézve egy oldalt működik?

elinks http://google.com

nsswitch.conf -hoz nem lett nyúlva?

Szia

Megnéztem a dmesg kimenetedet - és lenne egy tippem - de nem biztos, ugyanis valami rémlik az aláírt kernelmodulokról, és az aláíratlanokkal kapcsolatban felbukkant gondokról. Ha megnézed az alábbi sort, szerintem itt lesz a gond. A fedora biztonsági okokból olykor nem enged be olyan drivereket ami nincs aláírva. HTH.

r8101: module verification failed: signature and/or required key missing - tainting kernel
[ 1.565758] r8101 Fast Ethernet driver 1.024.00-NAPI loaded
[ 1.565890] r8101 0000:02:00.0: irq 44 for MSI/MSI-X
[ 1.576128] eth%d: RTL8101E at 0xffffc9000067e000, ed:0b:00:00:e0:00, IRQ 44
[ 1.576400] intel_rng: FWH not detected
[ 1.576530] r8101: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
[ 1.576533] eth0: Identified chip type is 'RTL8103E'.

Ami számomra érthetetlen, hogy centos 6 és késöbbi változataira megvan az el6 repókban. Itt legalábbis megtaláltam: http://www.rpmstuff.org/post/48920688946/rpms-kmod-r8101-1-023-00-1-el6…

Ezen felül még eszembe jutott mégvalami: rfkill csomag. Valahogy fel kellene tuszkolni rá, és megnézni rfkill list all paranccsal hogy nincs-e soft blokk benne. HTH.

Ezt én is láttam, valami linuxforums-os hozzászólásban azt írták hogy nem kell vele foglalkozni. Meg arra gondoltam, hogy ha nem engedné, akkor nem menne egyáltalán, be sem töltődne, nem az hogy betölti, link up, ip, dns, connonnected, stb.

Mindenesetre nagyon köszönöm, amint a közelében leszek, kipróbálom ezt az rpm-et, hátha hoz változást.

( gyko v | 2013. 09. 01., v – 22:04 )

A megoldást nem tudom, de érdekel, mert én is jártam már pórul, az alaplapi hálókártyával, ami szintén Realtek ( Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller). Működik teljesen jól, de hirtelen lehal és csak a gép újraindítása után indul el, a logokban sehol semmi... én nem voltam ennyire kitartó, mint te, megkerülő megoldásként raktam a gépbe egy PCI Ethernet kártyát (Intel Corporation 82557/8/9/0/1 Ethernet Pro 100) azzal minden rendben.

Ez is Fedora 19 64 bit...

( talisker | 2013. 09. 02., h – 10:55 )

Igaz, hogy ez már sokat nem segít, de CentOS ügyben nekem is voltak Realtek alaplapi NIC-kel bajaim.
Nálam is HWADDR hegesztgetés volt a tüneti kezelés, de produktív szerverbe nem mertem kiereszteni, így letiltottam
toltam bele Intel hálókártyát és ment minden vígan.

Olyasmire emlékszem, hogy nekem reboot során törnkrevágta a a virtualizációnál használt bridge definíciót, meg magát a kártya definíciót is és
rohadt nehezen lehetett visszagyógyítani.

Ezexerint más is szívott alaplapi Realtek-kel. :(

---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)