Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Internet a sítě => Téma založeno: matee 10 Června 2013, 12:01:49
-
Zdravím, potřeboval bych otestovat Wifi a LAN - současně.
Připojím se kabel a přes Wifi k modemu. Pokud pošlu:
ping 10.0.0.138 -I eth2
- Wifi
tak mi to dává stejnou odpověď jako
ping 10.0.0.138 -I eth0
- kabel
Zkoušel jsme nahradit eth2 za IP adreseu WifI adaptéru, ale to také nepomohlo.
Když opojím kabel, tak to prochází normálně. To, že ping přes Wifi neletí jsem ověřoval i ve statistice na modemu.
Jde tedy nějak specifikovat trasu kudy má ping letět?
-
Nevím jak je to v Cinnamon, ale v klasickém Ubuntu bych zakázal jeden druh připojení tím bych pingnul to druhé připojení.
V klasickém ubuntu 13.04 to dělám pomocí Nastavení systému -> Síť a vypínat jednotlivé druhy připojení.
Určitě někde lze nastavit prioritu jednotlivých připojení, ale to nevím kde :), pak by stačilo měnit prioritu.
Další poněkud násilnou metodou je odpojení kabelu, nebo HW vypnutí wifi na notebooku.
-
mno podle manuálu ping -I kudy kam a ne ping kam -I kudy
-
potřebuji ping na přes obě rozhraní současně. Teď jsem zkoušel přesunout parametr -I na začátek příkazu a stejně to nefunguje.
I když jsem připojen ke kabelu i Wifi současně, tak ping letí jen přes kabel.
Má to co dočinění s lokální smyčkou LO? Ubuntu si samo vybere prostupnější cestu?
-
co ti vypíše ifconfig? Opravdu máš interface eth0 a eth2? Není chyba tady?
Běžné je eth0 pro ethernet a wlan0 pro wifi, nebo případně mít wifi na eth1. Ty uvádíš, že máš eth0 a pak až eth2. Ty máš více wifi karet?
-
ifconfig
eth0 Link encap:Ethernet HWadr a4:ba:db:9f:7b:87
AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ MULTICAST MTU:1500 Metrika:1
RX packets:3892 errors:0 dropped:0 overruns:0 frame:0
TX packets:4465 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:1000
Přijato bajtů: 756722 (756.7 KB) Odesláno bajtů: 8348169 (8.3 MB)
Přerušení:18
eth2 Link encap:Ethernet HWadr c4:17:fe:29:48:78
inet adr:192.168.12.17 Všesměr:192.168.12.255 Maska:255.255.255.0
inet6-adr: fe80::c617:feff:fe29:4878/64 Rozsah:Linka
AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1
RX packets:872 errors:0 dropped:0 overruns:0 frame:537680
TX packets:953 errors:80 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:1000
Přijato bajtů: 571276 (571.2 KB) Odesláno bajtů: 232215 (232.2 KB)
Přerušení:17 Vstupně/Výstupní port:0xc000
lo Link encap:Místní smyčka
inet adr:127.0.0.1 Maska:255.0.0.0
inet6-adr: ::1/128 Rozsah:Počítač
AKTIVOVÁNO SMYČKA BĚŽÍ MTU:16436 Metrika:1
RX packets:2129 errors:0 dropped:0 overruns:0 frame:0
TX packets:2129 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:0
Přijato bajtů: 154054 (154.0 KB) Odesláno bajtů: 154054 (154.0 KB)
zkoušel jsme to i na stroji kde se rozhraní jmenují eth0 a wlan0 a taky to procházelo primárně po kabelu, i když byla nastavena trasa po wifi.
PS: nejsme připojen do 10.0.0.138, ale jen do firemni wifi.
Připojení do modemu:
ifconfig
eth0 Link encap:Ethernet HWadr a4:ba:db:9f:7b:87
inet adr:10.0.0.32 Všesměr:10.0.0.255 Maska:255.255.255.0
inet6-adr: fe80::a6ba:dbff:fe9f:7b87/64 Rozsah:Linka
AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1
RX packets:4421 errors:0 dropped:0 overruns:0 frame:0
TX packets:5073 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:1000
Přijato bajtů: 1140683 (1.1 MB) Odesláno bajtů: 8419283 (8.4 MB)
Přerušení:18
eth2 Link encap:Ethernet HWadr c4:17:fe:29:48:78
inet adr:10.0.0.33 Všesměr:10.0.0.255 Maska:255.255.255.0
inet6-adr: fe80::c617:feff:fe29:4878/64 Rozsah:Linka
AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1
RX packets:2496 errors:0 dropped:0 overruns:0 frame:813430
TX packets:2080 errors:129 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:1000
Přijato bajtů: 2501238 (2.5 MB) Odesláno bajtů: 429900 (429.9 KB)
Přerušení:17 Vstupně/Výstupní port:0xc000
lo Link encap:Místní smyčka
inet adr:127.0.0.1 Maska:255.0.0.0
inet6-adr: ::1/128 Rozsah:Počítač
AKTIVOVÁNO SMYČKA BĚŽÍ MTU:16436 Metrika:1
RX packets:2210 errors:0 dropped:0 overruns:0 frame:0
TX packets:2210 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:0
Přijato bajtů: 162023 (162.0 KB) Odesláno bajtů: 162023 (162.0 KB)
Další poznatek: jsme připojen k firemní Wifi - Intrenetu, a kabelem do modem kterej nikam nevede. Otevru prohlizec a ten se tvari jako ze jsme bez pripojeni. Az kdyz odpojim ten kabel kabel tak to jde. Omlouvam se ze nemam hacky a carky, ale pisu an fransouzky klavesnici :D
-
A zná ping implementovaný v ubuntu vůbec -I?
http://manpages.ubuntu.com/manpages/raring/man8/ping.8.html
Ono je těch pingů víc, můžeš zkusit nainstalovat nějaký jiný. Co třeba fping s parametrem -m?
http://linux.die.net/man/8/fping
-
A zná ping implementovaný v ubuntu vůbec -I?
http://manpages.ubuntu.com/manpages/raring/man8/ping.8.html
Ono je těch pingů víc, můžeš zkusit nainstalovat nějaký jiný. Co třeba fping s parametrem -m?
http://linux.die.net/man/8/fping
ping --help
ping: invalid option -- '-'
Usage: ping [-LRUbdfnqrvVaAD] [-c count] [-i interval] [-w deadline]
[-p pattern] [-s packetsize] [-t ttl] [-I interface]
[-M pmtudisc-hint] [-m mark] [-S sndbuf]
[-T tstamp-options] [-Q tos] [hop1 ...] destination
-
potřebuji ping na přes obě rozhraní současně. Teď jsem zkoušel přesunout parametr -I na začátek příkazu a stejně to nefunguje.
I když jsem připojen ke kabelu i Wifi současně, tak ping letí jen přes kabel.
Má to co dočinění s lokální smyčkou LO? Ubuntu si samo vybere prostupnější cestu?
Nevěřím tomu, že půjde ping poslat současně z obou síťových karet. PC nemůže komunikovat s více kartami současně, zvláště jsou-li různého typu.
U eth0 nevidím IP adresu, ale data tečou. Moc tomu nerozumím co máš za adaptéry?
Zajímal by mě výpis:
lspci | grep -i '\(Network \| Ethernet\)'
možná by bylo zajímavé i znát IP adresy (používáš-li IP4)
ip -o addr show|awk '/inet /{print $2":",$4}'
-
omg, hosici, ja Vam napovim .. sleduji s lehkym pobavenim tenhle thread uz od jeho vzniku :) .. co kdyby jste se nekdo zeptal na obsah routovaci tabulky ? (ip r) pripadne v jednom terminalu pingnul a ve druhem pro kontrolu `tcpdump -i eth0 icmp' a `tcpdump -i wlan0 icmp'
-
fping 10.0.0.138 -l -i 10 -S 10.0.0.33
a
fping 10.0.0.138 -l -i 10 -S 10.0.0.32
dává uplně stejnej výsledek do doby než odpojím kabel. Ve statitice vidím, že data do modemu tecou jen po kabelu.
-
Nevěřím tomu, že půjde ping poslat současně z obou síťových karet. PC nemůže komunikovat s více kartami současně, zvláště jsou-li různého typu.
[/quote]
To teda muze:) ve WIN to tak dělám uz 3 mesice.
-
Ještě k tomu ping -I, tady je kolem toho zajímavé vlákno:
Dotaz: rozdíl mezi "ping -I INTERFACE" a "ping -I IPAdresa" ? (http://www.abclinuxu.cz/poradna/linux/show/345242)
Nevěřím tomu, že půjde ping poslat současně z obou síťových karet. PC nemůže komunikovat s více kartami současně, zvláště jsou-li různého typu.
To teda muze:) ve WIN to tak dělám uz 3 mesice.
Opravdu komunikuje současně???
-
ip r
default via 10.0.0.138 dev eth0 proto static
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.32 metric 1
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.33 metric 2
lspci | grep -i '\(Network \| Ethernet\)'
09:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller (rev 13)
0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)
ip -o addr show|awk '/inet /{print $2":",$4}'
lo: 127.0.0.1/8
eth0: 10.0.0.32/24
eth2: 10.0.0.33/24
vse jde po eth0 dokud nevytahnu kabel...
-
Ještě k tomu ping -I, tady je kolem toho zajímavé vlákno:
Dotaz: rozdíl mezi "ping -I INTERFACE" a "ping -I IPAdresa" ? (http://www.abclinuxu.cz/poradna/linux/show/345242)
Nevěřím tomu, že půjde ping poslat současně z obou síťových karet. PC nemůže komunikovat s více kartami současně, zvláště jsou-li různého typu.
To teda muze:) ve WIN to tak dělám uz 3 mesice.
Opravdu komunikuje současně???
Ano, chodí. Vidím přenos paketu ktery jdou z PC do modemu po ENET1 a WL0
Zkousel jsem oboji eth0 i 10.0.0.32
-
A nepomůže ti poslat oba pingy téměř současně:
ping -I 10.0.0.32 -c 3 -nn 10.0.0.138 & ping -I 10.0.0.33 -c 3 -nn 10.0.0.138
Počet pingů n můžeš napsat za: -c n
Pozor pokud neomezíš počet pingů, budeš mít trochu problém se zastavením prvního pingu.
Jen nevím jestli půjde jednoznačně rozlišit který ping je který :-), ale třeba se pořadí neprohodí...
-
A nepomůže ti poslat oba pingy téměř současně:
ping -I 10.0.0.32 -c 3 -nn 10.0.0.138 & ping -I 10.0.0.33 -c 3 -nn 10.0.0.138
Počet pingů n můžeš napsat za: -c n
Pozor pokud neomezíš počet pingů, budeš mít trochu problém se zastavením prvního pingu.
Jen nevím jestli půjde jednoznačně rozlišit který ping je který :-), ale třeba se pořadí neprohodí...
Jednoduší je udělat skript s výstupem do souboru. Pro každý interface bych zvolil jiný soubor.
S výsledky je pak možné dál pracovat.
ten příkaz od Myrmici je nějaký divný (příkazy oddělené jedním &?)
#!/bin/bash
ping -I 10.0.0.32 -c 3 10.0.0.138 &> /tmp/eth0.log &
ping -I 10.0.0.33 -c 3 10.0.0.138 &> /tmp/eth2.log &
exit 0
Zrovna tak by mělo fungovat
#!/bin/bash
ping -I eth0 -c 3 10.0.0.138 &> /tmp/eth0.log &
ping -I eth2 -c 3 10.0.0.138 &> /tmp/eth2.log &
exit 0
-
dobrý nápad od beer:
ping -I 10.0.0.32 -c 3 -nn 10.0.0.138 > ping1.txt & ping -I 10.0.0.33 -c 3 -nn 10.0.0.138 > ping2.txt
Jen pořád pátrám proč je v uvedeném zdroji -nn, možná by stačilo jen -n, na mém PC to funguje s jedním -n i se dvěmi -nn.
(ntz z nás musí mít srandu :D)
-
ten příkaz od Myrmici je nějaký divný (příkazy oddělené jedním &?)
První ping se spustí, a hned se vrátí do terminálu, provede se druhý ping a do terminálu se vrátí až po jeho dokončení. Tím budu vědět kdy oba příkazy skončí. (první skončí chviličku před druhým, pokud je vše OK)
-
to ale neresi ten problém ze ping, kterej by mel letez pres WiFI lita pres kabel :D
schvalne to zkuste ;-) pripojite se k modemu/routeru kabelem a po wifi a pak na nej zkuzte pingnout z Woken pres LAN a WIfi a pak to stejny v Ubuntu :D
-
ten příkaz od Myrmici je nějaký divný (příkazy oddělené jedním &?)
První ping se spustí, a hned se vrátí do terminálu, provede se druhý ping a do terminálu se vrátí až po jeho dokončení. Tím budu vědět kdy oba příkazy skončí. (první skončí chviličku před druhým, pokud je vše OK)
Nevím, nemohu teď vyzkoušet. Jeden & ti dá příkaz na pozadí, pokud chceš, aby se ti druhý příkaz spustil v případě, že první dopadne dobře, tak bys měl oddělit &&. Pokud se má spustit, ať dopadne první příkaz dobře nebo špatně, tak oddělit středníkem.
Pokud tazatel chce paralelní zpracování, tak je lepší nechat příkaz na pozadí pracovat a paralelně spustit druhý ping. Ping 3 x je nedostatečný, minimálně bych nastavil 10, nebo bych řešil intervalem -i 10 a počet bych nenastavoval, killnout se dá vždycky.
#!/bin/bash
ping -I eth0 -i 10 10.0.0.138 >> /tmp/eth0.log &
ping -I eth2 -i 10 10.0.0.138 >> /tmp/eth2.log &
exit 0
-
to ale neresi ten problém ze ping, kterej by mel letez pres WiFI lita pres kabel :D
schvalne to zkuste ;-) pripojite se k modemu/routeru kabelem a po wifi a pak na nej zkuzte pingnout z Woken pres LAN a WIfi a pak to stejny v Ubuntu :D
Nevím, fungovat by to dle manu mělo takhle. Statistikám, které sám nezfalšuji, nevěřím.
-
Takže máš pravdu, že vše jde přes eth0 nebo jeli jako zdroj určená třeba wlan0 místo adresy, pak dokonce neprojde žádný ping. Je-li však jako zdroj určena eth0 pak mi ping projde.
Vypadá to jakoby se to řídilo routovací tabulkou. Pingy se snaží jít přez default (0.0.0.0) route nebo možná tou cestou kde je nastavená brána.
Moje routovací tabulka vypadá následovně:
route -n2
Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
0.0.0.0 192.168.127.10 0.0.0.0 UG 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.127.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
192.168.127.0 0.0.0.0 255.255.255.0 U 9 0 0 wlan0
A jako na potvoru mě nenapadá co s tím.
-
V práci zatím jedu na Win, ale to mi skončí a já musím přijít na to, jak tohle dělat po ubuntu.
Začínám si myslet, že by bylo lepší zůstat u francouzkého W7 než tohle :D (chápej: dostal jsem k dispozici notebook s francouzkým W7 - omítám s eučit francouzky, tak jsem tam dal ubuntu, ale nečekal jsem, že budu mít takovej problém udělat tam stejnej test modemu jako na win)
NTZ neví / neporadí?
-
Nemáš v biose funkci wlan lan switchable cosi? Pokud ano, disabluj to.
-
2NTZ: ... aneb dva Internety za cenu jednoho ... :D :D :D
-
2NTZ: ... aneb dva Internety za cenu jednoho ... :D :D :D
:D .. sleduju to se silnym zaujetim :D
-
Názor linux amatéra :)
Odejde to cestou, která má pro tvůj cíl nejnižší metriku v routovací tabulce. Tudíž chceš po prvním pingu prohodit metriky rout.
-
přepínání v BIOSu jsem taky zkusil, pokud je to funkce aktivovaná, tak se po připojení kabelu WiFi odpojí.
Ale proč to nejde cestou, kterou chci já??:)
-
Ale proč to nejde cestou, kterou chci já??:)
protoze to delas blbe a nenechas si poradit .. a stejne se bo vic pokousis o uplnou kravinu, takze bon apetit .. hlavne se u toho bav
-
jsem otevřen všem nápadum :) Potrebuju spíš navod nez radu... :(
A nemyslím, že je tu uplna blbost, muzu tak overit propustnost modemu jak po kabelu tak po Wifi. A ciste prakticka situace je kdy jsem pripojen do dvou siti - do jedny po kabelu a do jedny bezdratove - to si pak nemuzu vybrat?
Pripojil jsem se do Wifi s pristupem do internetu - ping na google projde, ale jakmile zapojim kabel, kterej do intrnetu pristup nemá, tak uz se nepropingnu.
Cele je to o tom, ze ackoliv jsem pripojen do dvou sity (Wifi + kabel) ubuntu zkousi jen ten kabel i kdyz mu nastavim at jde po wifi
Umím to ve WIN, ale chtěl bych to umět i v ubuntu.
-
a delas to spatne .. pouzivas NM a vymejslis kraviny .. ted jsem to zkousel u sebe a jde to out-of-box .. jedine, co se po tobe chce nastavit spravne ty routy a mozna jeste pro jistotu flushnout arp cache
a ve vindousech bych docela chctel videt jak to delas, protoze tam to iirc nejde ;)
-
Děkuju, ted uz aspon vim ze to jde :)
jak a kde nastavit routy? co je arp cache?:(
ve win to delam pres:
ping www.google.com -t -S 10.0.0.33
ping www.google.com -t -S 10.0.0.32
kazdej v jednom okne CMD a jedou nezavisle na sobe... odpojim kabel -> prestane odpovidat jedn odpojim wifi -> prestane odpovidat druhej.
-
v podstatě stejný problém, a taky bez jasné odpovědi :(
NTZ: Proč nenapíšeš jak se to dělá, když víš jak na to?
-
NTZ: Proč nenapíšeš jak se to dělá, když víš jak na to?
protoze se odmitam podilet na trapeni a muceni rostlin, zvirat a nebo pocitacu .. tim ten pocitac mucis, kdyz pingas ve stejnou chvili jednu destination najednou pres LAN a pres WLAN :P
-
Mne to funguje taky out of the box. A to i přesto, že mám network manager.
Důkaz:
mám rozhraní eth0 a několik tap rozhraní, například kladruby, obě fungují současně najednou, kladruby je virtuální n2n edge tap rozhraní, pro svůj chod potřebuje eth0, obě fungují tedy současně, avšak kladruby je jen taková lan, když pošlu ping na kladruby-desktop (ip adresa k hostu mám v /etc/hosts), tak zkrze virtuální tap rozhraní kladruby projde, ale zkrze samotné fyzické rozhraní eth0 ne:
ping -I kladruby -M do -s 1372 kladruby-desktop -c 5
PING kladruby-desktop (10.3.3.2) from 10.3.3.1 kladruby: 1372(1400) bytes of data.
1380 bytes from kladruby-desktop (10.3.3.2): icmp_req=1 ttl=64 time=88.4 ms
1380 bytes from kladruby-desktop (10.3.3.2): icmp_req=2 ttl=64 time=72.9 ms
1380 bytes from kladruby-desktop (10.3.3.2): icmp_req=3 ttl=64 time=94.7 ms
1380 bytes from kladruby-desktop (10.3.3.2): icmp_req=4 ttl=64 time=123 ms
1380 bytes from kladruby-desktop (10.3.3.2): icmp_req=5 ttl=64 time=143 ms
--- kladruby-desktop ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 72.943/104.739/143.770/25.542 m
ping -I eth0 -M do -s 1372 kladruby-desktop -c 5
PING kladruby-desktop (10.3.3.2) from 10.3.3.1 eth0: 1372(1400) bytes of data.
--- kladruby-desktop ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4032ms
Koukám do manuálové stránky pingu a je tam možnost i přidat volbu -r, která obejde routovací tabulky.
S wifinou to zkoušet nebudu, musel bych hledat notebook a pak ještě šoupat se stolem, abych zapojil UTP kabel z pc do notebooku.
-
ten příkaz od Myrmici je nějaký divný (příkazy oddělené jedním &?)
První ping se spustí, a hned se vrátí do terminálu, provede se druhý ping a do terminálu se vrátí až po jeho dokončení. Tím budu vědět kdy oba příkazy skončí. (první skončí chviličku před druhým, pokud je vše OK)
Hmm, ono to vážně asi takto funguje, to jsem netušil. Myslel jsem, že jeden & dává na pozadí. Potom mi uniká rozdíl mezi && a &.
Teď k tématu, vyzkoušejte tedy s volbou -r kdo máte wifinu i kabel po ruce :)
-r
Bypass the normal routing tables and send directly to a host on an attached interface. If the host is not on a directly-attached network, an error is returned. This option can be used to ping a local host through an interface that has no route through it provided the option -I is also used
-
ten příkaz od Myrmici je nějaký divný (příkazy oddělené jedním &?)
První ping se spustí, a hned se vrátí do terminálu, provede se druhý ping a do terminálu se vrátí až po jeho dokončení. Tím budu vědět kdy oba příkazy skončí. (první skončí chviličku před druhým, pokud je vše OK)
Hmm, ono to vážně asi takto funguje, to jsem netušil. Myslel jsem, že jeden & dává na pozadí. Potom mi uniká rozdíl mezi && a &.
Zde je popis: http://www.linuxexpres.cz/praxe/bash-10-dil
Význam konstrukcí && a || lze odvodit také z formální logiky, kde && představuje logické AND (tj. příkaz1 a současně příkaz2). || je pak ztvárněním logického OR, tedy příkaz1 nebo příkaz2.
příkaz1 && příkaz2 - příkaz2 bude proveden pouze v případě, že příkaz1 skončí s návratovým kódem 0.
To znamená, že příkaz2 se provede, pokud příkaz1 skončí úspěchem. V následujícím příkladu si necháme v závislosti na výsledku operace zobrazit veselou emotikonu:
$ ls /home && echo ':-)'
bohdan pavel petr
:-)
$ ls /mohe && echo ':-)'
ls: /mohe: není souborem ani adresářem
-
NTZ: Proč nenapíšeš jak se to dělá, když víš jak na to?
protoze se odmitam podilet na trapeni a muceni rostlin, zvirat a nebo pocitacu .. tim ten pocitac mucis, kdyz pingas ve stejnou chvili jednu destination najednou pres LAN a pres WLAN :P
tak ono při "TESTOVÁNÍ" je nutný ty stoje trápit. Nedělám to jen tak pro legraci, když mi přijde na stůl modem s popisem závady "nefunguje", tak nestačí zapojit ho na adaptér a podívat se jestli svítí diody. Lidi si obšas myslím, že s tím zařízením obsloužej celou ulici a intrentovou kavárnu k tomu. Já nemám na každej kus půl hodiny, abych mohl testovat ETH a pak WLAN. Takže to dělám dohromady, a pod Win docela úspěšně. Ale jak už jsem psal chtěl bych to rozjet i pod ubuntu.
Zdá se, že s paramatrem -r to funguje. Tak jak bych očekával - ale jsem teď na stroji kde mám rozhraní ETH0 a WLAN0 a jinej typ modemu (což předpokládám by nemělo mít vliv)
-
Zdá se, že s paramatrem -r to funguje. Tak jak bych očekával - ale jsem teď na stroji kde mám rozhraní ETH0 a WLAN0 a jinej typ modemu (což předpokládám by nemělo mít vliv)
Tak super, tak to zkoušej dál, a pokud bude fungovat, tak pak uzavři jako [vyřešeno].
-
do práce jdu až příští měsíc, tak to pak zkusím na tom firemním stroji...
-
tak v práci s s tím -r neprojde. Funguje pouze pokud jde ping na modem/router, ale do internetu už neprojde. :-[ :-[ Děkuju za další nápady.
eth0 Link encap:Ethernet HWadr a4:ba:db:9f:7b:87
inet adr:10.0.0.32 Všesměr:10.0.0.255 Maska:255.255.255.0
inet6-adr: fe80::a6ba:dbff:fe9f:7b87/64 Rozsah:Linka
AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1
RX packets:49979 errors:0 dropped:1 overruns:0 frame:0
TX packets:48958 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:1000
Přijato bajtů: 22849735 (22.8 MB) Odesláno bajtů: 29475703 (29.4 MB)
Přerušení:18
eth2 Link encap:Ethernet HWadr c4:17:fe:29:48:78
inet adr:10.0.0.33 Všesměr:10.0.0.255 Maska:255.255.255.0
inet6-adr: fe80::c617:feff:fe29:4878/64 Rozsah:Linka
AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1
RX packets:32802 errors:0 dropped:0 overruns:0 frame:1834825
TX packets:31021 errors:492 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:1000
Přijato bajtů: 18056766 (18.0 MB) Odesláno bajtů: 13380723 (13.3 MB)
Přerušení:17 Vstupně/Výstupní port:0xc000
lo Link encap:Místní smyčka
inet adr:127.0.0.1 Maska:255.0.0.0
inet6-adr: ::1/128 Rozsah:Počítač
AKTIVOVÁNO SMYČKA BĚŽÍ MTU:16436 Metrika:1
RX packets:16548 errors:0 dropped:0 overruns:0 frame:0
TX packets:16548 errors:0 dropped:0 overruns:0 carrier:0
kolizí:0 délka odchozí fronty:0
Přijato bajtů: 1479420 (1.4 MB) Odesláno bajtů: 1479420 (1.4 MB)
iwconfig
eth0 no wireless extensions.
eth2 IEEE 802.11abg ESSID:"Internet 117QJA14667"
Mode:Managed Frequency:2.427 GHz Access Point: 38:72:C0:0A:95:B9
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
lo no wireless extensions.
ip r
default via 10.0.0.138 dev eth0 proto static
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.32 metric 1
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.33 metric 2
169.254.0.0/16 dev eth0 scope link metric 1000
ping -c 3 -r -I eth0 www.google.com
PING www.google.com (173.194.113.144) from 10.0.0.32 eth0: 56(84) bytes of data.
From Inspiron-1545.local (10.0.0.32) icmp_seq=1 Destination Host Unreachable
From Inspiron-1545.local (10.0.0.32) icmp_seq=2 Destination Host Unreachable
From Inspiron-1545.local (10.0.0.32) icmp_seq=3 Destination Host Unreachable
--- www.google.com ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms
pipe 3
ping -r -c 3 -I eth2 www.google.com
PING www.google.com (173.194.113.144) from 10.0.0.32 eth2: 56(84) bytes of data.
From Inspiron-1545 (10.0.0.33) icmp_seq=1 Destination Host Unreachable
From Inspiron-1545 (10.0.0.33) icmp_seq=2 Destination Host Unreachable
From Inspiron-1545 (10.0.0.33) icmp_seq=3 Destination Host Unreachable
--- www.google.com ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2014ms
pipe 3
ping -c 3 -r -I 10.0.0.33 www.google.com
PING www.google.com (173.194.113.144) from 10.0.0.33 : 56(84) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
--- www.google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms
ping -r -c 3 -I 10.0.0.32 www.google.com
PING www.google.com (173.194.113.144) from 10.0.0.32 : 56(84) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
--- www.google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms
použil bych CODE, ale nejde tam měnit barva písma...
-
byl bych moc vděčný :), kdyby někdo poradil jak přinutit ubuntu aby se přestalo chovat jako router a já mohl házet ping kudy a kam chci :)
-
byl bych moc vděčný :), kdyby někdo poradil jak přinutit ubuntu aby se přestalo chovat jako router a já mohl házet ping kudy a kam chci :)
Napíšu to podruhý trochu zjednodušeně protože se mi nezdá, že jsi to zkusil.
Odeslaný packet se řídí routama a pro stejnej cíl pak podle metriky.
- Ping poprvý,
- Odeber routu po který to šlo
- Ping podruhý
- Vrať odebranou routu zpět
-
byl bych moc vděčný :), kdyby někdo poradil jak přinutit ubuntu aby se přestalo chovat jako router a já mohl házet ping kudy a kam chci :)
ty to ale celou dobu delas bud spatne a bulikujes nas a nebo je ubuntu trestuhodne zabugovany
-
umim si predstavit, ze mas v jedny siti dva interface a ty pouzivas jeden na data a druhej na internet takto:
mas dva rozsahy (10.0.0.0/24 na internet a 10.0.1.0/24 na data) a v etc/hosts a nebo v dns mas hosty s CIFS v datovem rozsahu a router samotnej a povolenej forward v netovem rozsahu .. default gw je samozrejme v netu
hotovo a bez uchylnyho pingovani a delani veci spatne
-
umim si predstavit, ze mas v jedny siti dva interface a ty pouzivas jeden na data a druhej na internet takto:
mas dva rozsahy (10.0.0.0/24 na internet a 10.0.1.0/24 na data) a v etc/hosts a nebo v dns mas hosty s CIFS v datovem rozsahu a router samotnej a povolenej forward v netovem rozsahu .. default gw je samozrejme v netu
hotovo a bez uchylnyho pingovani a delani veci spatne
teď to vypadá na úplný nepochopení toho oč se snažím... :( Už jsem zjistil, že UBUNTU může být připojené do dvou sítí současně. ALE tu nejde o sdílení dat nebo něco podobného.
Mám jeden MODEM 10.0.0.138 - který přiděluje adresy v rozsahu 10.0.0.1-XX. K tomu mám jeden Notebook s UBUNTU s WFI a ETH.
A já potřebuji poslat ping z ETH (10.0.0.32 eth0) a WiFI (10.0.0.33 eth2) přes MODEM do Internetu. Je pro mě důležité aby to co má letět po drátě šlo po drátě a co vzduchem šlo vzduchem. Jinak nepoznám jestli je modem na 100% funkční. Samozřejmě,že můžu nejdřív zkusit kabel a pak wifi, ale celé by to trvalo 2x déle.
Chápu, že se to zdá jako nesmysl, ale pokud někdo napíše "k modemu se nejde připojit anipo kabelu ani po wifi" tak je na mě abych mu dokázal, že to jde a pokud možno v co nejkratším čase.
-
ach jo, tak nic .. prosim popros o pomoc nejakeho dospeleho ze sveho okoli .. zda se, ze zde na foru nenajdes pochopeni ..
-
Když je to tak důležitý a nejde Vám udělat ping tak jak chce když jsou oboje rozhraní připojený, tak si udělejte skript který to testne seriově včerně připojování/odpojování konfigurace obou rozraní a následného pingu. Pokud jsem to pochopil tak to že ty data netečou ve stejný čas je Vám jedno ne?
-
Když je to tak důležitý a nejde Vám udělat ping tak jak chce když jsou oboje rozhraní připojený, tak si udělejte skript který to testne seriově včerně připojování/odpojování konfigurace obou rozraní a následného pingu. Pokud jsem to pochopil tak to že ty data netečou ve stejný čas je Vám jedno ne?
Testovat to postupně není řešení - z časového hlediska nemožný.
Nechci se tu ohánět Windowsem, ale tam je to otázka nápovědy a co říká nápověda to funguje. Nevím proč UBUNTU dělá věci jinak, než je psáno :/
-
ach jo, tak nic .. prosim popros o pomoc nejakeho dospeleho ze sveho okoli .. zda se, ze zde na foru nenajdes pochopeni ..
nevím, co dělám blbě... Předpokládal jsem, že ping je natolik primitivní nástroj, že mezi Win a ubuntu nebude rozdíl.
Copak je by vám to ublížilo napsat sem 2 příkazy, který pošlou ping přes MNOU definovaný rozhraní (která se nacházej ve stejným subnetu) a tím rozhraním ten ping taky odejde? Teď to funguje tak, že já pošlu ping přes Wifi a z pc to odejde po kabelu.
Praktický využití toho je nulové, ale jak jsem psal nejde o praxi, ale o testovani.
-
To jsou nějaké závody v testování Wifi routerů? S tímhle přístupem je ale nevyhraješ!
Už píšu třetí post a furt si nemyslím že by jsi něco z toho co jsem napsal vyzkoušel. :-[
A když to zafunguje, napíšeš si script a je to jedním příkazem během chvilky hotový. To platí i pro radu od ETNyx
-
Testovat to postupně není řešení - z časového hlediska nemožný.
Nechci se tu ohánět Windowsem, ale tam je to otázka nápovědy a co říká nápověda to funguje. Nevím proč UBUNTU dělá věci jinak, než je psáno :/
Tak nevím to těch routerů testujete 1000 denně? Navíc automatizace tím skriptem by byla možná rychlejší nez ty vaše dva pingy ručně. Jaká je vaše současná strategie na windows? všechno připravíte ručně a naklikáte přes ikonky appletu networkmanagera? Ten skript by Vás postupně provedl všim v jednom okně. Stačí vybrat nástroj pro pripojení wifi pro pohodlnost napsaný v ncruses jeden prompt pro ziskaní cilové adresy a je to.
Bohužel Ubuntu už nepoužívám ale situaci jsem si vyzkoušel na svém systému a vše fungovalo bez jakéhokoliv zásahu do systému.
ping -r -i 0.001 -I enp2s0 -c 1 192.168.1.1
ping -r -i 0.001 -I wlp3s0 -c 1 192.168.1.1
-------------------------------------------------------------------------------------------
No. Time Source Destination Protocol Length Info
1 0.000000000 192.168.1.121 192.168.1.1 ICMP 98 Echo (ping) request id=0x3c8d, seq=1/256, ttl=64
2 0.000487000 192.168.1.1 192.168.1.121 ICMP 98 Echo (ping) reply id=0x3c8d, seq=1/256, ttl=64
3 0.001965000 192.168.1.101 192.168.1.1 ICMP 98 Echo (ping) request id=0x3c8e, seq=1/256, ttl=64
4 0.007339000 192.168.1.1 192.168.1.101 ICMP 98 Echo (ping) reply id=0x3c8e, seq=1/256, ttl=64
-
To jsou nějaké závody v testování Wifi routerů? S tímhle přístupem je ale nevyhraješ!
Už píšu třetí post a furt si nemyslím že by jsi něco z toho co jsem napsal vyzkoušel. :-[
A když to zafunguje, napíšeš si script a je to jedním příkazem během chvilky hotový. To platí i pro radu od ETNyx
reklamační oddělení :) těch routerů tu udělám tak 30 za den. Těch co je potřeba testovat přes LAN i WiFi je méně.
Neumím psát scripty a nevím jak a kde nastavit routy.
-
Jaká je vaše současná strategie na windows? všechno připravíte ručně a naklikáte přes ikonky appletu networkmanagera?
Připojím modem kabelem a nakonfiguruji mu Wifi. Připojím se k Wifi. A ve dvou oknech CMD spustím ping.
ping [cíl] -t -S [adresa LAN]
ping [cíl] -t -S [adresa WIfi]
a pak pomocí Ctrl + Break kontroluji výsledek. (což mi v ubuntu taky chybí)
-
Celej problém je v tom, že to nebere v potaz parametr -I respektive -r. Z toho co jsem zkoušel, jsem došel k závěru, že ubuntu se chová jako router, pošlu mu příkaz z Wifi, ono se s tím popere a pošle ho dál po kabelu do modemu. Ale já potřebuju aby to šlo přímo z WiFi do modemu.
Zkusil jsem vypnou rozhraní lo, ale to už pak neprošlo vůbec nic.
-
Tyhle věci vůbec nepotřebuješ na otestování routerů.
-
Tyhle věci vůbec nepotřebuješ na otestování routerů.
jak to tedy testnout elegantněji?
-
Jako nevím,... když jsme testovali routery, stačil selskej rozum a trocha vědomostí. A prostě to šlo jako na seriovém drátku.
-
a pak pomocí Ctrl + Break kontroluji výsledek. (což mi v ubuntu taky chybí)
není to náhodou to samé jako ctr+c?
-
a pak pomocí Ctrl + Break kontroluji výsledek. (což mi v ubuntu taky chybí)
není to náhodou to samé jako ctr+c?
Je :)
-
Jako nevím,... když jsme testovali routery, stačil selskej rozum a trocha vědomostí. A prostě to šlo jako na seriovém drátku.
a jak doložíš výsledek testování? Jasný, že to můžu zapojit pustit si HD strem nějakej ten download a říct, že to funguje. Ping mi dává možnost doložit výsledek testu.
a pak pomocí Ctrl + Break kontroluji výsledek. (což mi v ubuntu taky chybí)
není to náhodou to samé jako ctr+c?
V linuxu asi ano, ale pod WIN Ctrl C ukončí příkaz, zatímco Ctrl Break zobrazí průběžný výsledek. - To jsem vyřešil nástrojem MTR, nebo použitím klikátka v "síťové nástroje"
-
Ctrl + Break je pod linuxem nahrazeno CTRL+| (Control key followed by pipe symbol) neboli Ctrl + pravý Alt + w
dává průbežnou statistiku bez přerušení příkazu. V manuálu o tom nic není:(
zdroj: http://www.thegeekstuff.com/2009/11/ping-tutorial-13-effective-ping-command-examples/
-
dnes jsem udělal zajímavý pokus.
K modem jsem připojil 2 PC - Ubuntu a Win. Vista - z obou zařízení jsem poslal permanentní PING na modem a na www.google.com a nechal běžet přes noc. Výsledek mě dost překvapil
Proč má Ubuntu víc chyb? A proč Ubuntu chybuje i při pingu na modem, i když z Visty je jasné že ten modem byl celou noc živej?
Může to bejt problém na eth0 LAN port?
Ubuntu --- www.google.com ping statistics ---
67922 packets transmitted, 67422 received, +319 errors, 0% packet loss, time 68043758ms
rtt min/avg/max/mdev = 39.642/40.541/122.523/0.553 ms, pipe 3
Ubuntu --- 10.0.0.138 ping statistics ---
68028 packets transmitted, 68017 received, 0% packet loss, time 68027192ms
rtt min/avg/max/mdev = 0.368/0.576/20.616/0.235 ms
Win Vista Statistika ping pro 173.194.69.106:
Pakety: Odeslané = 67620, Přijaté = 67582, Ztracené = 38 (ztráta 0%),
Přibližná doba do přijetí odezvy v milisekundách:
Minimum = 40ms, Maximum = 69ms, Průměr = 40ms
Win Vista Statistika ping pro 10.0.0.138:
Pakety: Odeslané = 67792, Přijaté = 67792, Ztracené = 0 (ztráta 0%),
Přibližná doba do přijetí odezvy v milisekundách:
Minimum = 0ms, Maximum = 16ms, Průměr = 0ms
-
Zkus nastavit ručně MTU na stejnou hodnotu v obou systémech, například 1492. A z Visty pingej na google.com, ne na 173.194.69.106.
-
v obouch systémech je MTU nastaveno na 1500.
Ping je spuštěn na www.google.com, ale oba systémy si to po chvíli pingání přepíší na IP adresu.
-
1500 je defaultní hodnota, to bývá na automatické volbě, ta ve windows funguje zřejmě o něco lépe. Pokud máš ADSL/VDSL nebo UPC, tak si nastav ručně 1492.
-
1500 je defaultní hodnota, to bývá na automatické volbě, ta ve windows funguje zřejmě o něco lépe. Pokud máš ADSL/VDSL nebo UPC, tak si nastav ručně 1492.
teď mě napadlo jaká je defaultní hodnota čekání na odezvu - doba po který je paket vyhodnocen jako ztracenej?
-
1500 je defaultní hodnota, to bývá na automatické volbě, ta ve windows funguje zřejmě o něco lépe. Pokud máš ADSL/VDSL nebo UPC, tak si nastav ručně 1492.
teď mě napadlo jaká je defaultní hodnota čekání na odezvu - doba po který je paket vyhodnocen jako ztracenej?
Toto bych za tím asi nehledal, pokud ty stroje běžely zaráz, ukázala by se ve statistice Win jako max hodnota nějaká brutálnost. Ty errory bych spíše přičítal chybě HW, prvně bych se mrkl na kabeláž, pak na switch a v poslendí řadě na síťovku (tady je ještě možnost chyb driveru ...)
Protože jsme na linuxu, podíval bych se do logu z noci, zda tam nebudou hlášky typu "link down" atp.
-
1500 je defaultní hodnota, to bývá na automatické volbě, ta ve windows funguje zřejmě o něco lépe. Pokud máš ADSL/VDSL nebo UPC, tak si nastav ručně 1492.
teď mě napadlo jaká je defaultní hodnota čekání na odezvu - doba po který je paket vyhodnocen jako ztracenej?
Toto bych za tím asi nehledal, pokud ty stroje běžely zaráz, ukázala by se ve statistice Win jako max hodnota nějaká brutálnost. Ty errory bych spíše přičítal chybě HW, prvně bych se mrkl na kabeláž, pak na switch a v poslendí řadě na síťovku (tady je ještě možnost chyb driveru ...)
Protože jsme na linuxu, podíval bych se do logu z noci, zda tam nebudou hlášky typu "link down" atp.
switch tam není, obě pc byly zapojený napřímo do modem-routeru. Teď mi tam zas jeden běží, tak uvidím v pondělí jakej bude výsledek.
Do jakýho logu bych se měl podívat? S tím logem jsi mi vnukl myšlenku, že jsem mohl zapnout logovaní i na tom modem-routeru.
-
Switch je součástí toho modemu.
A /var/log/syslog případně se to myslím objevuje ve /var/log/messages
-
Tak trochu mi tady uchází smysl, přípomínáš mi toho Řeka, jak tlačil kouli do kopce. Jo a už se těším až se bude řešit příbuzné téma - Ping přes dvě různá rozhraní současně už mi jede, ale nejdu do internetu, co s tím? ;)
-
Tak trochu mi tady uchází smysl, přípomínáš mi toho Řeka, jak tlačil kouli do kopce. Jo a už se těším až se bude řešit příbuzné téma - Ping přes dvě různá rozhraní současně už mi jede, ale nejdu do internetu, co s tím? ;)
Smysl je ten, že pokud dělám test, tak očekávám stejnej výsledek jak pod WIN tak pod UBUNTU. A nečekám že ubuntu ztratí 10x víc.
Je trochu divný, když mi linux pakety ztrácí a windows ne. A to nemluvím o tom, že u win můžu nastavit rozhraní odkud má paket odejít, to s emi v linuxu zatím nepovedlo.
-
děkuju všem za trpělivost, ale tady jde o to že by Ubuntu na mém stroji mělo fungovat jako referenční - testovací nástroj. => mělo by být spolehlivé, a né davat falešně negativní výsledky.
Pokud mi někdo poradí, jak to dělat jinak a lépe budu jedině rád:)
-
To je těžký. Teď jsem taky řešil, proč mi wifi karta v Linuxu jede na 1/4(zbytek paketů v čudu, ale alespoň něco přes to lze dělat.) a ve Windows vůbec(zkoušel jsem 3 ovladače-2 od Microsoftu... ty měly úplně pšouklé výchozí nastavení=vadné! a 1 od výrobce-beta prej-aby si lidi nemohli stěžovat). Prašť jak uhoď. No nenakopal bys někoho za tohle do řiti?
Přitom se vše tváří ok. Je to starší kousek(b/g).
-
ta po víkendovém testování je výsledek:
rozdíl sice menší, ale ubuntu pořád ztrácí víc než vista:( Doba odezvy u obou stejná, ale ty ztráty nechápu...
Ub. google
--- www.google.com ping statistics ---
243546 packets transmitted, 243533 received, +3 errors, 0% packet loss, time 243544542ms
rtt min/avg/max/mdev = 41.197/42.194/144.810/1.093 ms, pipe 3
UB. modem
--- 10.0.0.138 ping statistics ---
243542 packets transmitted, 243530 received, 0% packet loss, time 243540463ms
rtt min/avg/max/mdev = 0.246/0.413/14.456/0.115 ms
Win. google
Statistika ping pro 173.194.69.104:
Pakety: Odeslané = 242936, Přijaté = 242935, Ztracené = 1 (ztráta 0%),
Přibližná doba do přijetí odezvy v milisekundách:
Minimum = 41ms, Maximum = 167ms, Průměr = 42ms
Win. modem
Statistika ping pro 10.0.0.138:
Pakety: Odeslané = 242864, Přijaté = 242864, Ztracené = 0 (ztráta 0%),
Přibližná doba do přijetí odezvy v milisekundách:
Minimum = 0ms, Maximum = 14ms, Průměr = 0ms
var/log/syslog: neukazuje skoro nic, až na to že jsem v půl 10. přišel do práce a zapojil myš.
Sep 23 07:35:12 Inspiron-1545 rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="863" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Sep 23 07:35:12 Inspiron-1545 anacron[15515]: Job `cron.daily' terminated
Sep 23 07:40:01 Inspiron-1545 anacron[15515]: Job `cron.weekly' started
Sep 23 07:40:01 Inspiron-1545 anacron[15733]: Updated timestamp for job `cron.weekly' to 2013-09-23
Sep 23 07:42:04 Inspiron-1545 anacron[15515]: Job `cron.weekly' terminated
Sep 23 07:42:04 Inspiron-1545 anacron[15515]: Normal exit (2 jobs run)
Sep 23 08:17:01 Inspiron-1545 CRON[15769]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Sep 23 09:17:01 Inspiron-1545 CRON[15801]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Sep 23 09:33:29 Inspiron-1545 kernel: [855448.009967] atkbd serio0: Unknown key pressed (translated set 2, code 0x8d on isa0060/serio0).
Sep 23 09:33:29 Inspiron-1545 kernel: [855448.009973] atkbd serio0: Use 'setkeycodes e00d <keycode>' to make it known.
Sep 23 09:33:32 Inspiron-1545 kernel: [855450.680795] atkbd serio0: Unknown key pressed (translated set 2, code 0x8d on isa0060/serio0).
Sep 23 09:33:32 Inspiron-1545 kernel: [855450.680801] atkbd serio0: Use 'setkeycodes e00d <keycode>' to make it known.
Sep 23 09:37:18 Inspiron-1545 kernel: [855677.056052] usb 6-2: new low-speed USB device number 9 using uhci_hcd
Sep 23 09:37:18 Inspiron-1545 kernel: [855677.225097] usb 6-2: New USB device found, idVendor=0461, idProduct=4de2
Sep 23 09:37:18 Inspiron-1545 kernel: [855677.225102] usb 6-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
Sep 23 09:37:18 Inspiron-1545 kernel: [855677.225105] usb 6-2: Product: USB Optical Mouse
Sep 23 09:37:18 Inspiron-1545 mtp-probe: checking bus 6, device 9: "/sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2"
Sep 23 09:37:18 Inspiron-1545 mtp-probe: bus: 6, device: 9 was not an MTP device
Sep 23 09:37:18 Inspiron-1545 kernel: [855677.242650] input: USB Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.0/input/input24
Sep 23 09:37:18 Inspiron-1545 kernel: [855677.242850] hid-generic 0003:0461:4DE2.0008: input,hidraw0: USB HID v1.11 Mouse [USB Optical Mouse] on usb-0000:00:1d.0-2/input0
Sep 23 09:45:27 Inspiron-1545 kernel: [856165.500728] atkbd serio0: Unknown key pressed (translated set 2, code 0x8d on isa0060/serio0).
Sep 23 09:45:27 Inspiron-1545 kernel: [856165.500733] atkbd serio0: Use 'setkeycodes e00d <keycode>' to make it known.
Sep 23 09:45:29 Inspiron-1545 kernel: [856168.211648] atkbd serio0: Unknown key pressed (translated set 2, code 0x8d on isa0060/serio0).
Sep 23 09:45:29 Inspiron-1545 kernel: [856168.211654] atkbd serio0: Use 'setkeycodes e00d <keycode>' to make it known.
-
Možná by se ti hodilo navštívit linuxdays a zeptat se tam nějakých odborníků, s tím nižším výkonem by ti sice asi neporadili, myslím, že těžko to může na dálku nějak hádat, ale jak testovat dvě rozhraní najednou třeba jo...
Demo: Multipath TCP (Ondřej Caletka) (https://www.google.com/calendar/render?eid=aHQ2MTRpMnJ0cWIwYjRoaWtvb3EwdnMwaWMgaHJ1c2Vja3kubmV0X2U1MjJnOGVyY2c3N2drbDlnNzJzdTkzaDdvQGc&ctz=Europe/Prague&sf=true&output=xml)
-
Možná by se ti hodilo navštívit linuxdays a zeptat se tam nějakých odborníků, s tím nižším výkonem by ti sice asi neporadili, myslím, že těžko to může na dálku nějak hádat, ale jak testovat dvě rozhraní najednou třeba jo...
Demo: Multipath TCP (Ondřej Caletka) (https://www.google.com/calendar/render?eid=aHQ2MTRpMnJ0cWIwYjRoaWtvb3EwdnMwaWMgaHJ1c2Vja3kubmV0X2U1MjJnOGVyY2c3N2drbDlnNzJzdTkzaDdvQGc&ctz=Europe/Prague&sf=true&output=xml)
díky, za tip :)
-
Trocha hledání dává tušit, že se ping na obou OS trochu liší. Ne o moc, ale možná dost o to, aby to vysvětlovalo pozorované. Jsou tam drobné rozdíly v tom, jak ping přistupuje k velikosti paketu a časování.
Možná by bylo zajímavější spustit fping ...
Jen pro detail:
WIN> Příkaz PING na server [192.168.1.1] - 32 bajtů dat:
LIN> PING server (192.168.1.1) 56(84) bytes of data.
Tedy 32 vs. 56 byte dat v defaultu ...
Předpokládám, že velikost hlaviček je stejná na obou systémech.
-
Trocha hledání dává tušit, že se ping na obou OS trochu liší. Ne o moc, ale možná dost o to, aby to vysvětlovalo pozorované. Jsou tam drobné rozdíly k tomu, jak ping přistupuje k velikosti paketu a časování.
Možná by bylo zajímavější spustit fping ...
v dlaším testu porovnám výsedky fping a ping :)
-
Trocha hledání dává tušit, že se ping na obou OS trochu liší. Ne o moc, ale možná dost o to, aby to vysvětlovalo pozorované. Jsou tam drobné rozdíly k tomu, jak ping přistupuje k velikosti paketu a časování.
Možná by bylo zajímavější spustit fping ...
v dlaším testu porovnám výsedky fping a ping :)
fping existuje i pro Windows, nevím sice, zda je to totožný produkt, ale ...
-
díky, fping a ping ve windows davaj schodnej výsldek aspoň co se ztrát týká...
UB. ping
--- www.google.com ping statistics ---
13263 packets transmitted, 13260 received, 0% packet loss, time 66263829ms
rtt min/avg/max/mdev = 40.303/47.260/80.982/8.841 ms
--- 10.0.0.138 ping statistics ---
66268 packets transmitted, 66268 received, 0% packet loss, time 66266856ms
rtt min/avg/max/mdev = 0.292/0.482/14.715/0.135 ms
FPING
www.google.com : xmt/rcv/%loss = 34468/34458/0%, min/avg/max = 40.5/51.1/81.7
10.0.0.138 : xmt/rcv/%loss = 66064/66064/0%, min/avg/max = 0.35/0.53/12.3
Win. ping
Statistika ping pro 173.194.32.242:
Pakety: Odeslané = 66053, Přijaté = 66043, Ztracené = 10 (ztráta 0%),
Přibližná doba do přijetí odezvy v milisekundách:
Minimum = 40ms, Maximum = 111ms, Průměr = 46ms
Statistika ping pro 10.0.0.138:
Pakety: Odeslané = 66078, Přijaté = 66078, Ztracené = 0 (ztráta 0%),
Přibližná doba do přijetí odezvy v milisekundách:
Minimum = 0ms, Maximum = 10ms, Průměr = 0ms
To bychom měli, teď ještě aby paramert -S u fping dělal to co má:)
-
A nedělá? :)
root@server:/home/merlin# tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:22:36.276458 IP 192.168.1.12 > 192.168.1.1: ICMP echo request, id 22988, seq 0, length 76
13:22:36.276485 IP 192.168.1.1 > 192.168.1.12: ICMP echo reply, id 22988, seq 0, length 76
13:22:37.491256 IP 192.168.1.13 > 192.168.1.1: ICMP echo request, id 22989, seq 0, length 76
13:22:37.491283 IP 192.168.1.1 > 192.168.1.13: ICMP echo reply, id 22989, seq 0, length 76
merlin@merlin:~$ fping -S 192.168.1.12 server
server is alive
merlin@merlin:~$ fping -S 192.168.1.13 server
server is alive
-
A nedělá? :)
root@server:/home/merlin# tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:22:36.276458 IP 192.168.1.12 > 192.168.1.1: ICMP echo request, id 22988, seq 0, length 76
13:22:36.276485 IP 192.168.1.1 > 192.168.1.12: ICMP echo reply, id 22988, seq 0, length 76
13:22:37.491256 IP 192.168.1.13 > 192.168.1.1: ICMP echo request, id 22989, seq 0, length 76
13:22:37.491283 IP 192.168.1.1 > 192.168.1.13: ICMP echo reply, id 22989, seq 0, length 76
merlin@merlin:~$ fping -S 192.168.1.12 server
server is alive
merlin@merlin:~$ fping -S 192.168.1.13 server
server is alive
obě adresy jsou na jednom rozhraní?? já bych potřeboval poslat jeden požadavek po wifi a jeden po kabelu :) a to současně:)
-
Ne-e, nejsou na jednom rozhraní, jedna IP patří WiFi, druhá LAN.
merlin@merlin:~$ fping -v
fping: Version 3.2
fping: comments to david@schweikert.ch
-
a co když pustíš tcpdump na merlinu ne na serveru?
tcpdump -n -i eth0 icmp
a pro kontrolu současně
tcpdump -n -i eth2 (wlan0) icmp
Podle mě ty pakety odchází z merlinu na server po eth0 a to je kabel.
to cp je zde mi jde taky
IP WIFI -> kabel -> modem -> server
ale ja bych potřeboval aby to šlo přímo
IP WIFi -> vlnění vzduchem -> anténa modemu -> modem -> server
-
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:59:11.130174 IP 192.168.1.12 > 192.168.1.1: ICMP echo request, id 8588, seq 0, length 76
13:59:11.131359 IP 192.168.1.1 > 192.168.1.12: ICMP echo reply, id 8588, seq 0, length 76
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:59:49.268388 IP 192.168.1.169 > 192.168.1.1: ICMP echo request, id 8599, seq 0, length 76
13:59:49.268673 IP 192.168.1.1 > 192.168.1.169: ICMP echo reply, id 8599, seq 0, length 76
Ovšem jen technická:
Toto je samosebou možné pouze v případě, že se malinko upraví routovací tabulka - tj. definuje se za kterým rozhraním má daný host ležet. Celý problém je totiž v tom, že těžko můžete chtít, aby daná síť byla dostupná současně pod oběma rozhraníma - to je jako připojit kabel ve switchi do dvou portů zaráz. Stačí jeden bcast paket a switch bliká jak vánoční stromeček.
Proč to funguje na Windows nevím a popravdě řečeno snad ani vědět nechci. Teoreticky je možné tohoto docílit i na Linuxu, ale jen v případě implementace network multipath.
Tedy toť vše z mé strany, co jsem k tomu od začátku tohoto threadu chtěl říci. Neříkám, že můj názor je správný, ale z dlouhodobého hlediska a svých zkušeností si za ním stojím.
PS: Pokud opravdu je nutné docílit požadovaného, pak doporučuji napsat script, který bude ve smyčce definovat host za daným rozhraním a pingovat s využitím definice zdrojové adresy (což funguje správně, paket má nastavenou hlavičku zdroje tak, jak je požadováno - viz tcpdump ze serveru)
-
Na tohle jsem narazil Projekt do předmětu Směrované, přepínané sítě (http://wh.cs.vsb.cz/sps/images/9/98/Redundandni_pripojeni_serveru_pomoci_vice_NIC.pdf) Možná vám to pomůže.