Is it possible to echo characters directly to network

OS X can do this now, as of Snow Leopard. It's made possible through the Sleep Proxy Service. It's pretty much automatic. The only requirement is that you have a second always-on Apple device on your LAN that can act as the sleep proxy. Their current low-power embedded boxes all support this, I believe: Airport, Time Machine, and Apple TV.

In the general case, though, I believe the answer is no. I'm not aware of any other OS that has implemented a service like this. The technology is open source, so there's no reason this couldn't be everywhere eventually. It's probably too new to see widespread adoption just yet.

You might now be asking, why do you need a second Apple box on the LAN?

When a PC is asleep, the kernel — and therefore the network stack — is not running, so there is no code in your OS that can respond to a "magic" packet of the sort you're wishing for.

Wake-on-LAN magic packets aren't handled by the OS. They're recognized by the network interface IC, which responds by sending a signal to the CPU that releases it from the sleep state. It can do this because the IC remains powered up in some sleep states. (This is why the Ethernet link light stays on while a PC is "off" on some machines.)

The reason the Apple technology works is that just before the PC goes to sleep, it notifies the sleep proxy. The sleep proxy then arranges to temporarily accept traffic for the sleeping machine, and if it gets something interesting, it sends a WOL packet to the PC and hands off the traffic it received.

This is a feature of ATT ksh93 that was added in bash 2.04. None of the other common shells have it, in particular you won't find it in any of the dash variants, in pdksh or mksh (as of July 2015), in any of the BusyBox or Android variants, or in zsh¹ or fish. Bash can be compiled without this feature (see --enable-net-redirections), so it may be absent from embedded devices, even if they have bash.

To test whether the feature is present, you can check the error message when trying to open a TCP port for the discard service: both bash and ksh say “Connection refused” (or the command returns immediately if you have a discard service on your local machine), which you wouldn't see if this doesn't attempt to make some network connection.

: </dev/tcp/127.0.0.1/9

One reason this isn't a common feature is that a lot of network protocols require two-way communication with careful handling of who talks when, which shells aren't very convenient for. Another reason is that for the simple cases, pipes involving netcat, socat or socket also work. These programs handle binary data and can be servers as well as clients. Most protocols that can be handled in a simple way have specialized tools, wake-on-LAN excepted.

echo -e "GET / HTTP/1.1\n\n" | nc www.google.com 80

echo -e "GET / HTTP/1.1\n\n" | socat - TCP:www.google.com:80

(socket doesn't really work as a HTTP client since it doesn't close its write of the connection on the end of input.)

For scripting:

case $(export LANGUAGE=C LC_ALL=C; { : </dev/tcp/127.0.0.1/9; } 2>&1) in
  ""|*"Connection refused"*) echo "/dev/tcp is present";;
  *)
    if type nc >/dev/null 2>/dev/null; then
      echo "netcat is present"
    elif type socat >/dev/null 2>/dev/null; then
      echo "socat is present"
    else
      echo "I can't do TCP"
    fi
esac

¹ _{Zsh has a different way of using UDP and TCP sockets.}