From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Package updates in progress
Date: Mon, 12 Apr 2021 11:21:56 +0100 [thread overview]
Message-ID: <07030E10-1819-4684-9F12-5959AAC247E3@ipfire.org> (raw)
In-Reply-To: <65B38DCA-31D2-479D-95E1-48267205C270@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4521 bytes --]
Hello,
> On 11 Apr 2021, at 23:30, Jon Murphy <jcmurphy26(a)gmail.com> wrote:
>
> Hi Adolf
>
> Thank you for looking.
>
>> It seems like the original creater now has the repository in Bitbucket (Atlassian) and to get access to the downloads you have to have an account with atlassian. Without the account you can't even see what is available. ie is there a version 1.11 or not.
>
> I just tried to login to BitBucket to see mdns-repeater but BitBucket won’t allow it! Grrrrrr! I see this message:
> "We can't let you see this page
> To access this page, you may need to log in with another account. You can also return to the previous page or go back to your dashboard."
>
>
> And thank you for posting the notes from the kennylevinsen fork. One of the problems may be the same thing I just came across.
>
>> The first is most interesting. Say you have two networks bound together with site-to-site tunnels, repeating mDNS over the tunnel... And there are Chromecasts, or Apple TV's at both ends. Even if you had firewall rules to block traffic, the devices would still show up (albeit be defective) on the opposite network.
>
>
> I turned off ALL of my firewall rules but with mdns-repeater running via /etc/rc.d/init.d/mdns-repeater start and with mdns-repeater green0 blue0 set, I can still see and access everything from BLUE to GREEN.
>
> Stopping via /etc/rc.d/init.d/mdns-repeater stop causes everything to got back to normal (no access from BLUE to GREEN). It like mdns-repeater allows an easy path from BLUE to GREEN.
>
> I’m still testing this to be sure.
>
> I wonder if anyone else is using mdns-repeater…
I am :) It has been working fine so far.
>
> Jon
>
>> On Apr 11, 2021, at 4:53 PM, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Jon,
>>
>>
>> On 11/04/2021 21:09, Jon Murphy wrote:
>>> Hey Adolf!
>>> Can mdns-repeater (add-on) be added to the list?
>>> [root(a)ipfire ~]# mdns-repeater -h
>>> mDNS repeater (version 1.10)
>>> Copyright (C) 2011 Darell Tan
>>> I think version 1.10 (the current IPFire add-on version) is a few years old. There may be a version 1.11.
>> Current version is 1.10. It was created as an addon in Jan 2018. It seems like the original creater now has the repository in Bitbucket (Atlassian) and to get access to the downloads you have to have an account with atlassian. Without the account you can't even see what is available. ie is there a version 1.11 or not.
>>
>> There is a version 1.11 in a forked repository (kennylevinsen/mdns-repeater) but whether that is worth having or not I can't tell. It was created in Dec 2016 and had 6 commits since then but no new release. It was forked from the geekman version from Sep 2011 but as it is now in Bitbucket I can't find anything more out about it.
>>
>> This is what was listed as the changes for the 1.11 kennylevinsen fork:-
>>
>> --------------------------------------------------------
>> Blacklist feature added (16 blacklisted subnets allowed).
>> Socket limit increased to 16 sockets, moved to #define.
>>
>> The first is most interesting. Say you have two networks bound together with site-to-site tunnels, repeating mDNS over the tunnel... And there are Chromecasts, or Apple TV's at both ends. Even if you had firewall rules to block traffic, the devices would still show up (albeit be defective) on the opposite network.
>>
>> The new blacklist flag allows you to filter such devices out by specifying their subnet (or individual addresses, although having such "private" devices on their own subnet might be a good idea).
>>
>> Example:
>> # Repeat mDNS packets between eth1 and vti0, while ignoring packets from 172.20.20.0/24
>> mdns-repeater -b 172.20.20.0/24 eth1 vti0
>> --------------------------------------------------------
>>
>> So the question is do these additions warrant an update to this forked repository.
>>
>> Regards,
>> Adolf
>>
>>
>>> I haven’t located the "official" website so I am not sure…
>>> I can help test.
>>> Jon
>>>> On Apr 11, 2021, at 9:02 AM, Adolf Belka <adolf.belka(a)ipfire.org <mailto:adolf.belka(a)ipfire.org>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> For information I am working on the following package updates:-
>>>> cups
>>>> cups-filters
>>>> expat
>>>> glib
>>>> lua
>>>> meson
>>>>
>>>> I will hold submitting the patches until after Core Update 156 is released for testing.
>>>>
>>>> Regards,
>>>>
>>>> Adolf.
>
next parent reply other threads:[~2021-04-12 10:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <65B38DCA-31D2-479D-95E1-48267205C270@gmail.com>
2021-04-12 10:21 ` Michael Tremer [this message]
[not found] <EDD51CB2-83AD-46FC-8EE3-028F3FA0F490@comcast.net>
2021-04-11 21:53 ` Adolf Belka
2021-04-11 14:02 Adolf Belka
2021-04-14 7:27 ` Adolf Belka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=07030E10-1819-4684-9F12-5959AAC247E3@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox