Lines Matching full:some
32 some systems may have trouble sending large amounts of data that way, but it's
36 Valid question, and here are some reasons. Telnet has the "standard input
41 are thus removed from the data stream. Telnet also emits some of its
49 Some of netcat's major features are:
66 If netcat is not able to do some task you think up, minor tweaks to the code
104 Some systems may warn about pointer types for signal(). No problem, though.
125 which this can *save* time, such as when you want to know the name for some IP
146 some error happens, whereupon it describes the error and exits with a nonzero
231 syntax. CAVEAT: some port names in /etc/services contain hyphens -- netcat
245 some pitfalls with regard to UDP scanning, described later, but in general it
282 sockets and/or nit/bpf/dlpi may appear at some point. Such things are clearly
305 binary image files and display them elsewhere later. Some folks may find the
323 using the timeout will almost guarantee that you see some kind of greeting or
326 collect host information, and indeed some of the ideas herein were taken from
347 tar cfp - /some/dir | compress -c | nc -w 3 othermachine 1234
371 to the network the same way, perhaps sans some fancier signal handling. Given
378 experimental simulation of some service, without having to screw around with
469 back to yourself via some gateway outside your network will create "incoming"
533 target's network. Some examples for crafting various standard UDP probes are
536 Some configurations of packet filters attempt to solve the FTP-data problem by
539 able to bypass filtering in some cases. Maybe not to low ports "inside", but
551 You might be able to collect some interesting things from port 2049, including
554 some platforms [yppasswdd, anyone?]. Kerberos tickets, X cookies, and IRC
559 There are some daemons that are well-written enough to bind separately to all
566 that appear later on such as dynamic PPP links. There are some hacked web
613 they otherwise would from a more recent telnet program. Some telnetds actually
622 The interface probably has to be UP before this works; some SLIP versions
638 machine before you start receiving packets back. Warning: some machines still
644 is completed. If you send some data and observe the "send-q" side of "netstat"
653 than the default and the half-open timeout smaller can help, and indeed some
672 and then some data to transfer. Netcat is now smart enough to pick out the
697 You should be aware of some subtleties concerning UDP scanning. If -z is on,
712 "open" -- clearly wrong. [Some systems may not even *have* the "udp connected
742 telnetd happy worked some places but failed against newer BSD-flavor ones,
750 full-blown telnet to get to something but also want some of netcat's features
765 I've observed inconsistent behavior under some Linuxes [perhaps just older
773 packets to some other machine doesn't work as you'd expect -- they go out with
785 call" since the connect attempt was interrupted. Some old 4.3 BSD kernels
809 some really bizarre return paths, and send your traffic fairly directly to the
810 target but around some larger loop on the way back. Some Sun kernels seem to
819 features. After reading some other network code and realizing just how many
821 on the basics and the rest fell together pretty quickly. Some port-scanning
827 sort of a "netcat" with more obscure features], with some more paranoid
848 difficult with some of the tangles of spaghetti code that are out there.
849 Here are some of the major points I feel are worth mentioning about netcat's
901 some OSes that don't do timed select() right, but this remains to be seen.
