Dotaz: wget nepřenese celý parametr

[Milan Uhrák]

Zdravím, Mám podivný problém s wget. Z asi 50 PC ( stejný OS - Opensuse 11) si stahuju (nechávám posílat) data o "zdraví" disků.

Z nich je asi 8 PC, ze kterých se data 24.3 přestala načítat. Zkoumáním jsem zjistil, že

data=`/usr/sbin/smartctl -a $1 | base64 -w0`
echo $data
wget -qO - --post-data "pc=$2&pcm=$3&pcs=$4&data=$data" http://nasserver.cz/disky.php

wget ( asi ) ořízne na těchto PC argument $data na 1024 znaků. Zkoušel jsem googlit, co to může způsobovat, ale nic kloudného jsem nezjistil.

Echo vypíše celou salvu dat ( 5-6 kB ) ale následně v PHP skriptu hned na začátku print_r( $_REQUEST, 1 ) ukáže jen 1024 znaků z $data. Podezírám wget, ale nevím co s tím.

Uříznuto je to co je za polmčkami ( nevím, jak to líp zvýraznit ) :

.....U9OID09PQpTTUFS----VCBvdmVyYWxsLWhlYWx0a

V tom 1024B řetězci je jedna mezera někde +- uprostřed, v místě uříznutí ne. Jinak mně nic nenapadá.

Předem děkuji za nasměrování.

Milan

---

---

Odpovědi

[Milan Uhrák]

Co na to wireshark/tcpdump, aby se vyloucil problem na siti a zjistilo se na ktere strane je problem?

[Milan Uhrák]

Od vás vždy dobré rady ... bez ironie. V tomto případě nevím, protože ty kouzelné věci neovládám. zkusím tcpdump na odesílacím PC ?

[Milan Uhrák]

hm .. tak jsem to zkusil ( ani to nebylo složité .. ) a vypadá to, že wget je v tom nevinně .. <>

listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
09:50:04.498568 IP filialkajpo172.38312 > nasserver.cz.http: S 735164019:735164019(0) win 5840 <mss 1460,sackOK,timestamp 6954384 0,nop,wscale 6>
09:50:04.632886 IP filialkajpo172.38312 > nasserver.cz.http: . ack 3553872297 win 92 <nop,nop,timestamp 6954417 2249017047>
09:50:04.633047 IP filialkajpo172.38312 > nasserver.cz.http: P 0:190(190) ack 1 win 92 <nop,nop,timestamp 6954417 2249017047>
09:50:04.633162 IP filialkajpo172.38312 > nasserver.cz.http: . 190:3070(2880) ack 1 win 92 <nop,nop,timestamp 6954418 2249017047>
09:50:04.829839 IP filialkajpo172.38312 > nasserver.cz.http: . 3070:5950(2880) ack 1 win 92 <nop,nop,timestamp 6954467 2249017245>
09:50:04.889016 IP filialkajpo172.38312 > nasserver.cz.http: . 5950:7390(1440) ack 1 win 92 <nop,nop,timestamp 6954481 2249017305>
09:50:04.889024 IP filialkajpo172.38312 > nasserver.cz.http: P 7390:7622(232) ack 1 win 92 <nop,nop,timestamp 6954481 2249017305>
09:50:05.144622 IP filialkajpo172.38312 > nasserver.cz.http: . ack 1441 win 137 <nop,nop,timestamp 6954545 2249017556>
09:50:05.145479 IP filialkajpo172.38312 > nasserver.cz.http: . ack 1634 win 182 <nop,nop,timestamp 6954546 2249017556>
09:50:05.145844 IP filialkajpo172.38312 > nasserver.cz.http: F 7622:7622(0) ack 1634 win 182 <nop,nop,timestamp 6954546 2249017556>
09:50:05.231676 IP filialkajpo172.38312 > nasserver.cz.http: . ack 1635 win 182 <nop,nop,timestamp 6954567 2249017647>
09:50:07.238133 IP filialkajpo172.38316 > nasserver.cz.http: S 779152149:779152149(0) win 5840 <mss 1460,sackOK,timestamp 6955069 0,nop,wscale 6>
09:50:07.398023 IP filialkajpo172.38316 > nasserver.cz.http: . ack 1093656530 win 92 <nop,nop,timestamp 6955109 2249019813>
09:50:07.398183 IP filialkajpo172.38316 > nasserver.cz.http: P 0:190(190) ack 1 win 92 <nop,nop,timestamp 6955109 2249019813>
09:50:07.398298 IP filialkajpo172.38316 > nasserver.cz.http: . 190:3070(2880) ack 1 win 92 <nop,nop,timestamp 6955109 2249019813>
09:50:07.559120 IP filialkajpo172.38316 > nasserver.cz.http: . 3070:5950(2880) ack 1 win 92 <nop,nop,timestamp 6955149 2249019975>
09:50:07.620969 IP filialkajpo172.38316 > nasserver.cz.http: . 5950:7390(1440) ack 1 win 92 <nop,nop,timestamp 6955164 2249020036>
09:50:07.620976 IP filialkajpo172.38316 > nasserver.cz.http: P 7390:7622(232) ack 1 win 92 <nop,nop,timestamp 6955164 2249020036>
09:50:07.874718 IP filialkajpo172.38316 > nasserver.cz.http: . ack 1441 win 137 <nop,nop,timestamp 6955228 2249020287>
09:50:07.875273 IP filialkajpo172.38316 > nasserver.cz.http: . ack 1634 win 182 <nop,nop,timestamp 6955228 2249020287>
09:50:07.875681 IP filialkajpo172.38316 > nasserver.cz.http: F 7622:7622(0) ack 1634 win 182 <nop,nop,timestamp 6955228 2249020287>
09:50:07.966890 IP filialkajpo172.38316 > nasserver.cz.http: . ack 1635 win 182 <nop,nop,timestamp 6955251 2249020383>

