Existuje tedy několik věcí nazývaných netcat; ubuntu má dokonce /etc/alternatives symbolic-link-hackery.
Myslím, že součástí vašeho problému je, že UDP neprovádí relace; Zkopíroval jsem část souboru /usr/share/doc/netcat-tradiční/README.gz níže, který docela dobře vysvětluje.
Pokud je zadáno -u, místo TCP se otevírají připojení UDP. Ve skutečnosti se nejedná o „připojení“ za seci, protože UDP je protokol bez připojení, i když netcat interně používá mechanismus „připojený UDPsocket“, který většina jader podporuje. I když netcat tvrdí, že odchozí UDP spojení je "otevřené" okamžitě, žádná data se neodesílají, dokud se něco nepřečte ze standardního vstupu. Teprve poté je možné určit, zda je na druhém konci skutečně aUDP server, a často to prostě nepoznáte. Většina UDPprotokolů používá ke své věci časové limity a opakování a v mnoha případech vůbec neobtěžuje odpovídat, takže byste měli zadat časový limit a doufat v to nejlepší. Z připojení UDP získáte více, pokud je standardní vstup přiváděn ze zdroje dat, který vypadá jako různé druhy požadavků serveru.
OK, takže to možná není tak skvělé vysvětlení, ale právě to jsem našel.
Pokud jste to ještě neudělali, možná budete chtít experimentovat s jakýmikoli možnostmi netcatu, které najdete a které by měly co do činění s čekáním... experimentovali jste s:
-
pomocí -l a také -u, abyste se ujistili, že jste v režimu "naslouchání"
-
-vv, abyste přesně viděli, co se děje
-
-q -1 ...který by měl "čekat navždy" i po přijetí EOF (doufejme, že posloucháte znovu?)
Můžete použít socat pro to. Má velmi pěknou volbu fork :
forkPo navázání připojení zpracovává svůj kanál v podřízeném procesu a udržuje nadřazený proces ve snaze vytvořit další připojení, buď nasloucháním, nebo připojením ve smyčce (příklad).
Klient (ano, toto spouštíte z klienta):
$ ssh -L 7753:localhost:7753 YourServer.com "/usr/bin/socat tcp4-listen:7753,reuseaddr,fork UDP:8.8.8.8:53"
Klient:
$ sudo socat udp4-listen:53,reuseaddr,fork tcp:localhost:7753
$ dig @127.0.0.1 google.com