similar to: Relaying some UDP traffic through tinc?

I can confirm that Steam In-Home Streaming does work properly over tinc, for having tried it myself, as long as tinc is configured to route the broadcasts properly, as Guus described. Note that it would be easier to set up tinc nodes on your Windows desktop and Linux laptops, to avoid the additional complication of having to relay broadcast packets between your local networks and the tinc network.

On Thu, Apr 12, 2018 at 11:57:27PM +0200, Alex Corcoles wrote: > I've got a four site site-to-site tinc mesh working nicely. I have the > following systems at two of those sites: > > 10.a.a.2: Linux box running tinc and DHCP/DNS for site A > 10.a.a.dhcp: Windows desktop with a GPU > 10.b.b.2: Linux box running tinc and DHCP/DNS for site B > 10.b.b.dhcp: Linux laptop >

Hi, On Fri, 2018-04-13 at 18:17 +0100, Etienne Dechamps wrote: > I can confirm that Steam In-Home Streaming does work properly over > tinc, for having tried it myself, as long as tinc is configured to > route the broadcasts properly, as Guus described. Hmmm, tinc 1.11 is not in Debian stable so I guess this will be a bit of a PITA to set up. > Note that it would be easier to set up

On 13 April 2018 at 19:34, Alex Corcoles <alex at corcoles.net> wrote: > > Note that it would be easier to set up tinc nodes on your Windows > > desktop and Linux laptops, to avoid the additional complication of > > having to relay broadcast packets between your local networks and the > > tinc network. This is what I do in my setup. > > But both systems will

With pleasure we announce the release of tinc version 1.1pre11. Here is a summary of the changes: * Added a "network" command to list or switch networks. * Switched to Ed25519 keys and the ChaCha-Poly1305 cipher for the new protocol. * AutoConnect is now a boolean option, when enabled tinc always tries to keep at least three meta-connections open. * The new protocol now

With pleasure we announce the release of tinc version 1.1pre11. Here is a summary of the changes: * Added a "network" command to list or switch networks. * Switched to Ed25519 keys and the ChaCha-Poly1305 cipher for the new protocol. * AutoConnect is now a boolean option, when enabled tinc always tries to keep at least three meta-connections open. * The new protocol now

Hi again, On Fri, 2018-04-13 at 19:56 +0100, Etienne Dechamps wrote: > tinc is fully capable of traversing NATs automatically and > transparently; it implements techniques such as UDP hole punching > that are specifically designed to do just that. > > The only requirement is that you have *some* nodes on your graph that > are not subject to NATs. In your case that would be your

Dear All, We are trying the Tinc invites to let nodes join the network. This is working as described but we want to push some configuration for some nodes but this seemed not to be working. What is working is the following invite: Name = test_invite NetName = test_VPN ConnectTo = test_hub01 Ifconfig = 172.16.1.4/24 Subnet = 172.16.1.4

Have an interesting issue that's cropped up for us. We have a switch based vpn setup with multiple endpoints, some publicly accessible, some behind hide NAT. What we've noticed is that every machine can reach each other's VPN IP's up to a certain packet size. All machines can successfully ping each other up to 297 bytes. At 298 bytes and beyond, only "forwarded"

I have a simplex microwave radio ethernet bridge that can transport IP network traffic in one direction only. I need to get secondary audio streams to a transmitter site and Icecast source client seems like a good idea but the docs show me that it wants to establish a connection before starting the UDP stream. Can this be tweaked to just send the UDP steam to an ip address and port number. If not

I randomly get these errors on my Director Aug 17 10:52:37 imap-login: Error: BUG: Authentication server sent unknown id 98448 Aug 17 10:52:37 imap-login: Warning: Auth connection closed with 2 pending requests (max 2 secs, pid=27036, Received broken input: FAIL 98448 user=user at example.com) Aug 17 10:52:37 auth: Warning: auth client 27036 disconnected with 1 pending requests: EOF

http://bugs.freedesktop.org/show_bug.cgi?id=27036 Summary: kernel panic on resume on 9400M (NVAC) Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: bjt23

Sure, I?ll see if we can narrow it down for you. > On Jun 12, 2015, at 2:25 PM, Etienne Dechamps <etienne at edechamps.fr> wrote: > > That's interesting. I'm using a near-HEAD tinc-1.1 myself and haven't > encountered this problem, but I think that's because I'm using it in > router mode, as opposed to switch mode. > > I'm trying to narrow

This makes it work for us: > On Jun 12, 2015, at 5:02 PM, Chris Clements <cclements at outlook.com> wrote: > > This looks like the culprit: > > http://www.tinc-vpn.org/git/browse?p=tinc;a=commit;h=7730d5f3ed9bd7c011dced5808130ffcbd74ea6b <http://www.tinc-vpn.org/git/browse?p=tinc;a=commit;h=7730d5f3ed9bd7c011dced5808130ffcbd74ea6b> > > >> On Jun 12,

Good morning, On Thu, 2015-11-19 at 12:54 +0200, Theodotos Andreou wrote: > Hello to all, > > I am a newbie to Icecat2. I already know how to use darkice as a source > but I can't find any information on how to relay a udp multicast stream > like "udp://239.192.0.145:5000 for" example. Can icecast2 stream this > directly or do I need to use some source client?

Hello to all, I am a newbie to Icecat2. I already know how to use darkice as a source but I can't find any information on how to relay a udp multicast stream like "udp://239.192.0.145:5000 for" example. Can icecast2 stream this directly or do I need to use some source client?

Charles, It looks like the buildbot no longer builds (if it ever did, I don remember) the HAL addons, even if the requirements are met: configure:9680: checking for libhal version via pkg-config (0.5.8 minimum required) configure:9690: result: 0.5.11 found configure:9694: checking for libhal cflags via pkg-config configure:9703: result: -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal

That's interesting. I'm using a near-HEAD tinc-1.1 myself and haven't encountered this problem, but I think that's because I'm using it in router mode, as opposed to switch mode. I'm trying to narrow this down to a recent commit, but I can't find anything obvious. Did you have a working setup with a previous tinc-1.1 version? Do you have time to try a git bisect? On

This looks like the culprit: http://www.tinc-vpn.org/git/browse?p=tinc;a=commit;h=7730d5f3ed9bd7c011dced5808130ffcbd74ea6b <http://www.tinc-vpn.org/git/browse?p=tinc;a=commit;h=7730d5f3ed9bd7c011dced5808130ffcbd74ea6b> > On Jun 12, 2015, at 3:51 PM, Chris Clements <cclements at outlook.com> wrote: > > Sure, I?ll see if we can narrow it down for you. > > >> On

I'm unable to reproduce. Are you using 802.1Q (VLANs) by any chance? On 13 June 2015 at 00:15, Chris Clements <cclements at outlook.com> wrote: > This makes it work for us: > > > > On Jun 12, 2015, at 5:02 PM, Chris Clements <cclements at outlook.com> wrote: > > This looks like the culprit: > >