Názory k článku Příkaz ip: ovládněte linuxová síťová rozhraní

U mna je problem, ze som bol zvyknuty na ipconfig na windowsoch. Lahsie sa mi prechadzalo na ifconfig nez ip.

Přiznám se, že(s vědomím toho, o čem článek píše) příkaz ifconfig pořád poměrně často používám.
Je to zvyk, do příkazu ip se musím dlouhá léta prostě často nutit - ano, často to bez něj nejde.

Už tenkrát se projevilo takové jisté "bordelářství" a neúcta k Unixu, které dnes vyvrcholilo hrůzným systemd.
Syntaxe utility ip je totiž do značné míry klasickému unixovému systému cizí. Nechápu, proč ji bylo, v rámci zlepšovatelského hnutí, třeba pojmout zrovna takto.... klidně mohla být "klasická" s tím, že ifconfig mohl být už pak pouze link...

+1 myslim ze vyraz "neucta k *nixu" to presne popisuje.

Někdy se divím, co všechno se pod "neúcta k..." dá schovat.

Rozzuřenej Ovčáček si těžoval u RRTV, že se nemohl blýsknout v přímým přenosu jeho tiskovky. Důvod? "Neúcta k prezidentovi republiky".

Putin má zase cenzurní zákon, na základě kterýho může soudit oponenty. Zdůvodnění? "Budeme trestat neúctu k pravoslavné církvi a (voleným) zástupcům lidu".

Manželka jiné kremlofilní bestie si zase po zvolení manžela na hrad stěžovala na "neúctu k" tomu jejímu ožralovi, který zneuctil korunovační klenoty a snažila se tím ovlivňovat (vydírat) média v jeho prospěch.

Takže ne, tenhle argument neberu. Diskutujme věcně.

Osobně mám největší výhradu k CLI v tom, že si člověk musí pamatovat názvy všech prográmků. Pro jednu skupinyu činností jich existuje klidně i několik desítek (pro správu souborů a adresářů třeba rm, mkdir, ls, cp, mv, ....). Když si nevzpomene na název prográmku, tak má smůlu.

Nebo jde činnosti rozdělit do skupin. git, ip, yum/apt/rpm,... Pak stačí mít na paměti, že pokud chci dělat něco s sítí, začíná to na ip, takže další navigace ip --help rychle a jednoduše poradí. Je to na orientaci mnohem jednodušší.

Takže za sebe, Já společný prefix "ip" pro síťařinu vítám.

To je tim, ze pojmy jako ucta ci svoboda jsou vymysleny pro lidi a ne pro software ci systemy. Prenaseni techto pojmu do nehumanniho prostredi SW pak pusobi pojmovy zmatek.........

Nepůsobí zmatek, ale jenom slouží v diskusích jako argument ve chvíli, kdy dojdou rozumný arguemnty a diskutující se ještě nechce snížit k vulgaritám. Je to taková forma emočního vydírání při obhajobě dogmatu...

Co je spatneho na slove "neucta"?
Proc do toho zatahujete politiku?

Btw dival jsem se, jak se soudruzi postavili k IPv6 (a ano, "ip" je ocividne preferovany) http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/

a proc to neni unixove?

ip a a x.x.x.x dev eth0 brd +
ip r a default via x.x.x.x

vs (nebo jak to bylo)

ifconfig add x.x.x.x netmask y.y.y.y eth0
route add 0.0.0.0/0 gw x.x.x.x

No kdyz si nekdo ze stare verze vybere syntax tak aby podporil jeho hypotezu, to je pak tezka diskuse.

Predpokladam, ze 90% lidi s unixovym backgroundem pouziva stary system s podstatne jednodussi syntaxi:

nastaveni ip adresy
ifconfig eth0 x.x.x.x

nastaveni default route
route add default gw x.x.x.x

Ne ze bych nesouhlasil s obsahem clanku - ip ma rozhodne proti ifconfig-u spoustu prednosti ale podle mne je prave nekompatibni syntax a absence detailni dokumentace duvod proc jeste spousta lidi pouziva ifconfig.

