Not convenient for me right now to dedicate my laptop to that port in the wire room since I'm using my laptop for lots of other pressing things right now nothing to do with Hubitat.
But for Hubitat, can I not monitor wi-fi in general and filter for MTU > 1500? What is the filter? If I monitor for wifi w/ no filters and do a "ping -l 2000 Hubitat" from my PC, I see traffic but none related to the ping that I can tell but the ping works. Must not be capturing correctly and am trying to learn how to do so...
You can try monitoring the wifi traffic but you're going to be limited. To properly do it I would mirror a port on the switch that the AP is plugged into then plug my laptop into that switch and let it run.
I had no filters but did not see it. Perhaps there were default filters beyond the ones I removed from "cfilters", but I specifically added a capture filter for icmp and still saw nothing when I did the ping.
Yes if you have another piece of equipment somewhere on lan broadcasting Jumbo Frames. A lot of equipment can handle (or outright ignore it) if they come across it. Hubitat is not one of them. Even check your cable modem setup... I've seen weirder. I'm not saying that it's 100% this, just that when I see these symptoms that's what it "usually" is. One of the reason packet sniffing is so valuable in cases such as this...
Thx. The only way I could see a broadcast like that would be within the same AP the Hubitat is on since if not it would have to go through the switch. Is that correct?
Should I have any sort of capture filter?
I'm concerned I don't see ICMP traffic so am worried I have some traffic filtered out or I'm not monitoring the correct interface, and so may not see the jumbo frames even if filtering for just them correctly.
I see ICMP traffic if I monitor "ethernet" but not in promiscuous mode which it won't let me set. So I guess I need to monitor that interface and not my wireless connection.
Is this correct? Seems an impossibility unless it means show packets with lengths >= 1454 and also show packets with lengths <= 325. Perhaps the 2nd frame variable should be other than cap_len? Kind of like showing all number > 3 and < 1...
If I do just "frame.cap_len >= 1454" I get tons of packets including many well over length 1500 all the way up to length=54074 so have to admit I don't what is going on here or if I'm even capturing this stuff correctly.
Stopped capture after about 700,000 packets captured and 0 displayed till I understand more how to capture efficiently...
Is this a problem for the ethernet chip or the wi-fi chip? They had no wi-fi chip several years ago so I'm thinking this may not apply to the wi-fi since I have ethernet disabled.
Also, I never had a problem with my C7 which was hard wired with CAT cable.
I said it "may" be an issue. It's a known issue. I also don't know you're network, so I can only posit so much. Though the wifi is an interesting point. @gopher.ny does the jumbo frames issue also affect wifi connections?
Just for S&G post a screenshot of your Zwave details page. Should be short, you said you only have 4 devices. Ideally take the screenshot after the hub has been running for at least a few hours (the longer the better).
For now, I'm tentatively chalking this up to Ubiquiti optimizing my two AP devices' wi-fi channels at 3AM each morning which was when the Hubitat last locked up. Especially the last time it flipped the upstairs AP from channel 1 to 11 and the downstairs AP from 11 to 1 which I should think would confuse about anything. Anyway, I turned off wi-fi optimization, removed the 2nd LAN connection from my NAS so hope this stabilizes my network and the Hubitat stays running. Time will tell I guess. Thx everyone for the suggestions. I'll report back after monitoring this for a while...
Dave7, to the best of my knowledge if your switch doesn't have Jumbo Frame's enable it can't pass Jumbo Frames through it's buffer and in effect will block it in the network. If that's the case I would venture a guess you have something else causing your crash.
