# Node listening on multicast mDNS port 5353 on all interfaces **URL:** \ **Category:** Support\ **Created:** [January 27, 2024, 7:07am UTC](https://forum.autonomys.xyz/t/node-listening-on-multicast-mdns-port-5353-on-all-interfaces/2406 "2024-01-27T07:07:43Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Qwinn](https://avatars.discourse-cdn.com/v4/letter/q/8baadc/32.png) [@Qwinn](https://forum.autonomys.xyz/u/Qwinn)\ **Post date:** [January 27, 2024, 7:07am UTC](https://forum.autonomys.xyz/t/node-listening-on-multicast-mdns-port-5353-on-all-interfaces/2406/1 "2024-01-27T07:07:43Z")
Is there any reason for this? It’s causing some unpleasant effects on my local network, seems to be triggering a lot of multicast spam from other devices. In particular it seems to be driving my NVidia Shield nuts, it’s responding 4 or 5 times a minute. I don’t use any autodiscovery or zeroconf on my network - I know how to configure things to work the way I like. I purge avahi-daemon from all my linux boxes, and disable LLMNR, SSDP, UPNP, and all other spammy insecure zeroconf methods. If I could at least get an explanation as to why a node would need to autodiscover other devices on my network, I might be persuaded to allow that traffic, but as it is I am blocking inbound traffic on that port and it doesn’t seem to have any ill effects. It looks like it’s doing something outbound as well though. And if it _is_ required for some reason, could it at least be persuaded to not open ports and attempt to communicate with my completely unrelated docker interfaces? (Scary thing is, the completely unrelated docker interface is replying, albeit rarely, at least.) ---
**Author:** ![nazar-pc](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.autonomys.xyz/nazar-pc/32/6_2.png) [@nazar-pc](https://forum.autonomys.xyz/u/nazar-pc)\ **Post date:** [January 27, 2024, 2:51pm UTC](https://forum.autonomys.xyz/t/node-listening-on-multicast-mdns-port-5353-on-all-interfaces/2406/2 "2024-01-27T14:51:00Z")
I think it is just enabled by default in Substrate. `--no-mdns` can be used to disable it. I believe it ---
**Author:** ![Qwinn](https://avatars.discourse-cdn.com/v4/letter/q/8baadc/32.png) [@Qwinn](https://forum.autonomys.xyz/u/Qwinn)\ **Post date:** [January 27, 2024, 4:39pm UTC](https://forum.autonomys.xyz/t/node-listening-on-multicast-mdns-port-5353-on-all-interfaces/2406/3 "2024-01-27T16:39:22Z")
Gah, that’ll teach me not to forget just looking at the damn -help. Sorry! Worked great! Thank you for the help! And now that I’m looking at the help, I was also interested in getting my farmers to not listen on my docker 30533 ports. So I replaced the old --listen-ons I had: ```auto --listen-on /ip4/0.0.0.0/tcp/30536 \ --listen-on /ip4/0.0.0.0/udp/30536/quic-v1 \ ``` on my farmer with this: ```auto --listen-on /ip4/127.0.0.1/tcp/30536 \ --listen-on /ip4/192.168.4.22/tcp/30536 \ --listen-on /ip4/127.0.0.1/udp/30536/quic-v1 \ --listen-on /ip4/192.168.4.22/udp/30536/quic-v1 \ ``` … in an attempt to mimic what the farmer log showed as the DSN ports it was listening on. minus my docker containers. … and the result was these errors: ```auto 2024-01-27T16:18:58.262503Z INFO subspace_farmer::commands::farm: Collecting already plotted pieces (this will take some time)... 2024-01-27T16:18:58.262638Z INFO subspace_farmer::piece_cache: Initializing piece cache 2024-01-27T16:18:58.870191Z INFO subspace_farmer::commands::farm: Finished collecting already plotted pieces successfully 2024-01-27T16:18:58.870469Z INFO single_disk_farm{disk_farm_index=0}: subspace_farmer::single_disk_farm::farming: Subscribing to slot info notifications 2024-01-27T16:18:58.870507Z INFO single_disk_farm{disk_farm_index=0}: subspace_farmer::reward_signing: Subscribing to reward signing notifications 2024-01-27T16:18:58.870522Z INFO single_disk_farm{disk_farm_index=1}: subspace_farmer::single_disk_farm::farming: Subscribing to slot info notifications 2024-01-27T16:18:58.870526Z INFO single_disk_farm{disk_farm_index=1}: subspace_farmer::reward_signing: Subscribing to reward signing notifications 2024-01-27T16:18:58.870613Z INFO subspace_farmer::commands::farm::dsn: DSN listening on /ip4/127.0.0.1/udp/30536/quic-v1/p2p/12D3KooWLCkwJe7HbiwcFqcjTvhr3qRvnX9rGd2WVE9rZtHqepzV 2024-01-27T16:18:58.870769Z INFO subspace_farmer::commands::farm::dsn: DSN listening on /ip4/192.168.4.22/udp/30536/quic-v1/p2p/12D3KooWLCkwJe7HbiwcFqcjTvhr3qRvnX9rGd2WVE9rZtHqepzV 2024-01-27T16:18:58.870847Z INFO single_disk_farm{disk_farm_index=1}: subspace_farmer::single_disk_farm::plotting: Subscribing to archived segments 2024-01-27T16:18:58.871044Z INFO single_disk_farm{disk_farm_index=0}: subspace_farmer::single_disk_farm::plotting: Subscribing to archived segments 2024-01-27T16:18:58.871818Z ERROR quinn_udp::imp: got transmit error, halting segmentation offload 2024-01-27T16:18:58.871826Z WARN quinn_udp: sendmsg error: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }, Transmit: { destination: 65.108.71.22:30533, src_ip: None, enc: Some(Ect0), len: 1200, segment_size: None } 2024-01-27T16:18:58.872071Z INFO subspace_farmer::commands::farm::dsn: DSN listening on /ip4/127.0.0.1/tcp/30536/p2p/12D3KooWLCkwJe7HbiwcFqcjTvhr3qRvnX9rGd2WVE9rZtHqepzV 2024-01-27T16:18:58.872246Z INFO subspace_farmer::commands::farm::dsn: DSN listening on /ip4/192.168.4.22/tcp/30536/p2p/12D3KooWLCkwJe7HbiwcFqcjTvhr3qRvnX9rGd2WVE9rZtHqepzV 2024-01-27T16:19:04.213004Z INFO subspace_farmer::piece_cache: Synchronizing piece cache 2024-01-27T16:19:04.230005Z INFO subspace_farmer::piece_cache: Finished piece cache synchronization 2024-01-27T16:19:58.889435Z WARN quinn_udp: sendmsg error: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }, Transmit: { destination: 62.171.189.152:30533, src_ip: None, enc: Some(Ect0), len: 1200, segment_size: None } 2024-01-27T16:20:10.476120Z INFO subspace_farmer::utils: Received SIGINT, shutting down farmer... ``` Tried a few various orders on those listen-ons, but none seemed to work right. Barring a simple answer pointing out how I screwed something up that I don’t see, does it actually need to listen to both 127.0.0.1 and the farmer’s network address 192.168.x.x, given those are essentially the same thing? Could it just listen to one or the other and still do what it needs to? If 127.0.0.1 (for example) would be enough, then perhaps the default could/should be changed to that rather than 0.0.0.0 which is all available interfaces. ---
**Author:** ![Qwinn](https://avatars.discourse-cdn.com/v4/letter/q/8baadc/32.png) [@Qwinn](https://forum.autonomys.xyz/u/Qwinn)\ **Post date:** [January 27, 2024, 4:51pm UTC](https://forum.autonomys.xyz/t/node-listening-on-multicast-mdns-port-5353-on-all-interfaces/2406/4 "2024-01-27T16:51:40Z")
…and, bah. Looks like my messing around broke something. When I start it back up with listening on 0.0.0.0 (same as original), it looks like it’s working fine, and maybe it mostly is, but when I control-c it now I get a bunch of “get\_providers returned an error piece”. Looks like I screwed up my piece cache, and it’s not fixing itself. EDIT: Signing reward hashes, so the only sign there’s an issue is the messages when control-c’ing.