nepoukazoval jsem na delku zapisu ale spis na to, ze tam nevidim duvod, proc to neni unixove, jak psal nekdo vysse.

kdyz uz jste napsal spravnou syntaz tak pak mi to prijde tuplem skoro stejne :)
ip r a default via x.x.x.x
route add default gw x.x.x.x

poradna dokumentace chybi, o tom zadna. ale kdyz sahnu na ifconfig, spis jen nastavuju ty ip a na to nic moc nepotrebuju. kdyz chci toho vic tak pak je problem. ale nejsem si jisty, ze me pak dokumentace ifconfigu spasi

Přesně, nechápu proč někdo

route add default gw x.x.x.x označí za linuxové a

ip route add default via x.x.x.x označí za nelinuxové

Zázada :)

ifup eth0

ifup je nadstavba nad (nejen) ifconfig nebo ip, ktera konzulteje konfigurak a pak spusti sekvenci prikazu, a treba i dhcp klienta.

To je trochu zvlastni, vzhledem k tomu, ze OSPF broadcast nepouziva (pouziva multicast, na ktery tyto adresy nejsou potreba). I kdyz mohla to pouzivat jen jako indikaci, ze jde o proadcastovou sit.

ani nevim, asi ne. sila zvyku :)

Chování ip(8) bez zadání b + mě trochu překvapilo. Čekal jsem, že se to chová stejně jako ifconfig(8) a ono ne...
(nastaví se 0.0.0.0 zatímco s b + je chování stejné jako u ifconfig(8) - podle masky)

Ono to je asi vcelku jedno. Pokud broadcast adresa neni specifikovana, tak se sice nenastavi jako soucast adresy, ale kernel stejne automaticky zavede prislusnou broadcast routu do local tabulky, takze broadcast komunikace funguje stejne jako kdyz se to nastav s b+.

Maximalne to muze zmast nektere programy, ktere broadcast adresu ctou z konfigurace rozhrani a nepocitaji s tim, ze tam byt nemusi.

Přijde mi že ze všech iproute2 příkazů je ip ještě ten na který se přešlo nejvíce (a je nejvíce připomínán, aspoň si pamatuju diskuse na abclinuxu - no dobře, teď koukám že z let 2005-2006).

Užitečnější (ve smyslu více užitečné, ne že by nebylo fajn ho občas připomenout) by mi přišlo upozorňovat na netstat vs. ss a třeba na tc.

že konečně někde vychází článek s pořádným popisem příkazu ip. Ale ono zase nic, jen trocha prázdné propagace a pár nejjednodušších příkladů.
A přitom ip je mocný a komplexní nástroj a svou komplexností by si zasloužil celý seriál. Zvláště proto, že k němu prakticky neexistuje dokumentace (stručný přehled parametrů v man stránkách za dokumentaci opravdu označit nelze). A neexistence dokumentace je jeden z podstatných důvodů, proč se mu lidé (i já) vyhýbají.

Hezky shrnuto ;)

http://sysmagazine.com/posts/138698/

IP pochovava tez vconfig. Podobne existuje tez iw ktore sa snazi vymenit iwconfig atd :)

Proc nema iw stejnou syntaxi jako ip? Je mi dost lito, ze se Linux tak zkazil a s UNIXem uz nema skoro nic spolecneho ...

Proc nepouzivam prikaz ip? Protoze delam s hlavne s UNIXy a tam je pouze ifconfig. Treba takove OpenBSD ma ifconfig implementovano velice dobre, ze s nim jde ovladat i wifi.

No nejaka dokumentacia je a podla mna dostatocna. Z ifconfig na ip som presiel pred rokmi bez toho aby som ju studoval. Dneska ifconfig pouzivam iba raritne. Najcastejsie na nejakych embended zariadeniach kde nie je iproute, ale iba ifconfig z busyboxu.

To je sice hezke, ze 'ip' je tu uz od roku 1999, ale v dobe, kdy jsem se ucil linux (kolem roku 2004) , tak vsechny clanky a serialy vesele pouzivaly ifconfig, takze i ja jsem pouzival a pouzivam ifconfig a o nejakem 'ip' jsem tehda nemel potuchy.

