3

Even when this is a network problem, I would say this is rather a Unix/Linux experienced users question.

I am trying to manually send a network magic packet by using echo and redirectors (file descriptors).
This is an example of the data that must be sent via network broadcast (to 255.255.255.255) to wake computer with MAC 00:17:31:3F:D3:A9 (FFFFFFFFFFFF followed by 16 times the MAC without colons):

ffffffffffff0017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a9

I have sent a wake on LAN magic packet from my usual programs (IH WOL, or wakeonlan tool for Linux) that worked fine, and I captured the network traffic with WireShark:

Magic Packet working

Note the highlighted green area: the magic packet is correctly sent as Hex.

And now it is time for the redirectors echo method.
I am echoing the magic packet to broadcast IP address, UDP protocol, port number 4000:

exec 6<>/dev/udp/255.255.255.255/4000
echo "ffffffffffff0017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a90017313fd3a9" >&6

No results (remote computer does not wake up). The WireShark's capture is this time slightly different:

Magic Packet not working

As can be seen, the magic packet is now on the right side (!), the supposed binary area of the info. On the left area, each F appears as 66 (its ASCII code, I assume), each 0 as 30... etc.
And, by the way, the data is not detected as "MagicPacket" by WireShark.

What is the correct way to send my data via shell directly to the NIC?

P.S: maybe this question must be transferred to ServerFault? I think it is rather like some sort of hex to ascii or binary conversion issue.

4

Really easy:

  • Add the hex specification "\x" each two characters.
  • Use echo -e for hex to be interpreted. Also you can use printf because echo does different things in different shells.

Using your same example data:

echo -e "\xff\xff\xff\xff\xff\xff\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9\x00\x17\x31\x3f\xd3\xa9" >&6

This time your computer should wake up.

  • NOTE: not all the shells do support this feature. In fact, only a few do. Refer to this thread to know which one do. For me, Cygwin latest version (June 2015) for Windows running Bash 4.3.39(2)-release (i686-pc-cygwin) works perfect.
  • NOTE-2: Sadly, Ubuntu (v14.04) and Kali (v1.1.0) seem not to support it as for today, as explained in this thread. It has probably been disabled on Bash, due to problems with networking compatibility.
  • NOTE-3: Well, I must admit that people (see above threads) reporting that /dev/protocol/host/port is not a proper method are completely right. For example, the Hex code \x0a acts as some control code for network datagrams, splitting the packet. So you can not use MAC address like 0a:11:22:33:44:55 with this method. Time to switch to netcat or socat.
  • Does this work? Impressive. I would suggest using printf rather than echo because echo does different things in different shells - its behavior differs even between ksh and bash which are the two which I would suppose this might work in. printf is fairly reliable, however. Anyway, could please elaborate on opening >&6 in the first place? Where does it go? My bad - /dev/udp/.... Good q/a. Thank you. – mikeserv Jul 22 '15 at 1:53
  • Indeed, this work, @mikeserv. The bad news: recent Bash versions seem to have disabled it (I still can use it via CygWin's Bash). The good news: it can be easily replaced by netcat or socat. I have opened this thread that expands info about this: unix.stackexchange.com/questions/217469/… . I think all your questions will be answered there, even the >&6 (in the case of just sending data there is no need to use it, in fact; it is just por readability purposes). – Sopalajo de Arrierez Jul 22 '15 at 15:06
  • 1
    @mikeserv , tested your printf. It works OK, thanks you. – Sopalajo de Arrierez Jul 22 '15 at 15:09
  • And more bad news, @mikeserv : even when Bash would accept them, file redirectors are not a valid solution (see NOTE-3). – Sopalajo de Arrierez Jul 22 '15 at 21:07
  • Your last note isn't true. And anyway, I would never do such a thing with bash - bash is the worst shell there is. – mikeserv Jul 22 '15 at 21:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.