PING přes dvě různá rozhraní současně [zatím nevyřešeno]

[matee]

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

Kód: [Vybrat]

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

Kód: [Vybrat]

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

Kód: [Vybrat]

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 = 42msWin. modem

Kód: [Vybrat]

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

Kód: [Vybrat]

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.

[beer]

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)

[matee]

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)

díky, za tip

[Petr Merlin Vaněček]

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:

Kód: [Vybrat]

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.

[matee]

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

[Petr Merlin Vaněček]

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

[matee]

díky, fping a ping ve windows davaj schodnej výsldek aspoň co se ztrát týká...

Kód: [Vybrat]

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á:)

[Petr Merlin Vaněček]

A nedělá?

Kód: [Vybrat]

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


Kód: [Vybrat]

merlin@merlin:~$ fping -S 192.168.1.12 server
server is alive
merlin@merlin:~$ fping -S 192.168.1.13 server
server is alive


[matee]

A nedělá?

Kód: [Vybrat]

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


Kód: [Vybrat]

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ě:)

[Petr Merlin Vaněček]

Ne-e, nejsou na jednom rozhraní, jedna IP patří WiFi, druhá LAN.

Kód: [Vybrat]

merlin@merlin:~$ fping -v
fping: Version 3.2
fping: comments to david@schweikert.ch


[matee]

a co když pustíš tcpdump na merlinu ne na serveru?

Kód: [Vybrat]

tcpdump -n -i eth0 icmpa pro kontrolu současně

Kód: [Vybrat]

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

[Petr Merlin Vaněček]

Kód: [Vybrat]

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)

[Myrmica]

Na tohle jsem narazil Projekt do předmětu Směrované, přepínané sítě Možná vám to pomůže.