agree to disagree. what i am saying is wrong is your statement that there is an issue hidden by reboots etc is wrong. i am not saying there is not an issue.
Wow. That is a serious problem they should fix. Did you prove that to them? What did they say?
Blocking mDNS would require a Firewall functionality a the ethernet port going to the C7. Normal consumer and enterprise switches (even my HP 1810-24G) do not have that functionality.
Yes, we went through a good deal of detail on it. It was expected to be looked at for the next release.
FWIW, ACLs are not firewall functionality. Firewalls are stateful. Switch ACLs are stateless. Just simple bit pattern blocking on ingress or egress of a port. A common capability in a switch like VLANs or QoS.
Some consumer level switches offer ACLs, some don't. Netgear and TP-Link, both of which are consumer grade, offer ACLs. I certainly would expect any enterprise grade switch to have ACL support (and VLAN and QoS). It's kinda hard to call yourself enterprise without it. Even Cisco's bottom of the line small business switches have a full ACL implementation.
3 Likes
I'm not inclined to spend $250+ to buy a new 24port switch just to get the Hubitat to work -- no 'average consumer' would do that, nor would the average consumer know about or want to mess with ACLs / managed switch. Likely even a large portion of the Hubitat target would think that is ridiculous (like I do) to even consider that a requirement. If the Hubitat has problems with mDNS, they need to fix that - period.
99.999% of consumer switches sold are unmanaged and will never have ACLs. AND many (most) consumers dont even own a separate switch, they use the Wifi Router's built-in switch since most items they use are Wifi connections these day. Wifi router switches do not provide ACLs but do provide QoS & VPNs usually / not always very good though 
HP sold millions of ProCurve J series enterprise switches (I worked for HP way back) ... it doesnt have ACLs (specs). Its old tech but there is no reason to buy something new. It works perfectly. BTW, not a single Netgear consumer grade switch includes ACLs... only business class (marketed to SMB ) Smart and above series which also have SPF -- not generally used by soccer moms/dads ... like the Hubitat is'ish 
I wasn't suggesting that you should. I was just offering you a quick solution if you had a switch capable of such.
1 Like
my mDns machines seem perfectly happy. my C7 has been running for weeks - since the last update. Perhaps it is only mDNS on jumbo frames?
Yup. I'm using multicast UDP with normal ethernet frames, and no issues at all.
But a Google search for "jumbo frames" + "udp" + "multicast" reveals lots of issues.
Edit - also found advice against using JF - like this bit:
2 Likes
Yes. A large mDNS environment with jumbo frames enabled. The problem will occur as soon as the mDNS frame exceeds 1514 bytes. In my case it was an audio switching system with lots of syncs (destinations) and multiple protocol support.
This issue will not happen with TCP, even in a jumbo frame enabled network. The problem will be caused by a jumbo UDP multicast or broadcast packet. Most users would not have any multicast traffic that could exceed the standard frame size other than mDNS.
As previously noted, the vast majority of the world does not have jumbo frames enabled because they are of very limited use. As such they will never encounter this issue. That doesn't mean that it shouldn't be fixed though.
3 Likes
I'm too lazy to read up on the problem since it seems like a self inflicted wound but I assume the fix would involve the hardware chip set, and the linux driver and possible the mdns libraries and not really something Hubitat can do on its own - unless their are known driver fixes they could apply.
1 Like
Ok for SnG I disabled Jumbo Frames on my Switch, NAS, and main PC. Lets see what happens with the C7.
BTW. I did a basic file copy to/from my Windows 10 PC & Synology (two bonded 1GB NICs)...
1.62GB (4 separate evenly sized files) shows that Jumbo Frames is faster ~5 to 10%.
Sustained 109-112M (110 average) with Jumbo on vs 96-104 (102 ave) with it off.
You may think 5% is not a big deal, and maybe not for most people, but why not get the performance gains when it is super simple to do... and when you do nightly backups from multiple PCs, it might just benefit you.
1 Like
I do nightly backups from client sites every night. This includes their san's, around 20 vm images, etc etc. That increase isn't worth the headache vs making sure they have offsite backups. Stability means more top me than 5% and I've been doing this well over 35 years. And I'm not saying yours isn't stable but as others have pointed out, not all equipment does jumbo frames.
2 Likes
Not all equipment needs to do JFs... the IP stack will negotiate the frame size with every interaction. The entire argument about 'should not use JFs' is nuts... JFs should NEVER cause a problem if the client has a proper IEEE standard (non-JF) IP stack.
Thus, if turning off JFs "fixes" the C7 (I'm not counting on it but who knows) then the problem is NOT JFs... its the poor quality IP stack the C7 uses. Period.
Seems like people here are trying to blame pot holes in the road on 'not having the right tires'. Ah no! Fix the freakn road - the tires work on every other road in the world!
Again, not every implementation of JF is the same due to lack of standards. Like I said, if it's working for you great, but every datacenter I've worked in won't enable that due to causing hard to track issues.
3 Likes
Datacenters are very different environments... there are a million times more variables and priorities are very different.
We need to get back on topic... bashing or opinions on JF is beside the point and not relevant to the problem. Which, I'll remind everyone ... we still are totally guessing and do not know causing the issue.
Actually, this isn't correct, particularly for multicast/broadcast. The mDNS packets will come out as jumbos, and will have the do not fragment bit set. No negotiation is possible.
4 Likes
non-JF aware IP stacks should see anything large than the set frame size (aka 1500) as a malformed packet ... thus discard them without attempting to read it. If it doesnt then the IP stack has a bug.
again, lets stop the JF discussion... it will not help solve the issue.
You've also been told that jumbo frames can cause the issue on your hub. This has been stated many times by the person who actually handles that section of the hub. @gopher.ny
5 Likes