V uvode clanku je napisane ze net-tools obsahoval tradicne prikazy ako ifconfig, route, arp, netstat... Mna by zaujimalo, ako sa da vypisat zoznam vsetkych tcp/udp spojeni pomocou iproute2. Resp. aka utilita nahradza spominany netstat.

uz to tu padlo o par prispevku vys - ss

Vdaka, prehliadol som to a vobec som o ss netusil. Mne sa novy pristup ala iproute2 paci a ip som zacal pouzivat namiesto ifconfig asi pred 3-4 rokmi. Netusim preco by to tak nemohlo fungovat v linuxe, ked mnoho inych sietovych OS pouziva podobny styl konfiguracie.

man netstat:

NOTE
This program is obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr.

Rozdil ve vypisu mezi "netstat -lp" a "ss -lp" je markantni, to ss je tak NEPREHLEDNE. DVA radky u ss misto jednoho u netstat ? Na sirokouhlem FHD monitoru je to teda debilita

root@server /home/username # netstat -lp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:http *:* LISTEN 17293/apache2
tcp 0 0 *:ssh *:* LISTEN 402/sshd
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 10163 464/snmpd /var/agentx/master

root@server /home/username # ss -lp
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
nl UNCONN 0 0 rtnl:ntpd/24927 *

p_raw UNCONN 0 0 *:eth1 *
users:(("lldpd",­pid=442,fd=11))

Je pekne, ze vypisuji vsechny uzivatele navesene na ty porty/sockety, ale ten vypis je teda fakt opruzove neprehledny.

Ted jsem si vsiml, ze tam maji snad divny sloupce ci co ? Jakmile je delsi nazev procesu na portu, tak se posouva zbytek toho radku klidne na dalsi radek, takze vam to na dalsim radku zobrazi NIC nebo hvezdicku...:

LocalAddress:Port
9:kernel --> vejde se na cely radek
15:systemd/1 --> NEvejde se na cely radek

...wtf.

asi nějakej asciiart

Netid  State      Recv-Q Send-Q   Local Address:Port       Peer Address:Port
nl     UNCONN     0      0                 rtnl:3493                   *
nl     UNCONN     0      0                 rtnl:chrome/27206                *
nl     UNCONN     0      0                 rtnl:kernel                 *
nl     UNCONN     0      0                 rtnl:ntpd/15148                *
nl     UNCONN     0      0                 rtnl:3575                   *
nl     UNCONN     0      0              tcpdiag:kernel                 *
nl     UNCONN     0      0                   10:kernel                 *
nl     UNCONN     0      0                   15:pulseaudio/4977                *
nl     UNCONN     0      0                   15:X/3814                 *
nl     UNCONN     0      0                   15:udisksd/18271                *
nl     UNCONN     0      0                   15:chrome/27206                *
nl     UNCONN     0      0                   15:2035                   *
nl     UNCONN     0      0                   15:pulseaudio/4500                *
nl     UNCONN     0      0                   15:kernel                 *
nl     UNCONN     0      0                   15:upowerd/16234                *
nl     UNCONN     63488  0                   15:slim/3810                *
nl     UNCONN     63488  0                   15:su/6667                *
nl     UNCONN     0      0                   16:kernel                 *
nl     UNCONN     0      0                   16:3158                   *
nl     UNCONN     0      0                   18:kernel                 *

No, to by me tedy zajimalo cim to je, protoze

1] dela to KiTTY vuci Jessie
2] dela to KiTTY vuci Ubuntu 14.04.2 LTS
3] dela to xterm v Ubuntu 14.04.2 LTS
4] dela to xterm vuci Jessie
5] dela to xterm vuci Wheezy


LC_NAME=en_US.UTF-8
LANG=en_US.UTF-8
LANGUAGE=en


Je nejaky rozumny dovod, preco nechcu opravit tie chyby v ifconfig a trvaju na zmene za ip?