Jestli tomu dobře rozumím, tak (jsou tam 2 disky) wget posílá 2x 7622 bajtů .. ten zásek na 1024 je ale magický, a vztahuje se jen na tu poslední proměnnou ( $data ) ..

Děkuji za nakopnutí, ale .. nebyl by další nápad ?

[lertimir]

Je super, že jste to zvládl. Paketový analyzáor je ten první nástroj, který je na pořadu dne, když je komunikační problém s nejasnou diagnostikou. Prostě se zjistí co jednotlivé strany posílají a jestli to odpovídá protokolu, očekávání a požadavkům.

[Milan Uhrák]

A ještě legrace : u tohoto konkretního PC, které teď zkoumám, je ve stejné budově další PC, a z toho data projdou komplet. To je mešuge.

[Milan Uhrák]

na cílovém stroji který data přijímá mi

tcpdump -nn src 90.179.130.8 and dst port 80

ani nepípne ..

dělám něco špatně ? Moc tomu tcpdumpu nerozumím, to co dělám, je narychlo vygůgleno.

[lertimir]

na cílovém stroji nemůže být dst port 80 (vyhodte u portu i adres src a dst protože tím se dostane jen jedne směr komunikace) přijímaný paket webu je na klientovi src port 80 ale odesílaný http dotaz je dst port 80. a vy jste oba zkombinoval tak že je to nula.

[Milan Uhrák]

ok, takže tcpdump -i eth1 dst nasserver.cz and dst port 80 ukazuje, že data přijdou ( 7622 ) ...

hm, takže co teď ?

než jsem to stihl dopsat, objevil jsem patrně příčinu tohoto problému : https://stackoverflow.com/questions/5077969/php-some-post-values-missing-but-are-present-in-php-input

mne navedlo k

var_dump($file = file_get_contents('php://input'));

které vypsalo celý balík dat tak, jak jsou odeslána. Problém je asi v té mezeře, která nějak blokuje správnou transformaci na straně PHP interpreteru. V odkazu je také náčrt řešení, to ještě musím prověřit ...

NN díky, máš zase řešení u mně

[Kit]

Mezera by měla být při přenosu nahrazena znakem "+". Prostě urlencode().

[Milan Uhrák]

Jak už vyplynulo z tohoto "řešení", hlavní problém je v tom, že base64 zakódovaný výstup smartctl jako součást odesílané URL wget-em není předem url-enkódován. PHP při načítání proměnných url-dekóduje a tím se to rozeseje.

[Milan Uhrák]

tak na odkazu uvedená funkce

function getRealPOST() {
    $pairs = explode("&", file_get_contents("php://input"));
    $vars = array();
    foreach ($pairs as $pair) {
        $nv = explode("=", $pair);
        $name = urldecode($nv[0]);
        $value = urldecode($nv[1]);
        $vars[$name] = $value;
    }
    return $vars;
}

se v podstatě chová stejně špatně jako PHP. Musel jsem ji trochu upravit ( používá wget urlencode ? ) a už je to v pořádku :

		$pairs = explode("&", file_get_contents("php://input"));
		$vars = array();
		foreach ($pairs as $pair) {
			$nv =		strpos( $pair, "=" );
			$name =	urldecode( substr( $pair, 0, $nv ) );
			$value =	( substr( $pair, $nv+1 ) );
			$vars[$name] = $value;
		}
		return $vars;

Není tam nějaká bota, která mně unikla ?

Jinak díky všem za reakce, nakopnutí, pootočení atd ...

Milan

[chrono]

V návode k wget sa píše, že by mali byť tie parametre zakódované pomocou urlencode, ale že samotný wget nič také nerobí a ani nekontroluje (a má sa o to postarať používateľ).

[Milan Uhrák]

Dobré vědět :)

Jde to v bashi ?

....

Tak jsem koukal, a na jednoduché stringy by možná stačilo totok.

No uvidím, když jsem skript psal, vše fungovalo, zdálo se mi to dobře napsané, ale jak vidím, radost byla předčasná..

Tak uvidím, jak se to bude chovat takto, a jsem připraven zase do toho říznout ..

Díky

M.

[Kit]

Umí to curl.

[chrono]

base64 nepoužíva znak pomlčky, takže problém pravdepodobne nebude v $data ale niekde inde. Môže ale použiť znak = a ten by mohol spôsobovať problém (stačí ale použiť url percent encoding a nahradiť ho reťazcom %3D).

[Milan Uhrák]

pomlčky jsem tam dal já jako šidítko pro očí "tady se to rozseklo". Z 42 + 10 jiných kompů to funguje jen u těchto osmi ne ... to je to nejzajímavější

[chrono]

A keď sa odošle len "data=$data" dáta prídu kompletné, alebo nie? (a teda, naozaj je problém v $data?) Prípadne obsahuje $data na konci znak = a ak áno, (ne)obsahujú znak = aj tie počítače, kde to funguje?

[Jendа]

Osobně bych ta data dal do souboru a udělal --post-file, k dlouhatánským parametrům nemám moc důvěru.

[chrono]

--post-file funguje úplne rovnako, ako --post-data. Jediný rozdiel je v tom, že sa údaje načítajú zo súboru a nie priamo z parametrov programu.

[Jendа]

Ano, přesně tak.