From nobody Sun Apr 28 19:33:45 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VSGrt32rsz5JqLp for ; Sun, 28 Apr 2024 19:35:26 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "weser.webweaving.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VSGrs1htvz3xsd for ; Sun, 28 Apr 2024 19:35:25 +0000 (UTC) (envelope-from dirkx@webweaving.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=webweaving.org header.s=shared header.b=aV46udmv; dmarc=pass (policy=none) header.from=webweaving.org; spf=pass (mx1.freebsd.org: domain of dirkx@webweaving.org designates 148.251.234.232 as permitted sender) smtp.mailfrom=dirkx@webweaving.org Received: from smtpclient.apple (fiber.static.cbizz.nl [185.142.248.117] (may be forged)) (authenticated bits=0) by weser.webweaving.org (8.17.1/8.17.1) with ESMTPA id 43SJXw4J094640 for ; Sun, 28 Apr 2024 21:34:00 +0200 (CEST) (envelope-from dirkx@webweaving.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=webweaving.org; s=shared; t=1714332841; bh=5Ty3LbfUQu1YQL94eEMdJF9seL8sXOHCyp4VJkil5C4=; h=From:Subject:Date:To; b=aV46udmvsoe80y7knt8wIzpHuNA8l2n0E4R1V8V1gOJqF3XlcOmvlM15lBP5wWqE1 RLkrkLGve0+C1Rtmu/uu6FXzZhKOGDg/1rbV05TUAEe8eqWmHa99pVP/FSzNQEA3wq 7z6rXmRo87b9i9XAdHpXg1pRUobrXY7tFFA9np90= X-Authentication-Warning: weser.webweaving.org: Host fiber.static.cbizz.nl [185.142.248.117] (may be forged) claimed to be smtpclient.apple From: Dirk-Willem van Gulik Content-Type: multipart/alternative; boundary="Apple-Mail=_2C77F2BB-87C7-4F5B-A2B8-5CD33CED02FF" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Multicast & Tunnel devices Message-Id: Date: Sun, 28 Apr 2024 21:33:45 +0200 To: FreeBSD Hackers X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (weser.webweaving.org [148.251.234.232]); Sun, 28 Apr 2024 21:34:01 +0200 (CEST) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[webweaving.org,none]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[webweaving.org:s=shared]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ONCE_RECEIVED(0.10)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:148.251.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[webweaving.org:+] X-Rspamd-Queue-Id: 4VSGrs1htvz3xsd --Apple-Mail=_2C77F2BB-87C7-4F5B-A2B8-5CD33CED02FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Would anyone know if there is something special with tunnel devices and = multicast ?=20 I=E2=80=99ve got some code that happily processes multicast packets on a = normal interface; but appears not to do this on a tunnel interface. Tun0 = shows multicast enabled: =09 tun0: flags=3D8043 metric 0 mtu = 1500 Tcpdump on that interface gives the expected thing (here with mDNS): tcpdump -n -i tun0 port 5353 listening on tun0, link-type NULL (BSD loopback), capture size = 262144 bytes 19:26:03.976259 IP 10.31.0.6.5353 > 224.0.0.251.5353: 0 PTR = (QM)? _raop._tcp.local. (34) And code, with a simple IP_ADD_MEMBERSHIP of the MC group on the IP of = the local interface below works on a normal interface (e.g. = igb0/10.0.0.1/24).=20 ./listener 10.0.0.1 224.0.0.251 5353 Received packet, len=3D128 etc But yields no output if ran against above tun0 interface (while tcpdump = on same is fine). Does that ring a bell with anyone ? Dw int main(int argc, char *argv[]) { struct sockaddr_in addr; struct ip_mreq mreq; // skip error trapping command line arguments char* ip =3D argv[1];=20 char* group =3D argv[2];=20 int port =3D atoi(argv[3]); // 0 if error, which is an invalid port memset(&addr, 0, sizeof(addr)); addr.sin_family =3D AF_INET; addr.sin_addr.s_addr =3D htonl(INADDR_ANY); addr.sin_port =3D htons(port); mreq.imr_interface.s_addr =3D inet_addr(ip);=20 mreq.imr_multiaddr.s_addr =3D inet_addr(group); // skip error trapping on inet_addr int fd =3D socket(AF_INET, SOCK_DGRAM, 0); // skip error trapping socket if (bind(fd, (struct sockaddr*) &addr, sizeof(addr)) < 0) { // skip error trapping if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char*) &mreq, = sizeof(mreq)) < 0 ){ // skip error trapping argumetns while (1) { .. int nbytes =3D recvfrom(fd,msgbuf,MSGBUFSIZE,0,(struct sockaddr = *) &addr,&addrlen); if (nbytes < 0) { perror("recvfrom"); return 1; } printf(=E2=80=9CReceived packet, len=3D%d\n", nbytes); } --Apple-Mail=_2C77F2BB-87C7-4F5B-A2B8-5CD33CED02FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Would anyone = know if there is something special with tunnel devices and multicast = ? 

I=E2=80=99ve got some code that happily = processes multicast packets on a normal interface; but appears not to do = this on a tunnel interface. Tun0 shows multicast enabled:
=
tun0: = flags=3D8043<UP,BROADCAST,RUNNING,MULTICAST> metric 0 mtu = 1500

Tcpdump on that interface gives the expected = thing (here with mDNS):

tcpdump -n -i tun0 port = 5353

listening on tun0, link-type NULL = (BSD loopback), capture size 262144 bytes

19:26:03.976259 IP 10.31.0.6.5353 = > 224.0.0.251.5353: 0 PTR (QM)? _raop._tcp.local. (34)


And code, with a = simple IP_ADD_MEMBERSHIP  of the MC group on the IP of = the local interface below works on a normal interface (e.g. = igb0/10.0.0.1/24). 


./listener 10.0.0.1 = 224.0.0.251 5353

Received = packet, len=3D128

etc


But yields no = output if ran against above tun0 interface (while tcpdump on same is = fine). Does that ring a bell with anyone ?


Dw



int main(int argc, = char *argv[])

{

    struct sockaddr_in = addr;

    struct ip_mreq = mreq;


// skip error trapping command = line arguments


    char* ip =3D = argv[1]; 

    char* group =3D = argv[2]; 

    int port =3D atoi(argv[3]); // 0 if = error, which is an invalid port


    memset(&addr, 0, = sizeof(addr));

    addr.sin_family =3D = AF_INET;

    addr.sin_addr.s_addr =3D = htonl(INADDR_ANY);

    addr.sin_port =3D = htons(port);


    mreq.imr_interface.s_addr =3D = inet_addr(ip); 

  =   mreq.imr_multiaddr.s_addr =3D inet_addr(group);


// skip = error trapping on inet_addr


  =   int fd =3D socket(AF_INET, SOCK_DGRAM, 0);

// skip error trapping = socket


    if (bind(fd, (struct sockaddr*) = &addr, sizeof(addr)) < 0) {

// skip error = trapping


    if (setsockopt(fd, IPPROTO_IP, = IP_ADD_MEMBERSHIP, (char*) &mreq, sizeof(mreq)) < 0 ){

// skip error trapping = argumetns


    while (1) {

..

        int nbytes = =3D recvfrom(fd,msgbuf,MSGBUFSIZE,0,(struct sockaddr *) = &addr,&addrlen);

        if (nbytes < 0) = {

            = perror("recvfrom");

            return = 1;

        }

printf(=E2=80=9CReceived packet, = len=3D%d\n", nbytes);

     }


= --Apple-Mail=_2C77F2BB-87C7-4F5B-A2B8-5CD33CED02FF--