Mne sa paci myslienka jednej syntaxi, ktora priblizne funguje na Solarise, BSD a aj Linuxe.

Ano, patrně se na ten hnijící kód se zcela zcestným designed (viz "rozhraní" ethX.Y pro další IP adresy na tom samém rozhraní) už nechce nikdo ani podívat. Vůbec se nedivím.

Ono vubec nejde o chyby a syntax. Hlavni technicky rozdil mezi ifconfig a ip je v tom, ze ifconfig pouziva 'tradicni' API (pomoci SIOCGIFxxx ioctl() operaci), zatimco ip pouziva API zalozene na Netlinku.

Nove funkce ve starem API vubec nejsou dostupne, takze by to znamenalo cely ifconfig stejne prepsat na Netlink. Coz se vlastne udelalo, akorat se zvolila nova syntax, ktera je uniformni a nezatizena minulosti, a vysledek se jmenuje ip.

Popravdě právě netlink (respektvice spíš rtnetlink), je na celém ip největší šílenost, která mi nepřipadá jako vhodné systémové řešení, narozdíl od standardního ioctl. Navíc není rtnetlink v podstatě vůbec z dokumentovaný. Manuálová stránka rozhodně nestačí k jeho použití. Takže kdo chce toto api použít jinak než skrze utilitu ip, tak si musí přečíst celé zdrojáky ip a navíc ještě odpovídající kód z kernelu, kde je dobré připomenout, že toto api se stále ještě mění.

Toto je také nejspíš důvod, proč se někdo nesebral a nenapsal sadu utilit se stejnou funkčností, ale jinou syntaxí, nebo nerozšířil funkce ifconfig, route atd.. Jakkoli to totiž vypadá triviálně, tak se stačí podívat do kódu ip a zjistíte, že je to hotové peklo, kde je parser argumentů přímo generuje paket pro rtnetlink, jehož podoba je známa jen autorům ip.

No, jako vyvojar software pouzivajici primo rtnetlink bych k tomu neco dodal:

1) Dokumentace k rtnetlink je malo jako u vetsiny linuxoveho API, relativne k ostatnim jde ale o nadprumer. Je tu nekolik manualovych stranek, pomerne obsahle RFC 3549 a hlavickove soubory, drive nebo pozdeji clovek ale stejne sahne ke zdrojakum jadra. Nejde ani tak o konretni API (to je vcelku primocare), jako o chovani linuxoveho sitoveho stacku.

2) Ony ioctl bych neoznacoval za standardni rozhrani, pokud vim POSIX ani SUS je nedefinuji, spise se jedna o tradicni rozhrani. V Linuxu nejsou dokumentovany o moc lepe nez rtnetlnk. Jejich feature-set je beznadejne zastaraly a navic nejsou dobre rozsiritelne narozdil od rtnetlinku, ktery pouziva TLV model zprav.

3) Na BSD-variantach take nemaji tyto ioctl jako nativni rozhrani, ale pouzivaji message-based API pripominajici netlink.

Zdrojaky jsou v OSS mozna vyvojarska dokumentace. Rozhodne ne dokumentace pro adminy/usery!!! To je to co me na ekosystemu GNU/ Linuxu velmi vytaci. Neni dokumentacni kazen any u takovych dulezitych komponent jako ip utils.
V momente kdy resim pruser tak posledni vec co bych delal je studovat zdrojaky jadra a nejake api. Bohuzel u linuxovych progrosu jde hodne videt ze v podstate toho moc nevi o unixove filosofii a nedokumentace toolu nebo jen kratky neaktualni canc se stal standardem.

V clanku se uvadi, ze ifconfig nepodporuje CIDR notaci.
Na me instalaci je ifconfig v. 1.42 a prikaz

ifconfig eth0 10.9.8.7/16 funguje bez problemu.

take se uvadi ze je problem s parsovanim ve scriptech kvuli lokalizaci...
me vzdy stacilo ve skriptu pouzit: LC_ALL=C ifconfig
tedy spis povazuju pro jen cesky mluvici za nevyhodu ze ip neni lokalizovano :)

