1

My network consists of the GL-MT300N-V2 router running this code:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <fcntl.h>
#include <netdb.h>
#include <sys/time.h>
#include <arpa/inet.h>
#include <time.h>
#include <errno.h>

int main(int argc, char *argv[])
{
    int sock;
    if( (sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) == -1)
    {
        perror("socket : ");
        return -1;
    }

    int broadcast = 1;
    if( setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &broadcast, sizeof(broadcast)) != 0 )
    {
        perror("setsockopt BROADCAST: ");
        close(sock);
        return -1;
    }

    char netif[] = "eth0";
    if( setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, netif, sizeof(netif) )
    {
        perror("setsockopt BIND : ");
        close(sock);
        return -1;
    };
    
    
    char *ip = "255.255.255.255";
    char * msg = "OOO";            //Actual code has 250 'O's to be visible in the dump

    struct sockaddr_in si;
    si.sin_family = AF_INET;
    si.sin_port   = htons( 4444 );
    inet_aton( ip, &si.sin_addr.s_addr );

    /* send data */
    for(int i = 0; i < 10000; i ++) //Used to spam for tcpdump
    {
        size_t nBytes = sendto(sock, msg, strlen(msg), 0, 
                        (struct sockaddr*) &si, sizeof(si));
        if(i % 1000 == 0)
        {
            printf("Sent msg: %s, %d bytes with socket %d to %s\n", msg, nBytes, sock, ip);
        }
    }
    return 0;
}

The code successfully continually and rapidly sends packets. Said packets are easily visible in TCPdump. However, when I connect the router to a Windows 10 PC or laptop using ethernet, the computers are unable to detect the packets with Wireshark.

The sheer amount of packets is likely not the problem, as other code I have run sends similar amounts of packets, all of which are received.

Windows firewall has also been disabled, so the packet isn't being dropped there either.

Mason
  • 11
  • 2
  • Broadcast address `255.255.255.255` is not guaranteed to work. You might want to try using real broadcast address for the network you are using. – SergeyA Jul 21 '21 at 21:37
  • @SergeyA Got a citation for that? RFC 1122 says "Hosts SHOULD use the Limited Broadcast address to broadcast to a connected network." – Barmar Jul 21 '21 at 21:46
  • @Barmar i do not have a citation, but I know for a fact (have first hand experience) that if you try to broadcast to 255.255.255.255 from Android phone, it won't work, while the real broadcast address will. I am not saying OP is using Android phone, but I would not be too much of stretch to entertain the idea that using real address can help and try that. – SergeyA Jul 21 '21 at 21:58
  • @SergeyA Indeed: https://stackoverflow.com/questions/44846597/android-broadcast-to-255-255-255-255-not-working – Barmar Jul 21 '21 at 23:17
  • @SergeyA But except for toy example programs where you can hard-code the local broadcast address, scanning all the interfaces to get all the local broadcast addresses is complicated (it might double the size of the above snippet). – Barmar Jul 21 '21 at 23:27
  • bind only filters received packets. send interface is determined by the routing tables https://stackoverflow.com/a/683774/1216776 – stark Jul 22 '21 at 03:08
  • @Barmar I agree that in general more robust programs are longer than less robust. They tend to work better, though - so this is a trade-off :) – SergeyA Jul 22 '21 at 13:12

1 Answers1

0

It could be an interface optimization--drop it in hardware, so to speak (assuming port 0x4444 is not LISTENING--check netstat). For obvious reasons, you do not want to send all bcasts up the stack.

Andrew
  • 1
  • 4
  • 19