From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=webweaving.org (client-ip=148.251.234.232; helo=weser.webweaving.org; envelope-from=dirkx@webweaving.org; receiver=) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=webweaving.org header.i=@webweaving.org header.a=rsa-sha256 header.s=shared header.b=GO147IrN Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) by mail.toke.dk (Postfix) with ESMTPS id 18A48A5530F for ; Thu, 15 Feb 2024 16:06:00 +0100 (CET) Received: from smtpclient.apple (83-85-39-103.cable.dynamic.v4.ziggo.nl [83.85.39.103]) (authenticated bits=0) by weser.webweaving.org (8.17.1/8.17.1) with ESMTPSA id 41FF26ZN072374 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Feb 2024 16:02:09 +0100 (CET) (envelope-from dirkx@webweaving.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=webweaving.org; s=shared; t=1708009330; bh=se25xC22XG6g3r+jeZKfOPJxL3Ri8LVxSqTa81mfJUQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GO147IrNSfPiil4XT7yYXT2oEgfVR8JEreQOvM1SB3PVFqnMP9km4JAZVEUpfEeRI GOZNlFELbprUflpGOYBWaofyL0Aa/IXBpeV29wlYcVaUXRikUhB3cgwqrdUYcdoN3a CVpxAFsLX3emuHH7ytH1IziDFDg4GrzkFzI+Maeg= X-Authentication-Warning: weser.webweaving.org: Host 83-85-39-103.cable.dynamic.v4.ziggo.nl [83.85.39.103] claimed to be smtpclient.apple Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) From: Dirk-Willem van Gulik In-Reply-To: <87h6iehcng.wl-jch@irif.fr> Date: Thu, 15 Feb 2024 16:02:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87o7cmhole.wl-jch@irif.fr> <87h6iehcng.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (weser.webweaving.org [148.251.234.232]); Thu, 15 Feb 2024 16:02:10 +0100 (CET) Message-ID-Hash: 3EGERSBPHDJXW7HIFG33LE5G3XULDSFS X-Message-ID-Hash: 3EGERSBPHDJXW7HIFG33LE5G3XULDSFS X-MailFrom: dirkx@webweaving.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: galene@lists.galene.org X-Mailman-Version: 3.3.9 Precedence: list Subject: [Galene] Re: udp-port range and subsequent "turn" use of ports outside that range List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 11 Feb 2024, at 23:14, Juliusz Chroboczek wrote: >> Correct - but the issue that surprised me was the error: >>=20 >>=20 >> turn ERROR: 2024/02/11 14:26:36 Failed to handle datagram:=20 >> unable to handle ChannelData from 127.0.1.12:32895:=20 >> failed writing to socket: write udp4 = 127.0.1.12:24074->DESTINATION_IP:54924:=20 >> sendto: permission denied The situation is slightly more odd. With galene ran as: /usr/local/bin/galene -static /usr/local/share/galene \ .... \ -turn OUTSIDEIP:SRCPORT \ -udp-range 18100-19100 I would expect to only see UDP traffic going out that originates from = OUTSIDEIP. However a machine that has two addresses, OUTSIDEIP and = OUTSIDEIP_2 one sees below traffic wise (galene is working fine). With OUTSIDEIP and OUTSIDEIP_2 normal public IPv4 addresses on an = internet server (at OVH) and 10.11.0.240 the internal address of one of = the clients behind NAT at some consumer ADSL. 1) I had not expected to see OUTSIDEIP_2 in this list at all. 2) I had not expected source UDP ports such as 11247 in below list. With the attempts to reach 10.11.0.240 a case where perhaps some RFC1918 = optimisation can be applied. Dw. $ sudo dwatch -p `cat /var/run/galene.pid` -X udp-send=20 INFO Sourcing udp-send profile [found in /usr/libexec/dwatch] INFO Watching 'udp:::send' ... INFO Filtering pid: 2109 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:SRCPORT -> = CLIENTIP:58806 48 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:SRCPORT -> = CLIENTIP:7450 48 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:18824 -> = OUTSIDEIP:SRCPORT 28 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:18558 -> = OUTSIDEIP:SRCPORT 28 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:18757 -> = 10.11.0.240:58291 108 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:11247 -> = OUTSIDEIP:SRCPORT 44 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:SRCPORT -> = OUTSIDEIP:18824 48 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:18757 -> = 10.11.0.240:58289 108 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:SRCPORT -> = OUTSIDEIP:18558 48 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:18757 -> = 10.11.0.240:58291 108 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:SRCPORT -> = OUTSIDEIP:11247 88 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:18757 -> = 10.11.0.240:58289 108 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:11247 -> = OUTSIDEIP:SRCPORT 132 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:18853 -> = 10.11.0.240:58291 108 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:SRCPORT -> = OUTSIDEIP:11247 84 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:18853 -> = 10.11.0.240:58289 108 bytes -> why OUTSIDEIP_2 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:SRCPORT = -> CLIENTIP:58806 48 bytes 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:SRCPORT = -> CLIENTIP:7450 48 bytes -> we could probably apply RFC1918 optimisation 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP_2:18757 -> = 10.11.0.240:58291 108 bytes -> why a PORT outside the 18100-19100 range ? 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:11247 -> = OUTSIDEIP:SRCPORT 44 bytes -> testing myself. Fair enough 2024 Feb 15 14:47:09 328.328 galene[2109]: OUTSIDEIP:SRCPORT -> = OUTSIDEIP:18824 48 bytes