Pokud by šlo, ocenil bych, kdyby v dalším díle byly zmíněné ekvivalenty výpisu přenesených dat na portech. Pouhé zadání ifconfig mi vypíše přehledně kolik dat jednotlivé síťové karty přenesly. U ip, co jsem se díval se musí asi používat -s, ale to to zase ukazuje jenom v bajtech. Tak kdyby někdo věděl...

Je to z pohledu karty, ne pro všechny zařízení a chce to být root, ale ethtool -S říká dost.

Odchozí data z pohledu OS jsou vidět v tc -s qdisc show dev XXX.

Co je paket? To co dostane síťovka? To na co síťovká udělá interrupt? Co z toho ukazuje ifconfig?

Boha jeho. Chlapci vstavejte ti co jste ve wn zustali.

1. Ujasnete si o jake pakety na jake vrstve mi jde?
ifconfig a ethtool -S resi na counterech ethernet frames. Navic ethtool je driver dependent takze ho nejde pouzit _univerzalne_
qdisc IMHO resi pakety na IP vrstve

2. Proc te proboha zajima interrupt? Je to hw dependent. TO NERES! Nektery sitovky ti za kazdym udelaj interrupt a nektery az po milionu paketu. Jsou sitovky co dokonce interrupty negeneruji(em­bedded) a potrebujou polling nebo kombinaci obojiho.

Skusal som zmenit MAC pomocou ip link set dev wlan0 down ; ip link set dev eth0 address 11:22:33:44:55:66 ; ip link set dev wlan0 up a nedochadza k zmene. Ani ked pouzivam ifconfig. Mam USB wifi adapter ITEC , lsusb vypisuje 8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter Uz to riesim dhsie, nikde mi nevedia pomoct, skusal som aj iny USB adapter, pouzivam PCLinuxOS 64-bit LXDE. V prikazovom riadku (cez root samozrejme) vypise len 8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter

Neni nahodou ifconfig v jadre momentalne len "alias" na ip funkcie nahodou? Zda sa mi, ze povodne funkcie ifconfig bola v jadre uz odstranena a ifconfig ako prikaz bol zachovany len pre ucely kompatibility. Alebo sa mylim? Opravte alebo doplnte ma prosim pripadne.

Bych rek, ze se uz minimalne 5+ let nemylis ... a ifconfig je uz davno defakto alias k ip. A mimo jine prave proto jiz taky par patku nefunguji nektere veci, ktere puvodne fungovaly. Respektive funguji presne tak, jak to dela ip.

Tak len jedna ukazka preco asi nejeden admin (zjavne este nezvyknuty na citanie sialenych xml konfigov modernej doby) pouziva ifconfig nad ip. Ktory vystup je citatelnejsi?


T3: c@laptop: ~ $ ip route
default via 192.168.0.17 dev wlp4s0 proto static metric 600
10.0.0.0/8 via 10.226.52.1 dev tun0 proto static metric 50
10.226.52.0/22 dev tun0 proto kernel scope link src 10.226.52.208
10.226.52.0/22 dev tun0 proto kernel scope link src 10.226.52.208 metric 50
62.168.56.1 via 192.168.0.17 dev wlp4s0 proto static metric 600
192.168.0.0/20 dev wlp4s0 proto kernel scope link src 192.168.0.27
192.168.0.0/20 dev wlp4s0 proto kernel scope link src 192.168.0.27 metric 600
T3: c@laptop:
T3: c@laptop: ~ $ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.17 0.0.0.0 UG 600 0 0 wlp4s0
10.0.0.0 10.226.52.1 255.0.0.0 UG 50 0 0 tun0
10.226.52.0 0.0.0.0 255.255.252.0 U 0 0 0 tun0
10.226.52.0 0.0.0.0 255.255.252.0 U 50 0 0 tun0
62.168.56.1 192.168.0.17 255.255.255.255 UGH 600 0 0 wlp4s0
192.168.0.0 0.0.0.0 255.255.240.0 U 0 0 0 wlp4s0
192.168.0.0 0.0.0.0 255.255.240.0 U 600 0 0 wlp4s0


