Port 5353 Being dropped on Blue0

rabid_sausage · 10 April 2021 03:43

For the past few weeks I’ve have been trying to solve this, with no luck.
I have a HP MFP and use Vuescan as the scanner software, Vuescan uses the Bonjour protocol to search for devices.
The HP MFP sits on the Blue Network (convenience of location), and can talk to everything using Vuescan on that network fine, but nothing using Vuescan on Green can see it. It does how ever work fine as a printer, and the webportal can be accessed from Green.

Running;
mdns-repeater -f blue0 green0
I can see the data being repeated form green0 to blue0, but there is nothing coming back.
In the firewall log is shows;
DROP_Wirelessinput blue0 UDP (IP Addresses) 5353

It would look like there is a Firewall rule, or option, that is blocking the reply, however even if I disable all firewall rules, it still does not connect, with data being dropped.

Is there a way to see or trace what rule is causing these packets to get dropped?
Or can someone point me at what I may be missing.

Thanks

Mark

jon · 10 April 2021 17:54

Hello Mark - I’ve been trying to solve a similar issue (Apple products only). I may take the easy way out and add a wi-fi for GREEN but that seems like cheating.

I haven’t learned enough to be dangerous (yet). But I’d be interested if someone has a solution or a good hint for this issue!

Jon

EDIT: is there nothing in the message log at /var/log/messages ?

EDIT1: I loaded up mdns-repeater and it seems to work A-OK for me from an iPhone on BLUE to an Apple TV on GREEN.

[root@ipfire ~]# mdns-repeater -f green0 blue0
mdns-repeater: dev green0 addr 192.168.60.1 mask 255.255.255.0 net 192.168.60.0
mdns-repeater: dev blue0 addr 192.168.65.1 mask 255.255.255.0 net 192.168.65.0
data from=192.168.65.141 size=169
repeating data to green0
data from=192.168.60.145 size=540
repeating data to blue0
data from=192.168.60.105 size=357
repeating data to blue0
data from=192.168.60.210 size=353
repeating data to blue0
^C
[root@ipfire ~]#

I did have to create a firewall rule from BLUE to GREEN to get it to work (I did not try to make it port specific):

rabid_sausage · 11 April 2021 09:11

Thanks Jon for the ideas, makes sense what you did so gave it a try, but with no luck, even removing all other Firewall rules there was no change.
However, while doing this testing I did see some packets being being repeated to Green from Blue, but it was from my phone not the printer. The only difference I am aware of between my Phone and the Printer is the Printer is on a static DHCP lease.
Your idea of going through the messages, rather than via the web screen also gleamed some light too.
The DROP_Wirelessinput come form the IPtables, and I can see where, now I need to find the why.

I’m away for the week, but will read up on IPtables to understand better what is going on, and try some solutions next weekend.
Once I have it working or more information, I’ll give some information back as to what the solution was for my situation.,

jon · 11 April 2021 21:22

I’ve always seen DROP_Wirelessinput messages since I started using the BLUE network. And for me, most all of them talk to port 5353.

Since I installed mdns-repeater yesterday I am not sure if this will help or not (I would guess not).

Here is a command that will look for DROP_Wirelessinput in the messages log:

grep DROP_Wirelessinput /var/log/messages

andrew · 15 April 2021 08:56

Mark

I have the same requirement (scanner on different network than apple client). The solution requires 2 parts.

manage the "advertising and discovery"of the service using bonjour
communication for the service throughout the firewall

First the discovery. MDNS is the protocol but you also need to have the other network “discover” the service so for this I used the avahi package (which has a dependency on the mdns package). Once this packages are installed on the ipfire firewall you can use the macOS/iOS app "discovery"to see the advertised services. Remember to restart your printer after the avahi/mdns packages are active so that the service is (re)advertised. So now on your client with the discovery app you should see the advertised service (in this case Bonjour scanning) with the port that will be used for the communication.

Now you need to create a rule to allow the required ports from the client network/device to the scanner network/device. I used a rule for the source network to the printer device with multiple ports (scanning and printing).

It works very well and I use vuescan on different networks to a different network everyday without problem, and as the avahi and mdns packages are part of the standard packages they are kept in sync with the core firewall version, and so I have not had a problem with this for the at least the last 2 years.

Regards, Andrew

rabid_sausage · 30 December 2024 07:15

Sorry for resurrecting this old thread, but I have solved the issue, it still requires tidying up which is also why I’m posting for some further advice, and maybe some closure.

I had given up with the Vuescan and HP printer, after a firmware update locked the printer, however after getting a new toy I had to come back to this again. This particular situation was that I was not able to communicate with my BlueSound unit on the wired network (Green) from my mobile devices on the wireless network (Blue), the app uses mDNS for the device discovery.

mDNS-Repeater was working out of the box, and could see in the debug mode packets being repeated but with nothing really happening, so I started to dive into the logs and the workings of IPTables.

The first repeating error in the log was;

DROP_Wirelessinput from Blue0 to 224.0.0.251

This would be the returning traffic from my Bluesound unit to the mobile devices, and it was getting stopped by IPFire, so after some playing I added this to IPTables;

#iptables -I WIRELESSINPUT 1 -p udp --dport 5353 -i blue0 -j ACCEPT

That cleared the error in the log, but now I was getting a new one;

DROP_Forward from my wireless device to my BlueSound unit

and it was the same for all the wireless devices, so after some more playing this is what I added to get to IPTables;

#iptables -I POLICYFWD  5 -d 192.168.212.82 -s 192.168.222.0/24 -j ACCEPT

position 5 being the third from the bottom of the list, the IP address is that of my BlueSound unit and the range of my Blue0 network. With both of these applied to IPTables the mobile app can find and connect to the BlueSound unit without issue, what was interesting from the start without these being added to the IPTables I could from any wireless device access the http portal of the BlueSound unit without issue.

So that is where I am now, the next issue is if I make any changes to the firewall setting in the IPFire GUI or reboot, they get wiped. Then I have to SSH back in and re-apply them, bit of a pain. I have tried many combinations in the GUI to add the rules, but with no luck.

From what I have read so far it is possible to manually force these changes to the IPTables, not sure how yet. However as a matter of learning, it would be good to know what has to be entered in the GUI for IPFire to apply these changes. I’ve learnt a lot on the functions of IPTables, they are very logical, making them simple to work with, and even simpler to get then really wrong. But I cannot work out how IPFire maps from the GUI to IPTables.

Hope this is of some use to people, and once there is a permanent solution to a non-erasing IPTable entry I’ll get back and update with the new information, hopefully quicker than four years.

hvacguy · 30 December 2024 14:18

Did you try installing the mDNS addon?