nberlee / bonjour-reflector

A reflector that forwards mdns packets between VLANs - like avahi-reflector but with fine-grained control !
MIT License
73 stars 12 forks source link

Got a packet that is not a SSDP query, response or advertisement #53

Open rapkin61 opened 10 months ago

rapkin61 commented 10 months ago

I'm facing such warnings:

18:24:58 container,info,debug time=2024-01-14T17:24:58Z level=warning msg=Got a packet that is not a SSDP query, response or advertisement: 18:24:58 container,info,debug PACKET: 1116 bytes, wire length 1116 cap length 1116 @ 2024-01-14 17:24:57.357115 +0000 UTC 18:24:58 container,info,debug - Layer 1 (14 bytes) = Ethernett{Contents=[..14..] Payload=[..1102..] SrcMAC=a9:0e:15:77:40:42 DstMAC=6b:ab:e1:8e:08:19 EthernetType=Dot1Q Length=0} 18:24:58 container,info,debug - Layer 2 (04 bytes) = Dot1Qt{Contents=[0, 40, 8, 0] Payload=[..1098..] Priority=0 DropEligible=false VLANIdentifier=40 Type=IPv4} 18:24:58 container,info,debug - Layer 3 (20 bytes) = IPv4t{Contents=[..20..] Payload=[..1078..] Version=4 IHL=5 TOS=0 Length=1098 Id=17171 Flags= FragOffset=0 TTL=255 Protocol=UDP Checksum=4145 SrcIP=192.168.40.90 DstIP=192.168.40.5 Options=[] Padding=[]} 18:24:58 container,info,debug - Layer 4 (08 bytes) = UDPt{Contents=[..8..] Payload=[..1070..] SrcPort=5353(mdns) DstPort=41655 Length=1078 Checksum=47640} 18:24:58 container,info,debug - Layer 5 (1070 bytes) = Payloadt1070 byte(s)

I understand, this is not SSDP - it seems to be mDNS, but from my understanding of the description the reflector should reflect mDNS as well. Am I wrong?

nberlee commented 10 months ago

No you are not wrong, this is a mDNS response. And a unicast looking at the dstMac. which is why it was picked up by the SSDP code...

Please make sure the ip of the container (in this case 192.168.40.5) is not shared with another device. or with the broadcast address of the network.. (which cannot be in your case with a .5)

Are you using a multicast helper in your network (converting multicast to unicast, which is common on accesspoints)

In order to fix this the right way I would like to know:

rapkin61 commented 10 months ago

Thank you for your explanations!

As far as I have seen, it is always the same device (192.168.40.90). This is a printer/scanner (Samsung CLX-4195FN) which is capable to use both - mDNS and SSDP. SSDP is useless in this context, as the PC software (vuescan) cannot deal with it. Therefore I need tho use mDNS in this case (although I always thought that SSDP was also based on mDNS ... anyhow ...). The strange thing is, when I disable SSDP in the config of the printer and activate mDNS, absolute nothing seems to happen - i.e. I do not see any packets that are reflected ...

Regarding the ports: As far as I have seen, only high src ports (like 41655) are affected and the destination is always 5353.

What do you mean by "Please make sure the ip of the container (in this case 192.168.40.5) is not shared with another device"? 192.168.40.5 is the address of the VETH interface within network 192.168.40.0/24

[vlan] ... [vlan.40] ip_source = "192.168.40.5"

This address is not used for any other purpose.

BTW: is there a way to produce more diagnostic output? E.g. a environment variable?

nberlee commented 9 months ago

Ok, thank you. This is not how mDNS should behave, but its easily fixable in my code.