tak nakonec je to formatovanie aj tak zmrsene u route

Rekl bych, ze kazdy vypis, ktery obsahuje masku misto pxlen je krajne neprehledny. Preferuji tedy ip route, ale ocenil bych tam nejakou option na zarovnani jednotlivych polozek.

Když ten nový příkaz ip mi připadá tak strašně nepřehledný. Hlavne jeho hlavni vypis adres. Nemuzu ocima najit nikdy co hledám. :-D

No prave. Keby nechali rozumne formatovanie u 'ip' tak ako to vyeralo predtym, asi by nikto nemal problem prestat pouzivat zastaraly ifconfig a pod.

a obaleni balastem ze vsech stran ma vazne jen ifconfig ?? ;)
ifconfig: inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
ip addr: inet 192.168.0.1/24 brd 192.168.0.255 scope global wlan0

Tak mám dojem, že je to podobný problém, jako přesunutí ovládacích tlačítek oken u ubuntu kdysi před lety. V praxi jde o to, že uživatel efektivně něco používá, a pak, aniž by k tomu byl nějaký zřejmý důvod, se stejná věc začne dělat jinak, a je to prezentováno jako pokrok.

Proč?

Proč nemůžeme používat ifconfig, route a arp který bude mít víc funkcí a updaty jako v BSD?

Proč nemohou zůstat tlačítka vpravo?

Protože imbecilní developeři se chtějí stát něčím zajímaví a přinutí zbytek světa klikat doleva místo doprava anebo psát ip route místo route, místo toho, aby pracovali na kvalitách svého software a ctili unixovou zásadu "dont fix what works".

Howgh

IpAddress() {
echo "############­########################­##################"
echo "### 'ifconfig' is obsolete. Using: 'ip address' ###"
echo "### 'unalias ifconfig' restores the original state ###"
echo "############­########################­##################"
ip address
}
alias ifconfig='IpAd­dress'

notebooky systemd nepotrebovaly, co je to za divnej mytus ??? pokud jde o paralelni spousteni a rychlejsi start - obdoba upstart v ubuntu ciste jako init by bylo dostatecne - notebook startuje cca 6s na i5+SSD, nehlede na to ze notebook se nestartuje ale probouzi z hibernace nebo spanku... :)

Jop, pokud se ho vubec povede uspat, a pokud se ho pak jeste vubec nekdy povede probudit. Coz je casto prave se systemd, nm ... a dalsima hitech ficurama holy scifi.

Z tohoto duvodu jsem pred casem opustil linux a pouzivam ho jen bokem. Preferuji BSD a stabilni komercni unixy kde reseni postavene pred 3mi lety mohu pouzit znovu. Kde se nemusim ucit veci ktere neprinaseji zadnou pridanou hodnotu a vznikly jen lennartovskym huronskym krikem. Tam pokud se neco prekope z gruntu tak je to kvuli tomu ze stavajici zpusob uz je znacne neprehledny a nesystemovy nebo zastaraly. Byva vsak zachovana moznost delat i ty veci postaru az do nake prelomove verze za 5-10 let.
Mainframy drzi zpetnou kompatibilitu prakticky po celou dobu sve existence.

Oprava, to eth0 som tam vlozil kopirovanim, samozrejme ze zadavam wlan0
v root terminale zadam:
ip link set dev wlan0 down ; ip link set dev wlan0 address 11:22:33:44:55:66 ; ip link set dev wlan0 up
a terminal mi odpise: RTNETLINK answers: Cannot assign requested address
a po zadani ifconfig opat ukazuje povodnu MAC adresu USB wifi adaptera.
Zaujimave je aj to, ze aj ked zadam ip link set dev wlan0 down po chvili wlan0 sam nabehne bez toho aby som zadal up. Pouzivam PCLinuxOS 64bit LXDE.

Kdyby mi nekdo v roce 96 rekl ze init nahradi systemd, oss/alsu pulseaudio a ostatni clenove komunity tomu budou jeste prizvukovat, tak se jdu venovat radsi jinemu operacnimu systemu.