Problém s GLAN

Změna předmětu z “kabelový modem TC7200 od UPC a Fedora”.
Jelikož problém se týká každého Gb síťového prvku.
Zatím nevyřešeno.

Mám zajímavý problém s internetovým připojením od UPC.
Protože z jistých důvodů musím změnit ISP, oslovil jsem firmu UPC
Dnes mi natáhli domů kabel a na poličku posadili modem TC7200.
Připojil jsem počítač a nic.
Nepřidělí se IP pomocí DHCP. ba ani link se na modemu nerozsvítí. Mám tu doma celkem 3 počítače s FC 22, XFCE, 64b.
Ani jeden se na ten modem nechytá, přičemž ale všechny se bez problémů připojí (na počítačích je DHCP a router jim přiděluje statické IP podle MAC) na stávající připojení (router Zyxel a od jeho WANové strany kabel k jinému ISP.)
Předpokládal jsem, že modem nemá povolené DHCP, ale pak mě napadlo zkusil Wokna - jeden počítač má dualboot s Windows 7.
A co se nestalo - normálně se to rozjelo, IP se přidělila, internet se připojil a všechno běželo jak má.
Ale jenom s Woknama. Jakmile jsem přebůtoval zpátky na Fedoru, tak zase mrtvo.
(několikrát opakováno, je to plně reprodukovatelné. )

Nemají oni v Microsoftu nějakou specialitku v DHCP protokolu, kterou nutně vyžaduje ten úžasný modem TC7200?

Zítra zkusím přinést jiný router (ten stávající se mi nechce přenastavovat, dokud ho potřebuji) a připojím jeho WANovou stranu k modemu, ten nastavím na DMZ, nebo vůbec radikálně - do bridge módu.
Ale moc tomu nevěřím.

Nemáte někdo podobnou zkušenost?


Později:
Tak DHCP za to nemůže, neprojde ani handshaking. Když tam strčím WANovou stranu routeru a na něm DHCP, (UPC modem jak v router- tak i v bridge modu) tak to běží.

Prostě ten modem TC7200 má něco proti linuxovým počítačům už na linkové vrstvě.

Ano, zapasil jsem s tim u UPC taky, dnes mam pripojeni jine a problemy “zmizely”. Podle me za to ten kabelovy modem nemuze, to je jen bridge mezi ethernetem a koaxem (tusim DOCSIS u UPC). Nevim co myslis tim handshakem. Co si pamatuju tak problem byl vzdy v DHCP, jejich DHCP ma totiz strasne dlouhou odezvu a NetworkManager ma jen kratky timeout. Takze pomahalo zvetsit timeout DHCP (uz si ale nepamatuju jak).

To byl prvni problem, pamatuji si ale, ze jsem s tim stravil spoustu zabavnych hodin, protoze kdyz uz mi prisla DHCP odpoved, nebyly v ni tusim DNS, takze sem sice mel IP, ale nemel jsem DNS. Opravdu to bylo jako kdyz UPC nema rado Linux. Jejich support je nedosazitelny - dostat se na technika, ktery by o to neco vedel je nemozne a z frontend support chodi klasicke odpovedi “zkusil jste to vypnout a zapnout?” - proste uplne zbytecne.

Napada me jedine reseni - nechat si prideli IP na nejakou krabicku “router” a tim si udelat doma NAT (coz je asi nejlepsi reseni stejne).

PS: mimochodem ten modem ma i WiFi a UPC z nej ve vychozim stavu dela VEREJNY hotspot pro vsechny zakazniky UPC. Napad to je hezky, ale trochu dvousecny. Naloz s tim jak chces.

Tak jeste zverejnuji jeden z mych pozadavku na UPC ve kterem se jim snazim vysvetlit, ze jejich DHCP server vraci neplatnou odpoved, protoze je v ni spatne vyplneny option dhcp-server-identifier:


Důvod požadavku: Potíže s IP adresou

Text požadavku: 
Registruji problemy s pridelovanim IP adres pres vas DHCP server 213.46.172.166, ktery vraci
option dhcp-server-identifier 0.0.0.0;
coz je pravdepodobne neplatna adresa pro dalsi pozadavek na DHCP server. Pri pokusu o dalsi obnoveni
IP tak nasleduje i nekolika minutovy timeout DHCP klienta, nez zkusi obecnou adresu 255.255.255.255
a dostane novou adresu. V pripade, ze tento zaznam zustane v cache DHCP klienta, muze po restartu
pocitace trvat i nekolik minut nez je mu pridelena IP.

