5

I am trying to send characters directly to the network stack as explained in this thread.

Even when the process work OK under CygWin (Windows), the same lines do fail on Ubuntu v14.04:

luis@Zarzamoro:~$ sudo echo -e "\xff">/dev/udp/255.255.255.255/4000
-bash: connect: Permission denied
-bash: /dev/udp/255.255.255.255/4000: Permission denied

Tested on Ubuntu for PC:

luis@Lamborghini:~$ bash --version
GNU bash, versión 4.3.11(1)-release (i686-pc-linux-gnu)

And Ubuntu for RaspBerry Pi 2:

luis@Zarzamoro:~$ bash --version
GNU bash, version 4.3.11(1)-release (arm-unknown-linux-gnueabihf)

Doing this via direct character sending to NIC instead of by using netcat or socat could be useful for some routers or embedded devices (like NAS) that have a rather modern Bash version, but don't allow (or it is awkward to achieve) installation of extra tools.

Why is this happening and how could I solve it?

Tested too:

luis@Zarzamoro:~$ sudo bash -c 'echo -e "\xff" >/dev/udp/255.255.255.255/4000'
bash: connect: Permission denied
bash: /dev/udp/255.255.255.255/4000: Permission denied

And:

luis@Zarzamoro:~$ echo -e "\xff" | sudo tee /dev/udp/255.255.255.255/4000
tee: /dev/udp/255.255.255.255/4000: No such file or directory
▒
luis@Zarzamoro:~$

New info from @Emeric: the problem seems to affect only to broadcast address(es):

luis@Zarzamoro:~$ sudo bash -c 'echo -e "\xff" >/dev/udp/192.168.11.255/4000'
bash: connect: Permission denied
bash: /dev/udp/192.168.11.255/4000: Permission denied
luis@Zarzamoro:~$ sudo bash -c 'echo -e "\xff" >/dev/udp/192.168.11.1/4000'
luis@Zarzamoro:~$

Tested failing too on Kali Linux v1.1.0 with Bash v4.2.37:

luis@Lamborghini:~$ sudo lsb_release -a
No LSB modules are available.
Distributor ID: Kali
Description:    Kali GNU/Linux 1.1.0
Release:        1.1.0
Codename:       moto
luis@Lamborghini:~$ bash --version
GNU bash, versión 4.2.37(1)-release (i486-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.

luis@Lamborghini:~$ sudo bash -c 'echo -e "\xff" >/dev/udp/192.168.11.255/4000'
bash: connect: Permiso denegado
bash: /dev/udp/192.168.11.255/4000: Permiso denegado

Tested failing too on Bash from Conceptronic CH3SNAS (a NAS with 2 HDDs) installed via Fun_Plug:

sh-4.1# bash --version
GNU bash, version 4.1.11(2)-release (arm-ffp-linux-uclibc)
sh-4.1# su
sh-4.1# echo -e "\xff" > /dev/udp/255.255.255.255/4000
sh: connect: Permission denied
sh: /dev/udp/255.255.255.255/4000: Permission denied
2
  • Note that this seems to only happen when you try to send data to the broadcast address. If you use a different target address instead, the call will be successful (even without resorting to sudo since a normal user for which a network interface is available can send data to a udp socket). I am still trying to find out what is wrong with the broadcast address, but it might be simply missing from bash's socket implementation.
    – Emeric
    Jul 22, 2015 at 13:20
  • Indeed, @Emeric . Edited original question to reflect. Note the broadcast 192.168.11.255 failing too. Jul 22, 2015 at 13:34

2 Answers 2

10

Edited following OP's clarification on the use case:

You can not do that using the latest official release of bash (currently 4.3.30 according to this page). lib/sh/netopen.c shows that bash opens a UDP socket (SOCK_DGRAM) then directly tries to connect without looking at the ip address to determine whether it would make sense to set specific socket options (in your case SO_BROADCAST).

Your best bet would be to send a patch to current bash maintainers or the appropriate mailing list, have it included in the official releases, then wait until the rather modern bash version in your NAS gets updated to an even more modern version including your feature.

Short answer: bash can currently not do that.

Previous answer:
You have to resort to socat:

$ echo -e "\xff" | socat - UDP-DATAGRAM:255.255.255.255:4000,broadcast

Writing to /dev/udp uses bash's built-in socket implementation. To the best of my knowledge, this implementation does not allow to send UDP datagrams to the broadcast address, as this requires setting an SO_BROADCAST flag to the socket before sending.

Using netcat is also not an option, as it rejects the UDP broadcast:

$ echo -e "\xff" | nc -u 255.255.255.255 4000
nc: netcat.c:573: main: Assertion `connect_sock.proto != NETCAT_PROTO_UDP' failed.
Aborted (core dumped)

Edit:

Sometimes netcat has -b flag to enable broadcast address. See this answer about UDP broadcasting on Ubuntu.

5
  • Indeed, netcat (tested for me working on CygWin) and socat should be capable of doing this, as can be read on the origin thread referred to at the beginning of the original question. But this question deals rather with solving the problem by directly echo data to NIC, as stated in the title. Edited original post to reflect. Thanks you anyway. Jul 22, 2015 at 13:56
  • Thanks for your clarification. I edited my answer accordingly, but it really does not look good for you.
    – Emeric
    Jul 22, 2015 at 14:24
  • You seem to be right. It seems this feature has been disabled on Bash due to networking compatibility problems. We will have to use netcat and socat instead... when possible. Jul 22, 2015 at 15:16
  • Why does NetCat rejects UDP broadcast? This makes no sense for me. Jul 22, 2015 at 16:34
  • Another detail: On Ubuntu and Kali NetCat yields no error, but it doesn't sends the data. Tested on PC and RaspBerry versions. Jul 22, 2015 at 16:46
0

Open two terminals and type on both of them:

nc -u -l 55555

Open a third terminal, install socat if necessary and type: (in case you ask netcat does NOT support broadcast)

echo -n "TEST" | socat - udp-datagram:127.255.255.255:55555,broadcast

You should see both terminals receiving the message.

If you try the same experiment with 127.0.0.1, only one terminal will get the message as expected.

2
  • "Why does NetCat rejects UDP broadcast? This makes no sense for me."
    – user161440
    Dec 20, 2015 at 23:30
  • Because telnet is incapable of listening to inbound connections which require line feed and carriage return
    – user161440
    Dec 20, 2015 at 23:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .