Add mDNS support for local networks

[techryda]

When I enable "LAN control" on my Android device I cannot send out mDNS requests. mDNS broadcasts go to 224.0.0.251 on UDP port 5353. This request stays within the local network and, I believe, should be allowed. It's useful for printer and device discovery.

My request is that this address range would be allowed/whitelisted when I enable 'LAN communication' for one of my apps.

More info on mDNS can be found at: https://en.wikipedia.org/wiki/Multicast_DNS

Thanks for your time developing this program.

[techryda]

If the LAN Control checkbox is selected in preferences, apps should not have access to 224.0.0.251:5353(UDP) unless they have their LAN checkbox selected. I think a few valid reasons for changing this are:

1. 224.0.0.251:5353(UDP) is, by all definitions, a local (LAN) address, therefore, if LAN is controlled separately from WiFi it should fall under the LAN category
2. If a user checks 'LAN Control' under settings, they have declared themself to be an advanced user and can deal with the 'consequences', namely, having to check the LAN checkbox to allow an app to access mDNS broadcasts.
3. If a user doesn't give an app the LAN permission, their goal is to prevent apps from enumerating, or communicating with, devices on the local network.
4. If a user gives an app the LAN permission, their goal is to allow apps to enumerate, or communicate with devices on the local network.
5. Currently (3) and (4) are not true for mDNS broadcasts
6. Some users don't want all/any of their print jobs first going to Google (who deletes nothing), or anyone else, then to be sent back to their printer
7. Some users don't want apps scanning or enumerating devices on their local neworks without their permission and sending that info to the internet

Many users think that when they enable the LAN checkbox for an app, that it will be able to access anything that doesn't need to be routed (anything on the Local Area Network). I think that a request (and response) to 224.0.0.251:5353(UDP) should be included in that. Conversely, I think that apps, which do not have the LAN checkbox enabled, should not be able to access this address.

Apps are regularly found in the appstore that do unwanted data collection on unsuspecting users. Why does Angry Birds need to know that a user has a Samsung printer, an iPhone and a wireless webcam on their network? It wouldn't know if it could just be granted internet permissions (WiFi) while being forbidden from accessing info about the local network (other than the default gateway).

I have an HP printing app that I use. If the internet cable on my DSL is plugged in, the app will attempt to send the print job to HP for 'processing' first. However, if I unplug my DSL modem, and enable the WiFI and LAN checkboxes, it prints fine. But, if I disable the WiFi checkbox, which would allow me to use it without unplugging the DSL modem, and without HP learning my recipe for pineapple-upside down cake :-) , it ceases to work. All communications are happening within the LAN, but it fails to work because a "LAN" address, the mDNS broadcast address, is actually identified as being in the WiFi "security group".

Also, there is no reason to setup another 'option' in the settings menu. When you check the "LAN Control" option, that is already there, 224.0.0.251:5353(UDP) should be allowed only for apps that have their LAN checkbox selected.

I hope this helps to explain my thoughts and concerns. Please let me know if I can further clarify things. Communicating about this over the internet is very tedious. I hope I come across clearly. There is all kind of potential for misunderstanding.

Thank you for your time considering this.

[lpinner]

Another use case is apps that only have LAN enabled are unable to discover dlna media servers on the LAN. I assume most users regardless of their technical abililities would expect enabling LAN access for an app would allow that app to find their media server on tje LAN. I use a custom script to allow multicast but not all users would be able to figure that out.

[lpinner]

http://en.m.wikipedia.org/wiki/Multicast_address

Example script:
#Enable multicast on WiFi
$IPTABLES -A "afwall-wifi" --destination "224.0.0.0/24" -j RETURN || exit

[techryda]

From a cursory exploration of http://en.m.wikipedia.org/wiki/Multicast_address

it seems that the following:

224.0.0.1 - all hosts on this subnet
224.0.0.251 - Multicast DNS (mDNS) address
224.0.0.252 - Link-local Multicast Name Resolution (LLMNR) address

are the main addresses to be concerned with.
I would not do a blanket ALLOW for 224.0.0.0/24 because some of these addresses
route outside of the local network and this IS a firewall app.

[lpinner]

I thought 224.0.0.1-255 was local subnet only:

"Addresses in the range of 224.0.0.0 to 224.0.0.255 are individually assigned by IANA and designated for multicasting on the local subnetwork only. Routers must not forward these messages outside the subnet in which they originate."

But that was just from Wikipedia which I wouldn't rely on.

[afflux]

I get lots of toats about AFWall blocking mDNS requests in some circumstances on CM12.1 2015-11-02. The requests originate from mdnsd (from mdnsresolver), which is started from NsdService. What do you suggest?

[afflux]

Unfortunately, I don't see how to debug which app is causing the NsdService to enable.

[sir-brickalot]

I'm on CM12.1.1-20151106 (Xposed+Xprivacy) and AFWall+ 2.1.1. and lately I get tons of toasts like AFwall+ Blocked : null(1020)-224.0.0.251:5353. Unfortunately I don't know how to allow this process in AFwall.
The Log says:

AppID : -11
Application's Name: 
Total Packets Blocked:  243
[UDP]224.0.0.251:5353(243)

AppID -11 is the Linux Kernel and everything is whitelisted for this process.

So is there a workaround or a possible fix, or an fault on my side?

[sir-brickalot]

That is why we use firewalls, right? But it still bugs me that I whitelisted everything for the process but these packets get blocked anyways. I don't get why the CM team should be asked (except why they implemented it). The main problem here as I see it is that AFWall doesn't comply with the rules that have been set.
Or am I misunderstanding something here?

/Update: I tried the AFWall Notification Filter and even ticking ALL apps and processes, the mentioned notification still pops up. This is another indicator that something is wrong with AFWall or my local installation.

Link to afwall_rules.log.txt on dropbox

[sir-brickalot]

Thank you @CHEF-KOCH for the explanation. Unfortunately I'm not experienced enough to "play with the configuration".
I would be grateful if you could post a Custom Script to circumvent this problem.

Maybe I'm not capable enough to understand your explanation but does it actually explain, why I can't control the blocking of mdns via AFWall GUI?

[0xallie]

I'm having this issue too, "Linux kernel" is whitelisted and LAN control is disabled. The notifications are really annoying.

[0xallie]

On 2015-11-24 17:27, CHEF-KOCH wrote:

I suggest to not block the Kernel since this breaks possible too many
internal things without any benefit. I also never saw any attack or
unloved traffic on this since Lollipop, so maybe we need to rework the
'unknown traffic' switch.

—
Reply to this email directly or view it on GitHub
#326 (comment).

That's the point, I'm not blocking it, it's allowed, but AFWall+ is
still blocking multicast traffic.

[ionum]

Added support for localnet multicast adresses (ipv4 and ipv6) #620

[hackel]

Why is UID 1020 (AID_MDNSR 1020 /* MulticastDNSResponder (service discovery) */) not available in the app list to allow/deny explicitly? I'm trying to get the Android TV remote app to work which uses mDNS without much luck.

[michaelh99]

I'm also seeing a lot of alerts for mDns being blocked but it doesn't show up in the afwall list of processes

[linkp]

I'm seeing these notifications as well. It appears to be the Facebook app triggering these mdns packets. While I am quite content to have the traffic denied, without an entry on the app list, it makes blocking the notification spam impossible without disabling all notifications.

Getting an entry for UID 1020 onto the app list would be useful in suppressing the noise, as well as a benefit for the users who are using mdns in their networks that wold like to permit the traffic.

[Gitoffthelawn]

Why is the Facebook app triggering these mDNS packets?

[linkp]

I have no idea why the Facebook app is causing the Android to generate mDNS traffic under UID 1020. Searches for Facebook Androidp app and mDNS were fruitless. I don't currently use mDNS from my Android, so I am content to let AWFall+ block it, but it would be nice to be able to disable the barrage of notifications AFWall+ is generating without resorting to disabling all AFWall+ block notifications. Until UID 1020 appears in the application list, or more specifically, the notification suppression list, I'm left with only two unsatisfactory options.

[minteral]

I'm also looking for a solution to suppress the blocked mdns package notifications.

[ionum]

This should be resolved by #620. @ukanth, i think you can close this issue ....

[ukanth]

@ionum

Not really, I was expecting issues since all the devices/iptables are not same. That's the reason I wanted to separate it from core.

already reported failure.
https://forum.xda-developers.com/showpost.php?p=71025484&postcount=3649

I might revert the change and work on my alternate approach

[gerroon]

I have the same issue @hackel has. I get toasts about 1020 mdns but mdns is not listed in the appss nor 1020 process.

[mirfatif]

+1 for issue reported by @hackel and @gerroon.

mDNS(1020)
Source: 192.168.43.1:5353
Destination: 224.0.0.251:5353
Protocol: UDP

Multiple requests being denied per second. UID 1020 not listed in apps list. Devices connected over Wi-Fi tethering can't resolve host.

[internationils]

Also seeing this... same destination 224.0.0.251:5353. This is (on my side) caused by the Beoplay app, which is trying to find and connect to the speaker (connected via bluetooth).
Strange thing is that even if I disable or even (force) close afwall, the speaker still isn't found.
Is this an AFwall issue, an AFwall notification issue, or a ROM issue?

[chrcoluk]

fe80 should never be blocked really, I think I will examine the rules created by afwall to see what standards are been broken.

Right now with all boxes ticked on kernel, and mdns also allowed on both wifi and lan I get mdns been blocked as well as icmp, icmp is a nasty one as well as icmp is important for mtu discovery.

The solution to this problem is allow rules for the following. (bypass app restrictions).

Allow icmp6 types timex, toobig, unreach, paramprob globally
Allow icmp types times,unreach globally
Allow all fe80::/10 for src and dst globally
Allow icmp6 types neighboradv, neighborsol, routeradv, routersol to dst ff02::/16

I will make a custom script for this which maybe could be added to the wiki.

[gerroon]

@chrcoluk

Please paste it here when you have a working one.

[ukanth]

You can add mDNS from list of apps to whitelist (LAN access should be least) in 3.2.0

[gerroon]

I do not have mdns listed, on LIneageOs 7.1 using 3.1 from Fdroid