Priklad ze dneska:
Boot
Feb 15 19:13:14 base dhclient[1208]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
Feb 15 19:13:14 base dhclient[1208]: DHCPOFFER from 10.123.128.1
Feb 15 19:13:14 base dhclient[1208]: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Feb 15 19:13:14 base dhclient[1208]: DHCPACK from 10.123.128.1
Feb 15 19:13:14 base dhclient[1208]: bound to 94.112.14.180 -- renewal in 1492 seconds.
Feb 15 19:38:06 base dhclient[1208]: DHCPREQUEST on eth0 to 213.46.172.166 port 67
Feb 15 19:38:06 base dhclient[1208]: DHCPACK from 213.46.172.166
Feb 15 19:38:06 base dhclient[1208]: bound to 94.112.14.180 -- renewal in 909 seconds.
Feb 15 19:53:15 base dhclient[1208]: DHCPREQUEST on eth0 to 0.0.0.0 port 67
Feb 15 19:53:18 base dhclient[1208]: DHCPREQUEST on eth0 to 0.0.0.0 port 67
Feb 15 19:53:26 base dhclient[1208]: DHCPREQUEST on eth0 to 0.0.0.0 port 67
...15 minut timeout
Feb 15 20:08:55 base dhclient[1208]: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Feb 15 20:08:55 base dhclient[1208]: DHCPACK from 10.123.128.1
Feb 15 20:08:55 base dhclient[1208]: bound to 94.112.14.180 -- renewal in 8333 seconds.

Pokud mate jine vysvetleni rad ho proberu. Jinak dekuji za napravu.

Datum přijetí: 2/15/2011 9:29:19 PM

a odpoved UPC:


Na našem DHCP serveru jsme žádné potíže nezaznamenali, vše funguje jak má. Ověřte prosím, že je vše
v pořádku ze strany Vašeho zařízení. V případě, že provádíte za modemem jakékoliv změny, je nutné
provést jeho restart odpojením od elektřiny.

Co na to rici? Ze v UPC neumi nastavit ani DHCP server? Dost mozna… kazdopadne s UPC bylo tolik ruznych neresitelnych problemu ze to nestalo za to.

ref.: http://www.upczone.cz/viewtopic.php?f=8&t=3351&p=47803#p47803 http://www.abclinuxu.cz/poradna/linux/show/328721
A jeste jedna zabavna ale vystizna ref.: http://magazin.softimage.cz/klientske-centrum-upc-s-problemy-nam-nevolejte/comment-page-23/

Tak pozor - změna !!!
UPC je v tom zcela nevinně.

Moje počítače s Fedorou nejsou schopny se připojit k ničemu, co má Gigabitový ethernet, rozumí si jenom se 100Mbps zařízeními.
Tentýž počítač s nabůtovanými Wokny však nedělá žádný problém, připojí se a jede gigabitem.

Všechny počítače mají GLAN kartu.

Tak, a teď - kde je problém? 8-O

Chces rict, ze zcela rozdilne pocitace (nebo je to uplne stejny HW?) nenahodi sitovku na gigabitu pokud je tam Linux? A zkousel si ty pocitace propojit mezi sebou, ne jen s tim UPC modemem?

Co ti vypise
ethtool
lspci | grep -i ether
dmesg | grep -i eth

UPC mám doma od doby, kdy Karneval do Neratovic natáhl z Prahy optický kabel.Pokud je problém s připojením na internet VŽDY mi na podpoře Karneval/UPC přikázali připojit PC přímo ke kabelovému modemu. Pokud bylo připojení na internet funkční byla chyba za ním - router, PC, …

Mám zde momentálně 3 počítače. Na dvou je pouze Fedora 22, 64b, XFCE a na třetím je dualboot, stejná Fedora jako vedle a navíc Windows 7, 64b.
Dále jsou tu dvě zařízení s GLAN - jednak LANová strana toho modemu TC7200 od UPC a GLAN router NetGear - mám ho půjčený z práce.
Tyto všechny 3 počítače pod Linuxem se nepřipojí ke kabelovému modemu TC7200 od UPC, ale ani k k k tomu routeru NetGear. Ani nerozsvítí link.
K těmto oběma GLAN zařízením se ale připojí routery TP-Link a Zyxel (oba 100Mbps) a ten třetí počítač, pouze pokud je nabůtován do Woken.

Tedy ano - neuvěřitelné se stalo skutkem - tentýž počítač pod Woknama normálně jede na gigabitové síti a pod Fedorou ani nenaváže link - nejen, že se nerozjede 1G, ale ani se nedohodne na tom, že pojede 100Mbps.

Ty dvě 100Mbps krabičky - TP-Link a Zyxel se alespoň domluví, že pojedou jenom na 100M.

Situace se jeví tak, že Fedora nedokáže dostat síťovku do stavu, aby navázala komunikaci s gigabitovým zařízením. Karty jsou skutečně GLANové, mají to v názvu, například
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
(to je ten počítač s dualbootem)
a
Ethernet controller: JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller (rev 03)
(to je počítač pouze s Fedorou)


[root@bedroom rna]# ethtool enp2s0
Settings for enp2s0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	Link partner advertised pause frame use: Symmetric
	Link partner advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000033 (51)
			       drv probe ifdown ifup
	Link detected: yes


.


lspci | grep -i ether

viz výše

.


[root@bedroom rna]# dmesg | grep -i eth
[    0.863044] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    0.866098] r8169 0000:02:00.0 eth0: RTL8168g/8111g at 0xffffc9000314e000, d8:cb:8a:77:14:8a, XID 0c000800 IRQ 28
[    0.866100] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[    0.884214] r8169 0000:02:00.0 enp2s0: renamed from eth0
[root@bedroom rna]# 


To jsem z toho kolouch.
Rozumíte někdo tomu, co se mi to doma děje?

Ještě poznámka:

ten výpis ethtool enp2s0 jsem dělal na funkčním připojení 100Mbps, pošítač připojen přes router Zyxel na jiného ISP než UPC.

To je skoda ze ten vypis ethtool nemame z toho Gigoveho modemu nebo routeru.

Jen jsem ted kouknul na jeden pocitac kde normalne gigabit funguje a je to dokonce stejny chipset jako mas ty, akorat jemne jina revize


05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)

Settings for enp5s0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
                                             1000baseT/Full 
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes


Trochu me zarazi, ze ti ve vypisu modu sitovky chybi 1000baseT/Half.

Jeste me napada takove kacirska myslenka - mas kabelaz pro gigabitovy ethernet?

covex napsal(a):

Jeste me napada takove kacirska myslenka - mas
kabelaz pro gigabitovy ethernet?

Aha.
Tak to asi bude problém.
Jak vypadá kabel pro GLAN?
Mám úplně obyčejné.
Že mi to nechodí z kuchyně do ložnice (25 m přes železo a silovku) to bych chápal. Musel jsem vyměnit swič, protože ten starý krám se s tímhle kabelem zasekával i na 100Mbps.
Ale nejde to ani přes 2 m kabel přímo z počítače na LANovou stranu routeru.

Ale čert to vem. Jede mi to všechno doma na 100Mbps, internet 110Mbps down a 20Mbps up. (podle údajů z panelového widgetu na XFCE)
Podle údajů ISP by to mělo být 120 down a 12 up.
Já spíše potřebuji něco jako symetrickou linku, mám tu OpenVPN server.
Tohle mi plně vyhovuje.
Dík za spolupráci.

Tak na gigovy ethernet by mel normalni cat5e kabel z kramu stacit (oznaceni by na nem melo byt napsane). Stejne tak by jiz dnes nemelo byt potreba dodrzovat krizene a nekrizene kabely, ale jistota je jistota.

Jinak muzes jeste zkusit dve veci

  1. vypnout network manager a zkusit inicializovat sitovku rucne (ifconfig up; dhclient)
  2. nastavit mod sitovky napevno a vypnout autonegotiation, zda to aspon bude fungovat
    ethtool -s enp2s0 speed 100 duplex full autoneg off

covex napsal(a):

ethtool -s enp2s0 speed 1000 duplex full autoneg off

Tak tohle jsem zkoušel, i v network-scripts/ifcfg…

Ale nic.

Teď se už do toho vrtat nebudu, protože mám 100kový router v kuchyni a 100kový swič v ložnici a moje páteřní linka (tzn. kitchen-bedroom metallic data line) nechodila pořádně ani těch 100, pokud jsem tam měl šitový swič. Teď mi to šlape v plném rozsahu technických možností a já jsem rád, že tak.

Někdy se k tomu vrátím, možná budeme ve firmě zavádět taky gigabit na každý stůl. (Páteřní optika přes 3 baráky a swiče už jsou Gb, ale jinak jsou rozvody staré. )