I have a bunch of devices that share the same 3 octects of mac address and want to sniff the packets of all of them.
Is there a wildcard (or otherwise) way of enable the filter:
The following does not work:
tool/sniffer/set filer-mac-address=44:61:32:00:00:00
tool/sniffer/set filer-mac-address=44:61:32:00:00:00-44:61:32:ff:ff:ff
tool/sniffer/set filer-mac-address=44:61:32
tool/sniffer/set filer-mac-address~44:61:32
Thanks
I ran sniffer and see the log entry contains a mask for the mac address:
filter-mac-address=44:61:32:73:E5:FF/FF:FF:FF:FF:FF:FF
Would the following mask allow 44:61:32:xx:xx:xx
FF:FF:FF:00:00:00
Indeed.
Thank you!
Maybe you can point me in the right direction to solve the problem that gave rise to this.
These devices are Ecobee thermostats. They lose wifi connectivity on a regular basis. The only thing I have found to resolve the probelm is to cycle the power to the Ecobee – which is also the only thing I can’t do remotely (although I’ve considered putting a Shelly switch on the Ecobee’s power lines).
Ecobee can’t/won’t help. I’ve tried all sorts of troubleshooting on the local network infrastructure side.
I suspect that when Ecobee (the manufacturer) pushes a firmware upgrade, or perhaps some other reset or inquiry, the device looses connectivity and cannot recover.
So I thought I would monitor the traffic to try to figure out how to block everything except the regular reporting of temperature and the regular remote control of the thermostat. My fantasty (because I have no indications that this is true) is that there is some identifyable port or connection or packet that Ecobee (the manufacturer) sends to the device.
Do you think I’m on the right track?
I looked at the saved sniffed file, but it is not in ASCII.
Here are some screenshots of the sniff:
The modus operandi of most of these IoT devices is the same - they establish a single TLS connection to one server from a pool in cloud and internally use this connection for all sorts of communication. I don’t say it is not possible for them to temporarily establish some other connection ad hoc for a software upgrade, but if you experience the communication loss frequently, I don’t think it is related to software upgrades - I don’t think the is enough software complexity in a thermostat that it would require an improvement every other day. And if it does, I’d be afraid to use it.
Next, are you sure it loses wireless connectivity as such (i.e. the wireless communication between the device and the AP disappears) or, since it has no Ethernet interface, you call it “loss of wifi connectivity” but the actual issue may be a loss of communication with the server(s) in the cloud but the wireless hop in your premises may be OK? To find out, see the wifi/wireless/capsman registration table (or the equivalent table on the UDM) whether, while the thermostat is unreachable for its control app, it still appears in this list.
If it does, you may give it an impulse to restart at least some processes by removing the row from the table, which makes the relevant AP send it a deassociation request, so it has to re-associate and re-authenticate on WiFi level and it should also ask for a DHCP address from scratch. I have a couple of devices here that can be helped this way, but it happens once in several months at most.
If the device disappears from this list of associations, it is indeed the local wireless connection that dies off, so you indeed have to power-cycle it (or recycle it, depending on the remaining amount of your patience).
wifi with its all good and downside (noises, los, weather, winds)..
loosing signals is probably common, but having to power cycle the device is another thing. are these ecobee thermostat for the greenhouse?
while you’re looking for something in their data communication - if they are jamming, this problem could be expensive to resolve. remote power reset boxes needs wiring as well, hence denying the concept of cheap wifi.
Great approach.
I have verified (repeatedly, over the course of many months of this happening) that the Ecobee is disconnected (in a wifi sense) from the AP.
The location is served by two Ubiquity APs, and I have tried keeping 1 of them disabled to rule out a roaming issue. And, the Ecobee is connecting to a network (SSID) that is limited to 2.4ghz.
I have tried restarting the APs.
Nothing gets the Ecobee to reconnect to an AP except for rebooting the Ecobee.
The only thing I can think of is putting a wireless sniffer to determine if the Ecobee is transmitting anything, or trying to establish a connection to an AP.
Thank you for the familiarity with my environment!
No, these are in a house served by 2 Ubiquity APs. There is a hEX there also providing Wireguard, DHCP, and DNS services.
What does jamming mean?
Wiring in a Shelly switch would not be difficult or expensive. Just a little time consuming and another layer of devices to manage – 1 shelly for each of the 9 Ecobees at this 1 locacation.
Thank you for the familiarity with my environment!
well, i have used to put few sensors for my mushrooms production growing chamber (to power on automatic misting devices). but not so much luck as the sensors kept broken all the time by humidity and water vapor. the co2 sensor is the most expensive one to buy.
What does jamming mean?
well, if you need to power cycle those ecobee - it means they are hung. defective product maybe?
shelly sockets are good options - as long as you don’t have to walk faraway distance.
How humid does a mushroom environment get? I use TH316 and humidity rises quite high and haven’t had a problem.
I like the Shelly Plus 1 (or 1PM) – they really are great-performing devices.
How humid does a mushroom environment get? I use TH316 and humidity rises quite high and haven’t had a problem.
well, theoretically it supposed to be around 80 to 85 rh. but that doesn’t work for my mushrooms - with the results of the mushrooms being too wet. so i kept it around 65 to 75 rh.
our chambers is 5x10 meters each. we have 7 of them. for each chamber we have 3 controller: temperature and co2 controller for turning on the fan to get fresh air exchange (as the mushrooms are literally breathing just like us - if there is too much co2 at the afternoon, the mushrooms will be wet as well). and a humidity controller for turning on misting devices and water solenoid valve.
each chamber contains 4 tons of mushroom substrate which we make every 2 weeks. for harvest period of 3 months. if everything goes well - we should have around 1.2 to 1.5 tons of oysters mushrooms. 7 chambers get 150 to 200 kg of mushrooms daily.
really a heavy hard work from start making the substrates, bag them, pressure cooked to inoculation process. so for each ton of substrate, we literally moving 5 tons of the same substrate.
that’s why I put those sensors at the growing chambers but not that lucky as the sensors they breaks all the time 
That is very cool indeed!
Possible to put the electronic device in an environment proof box with tiny exhaust fan to remove heat (yes, you will need a way to get fresh acceptable quality air in as an exchange), and leave the actual sensor probe exposed to the environment that needs to be monitored? Or, move the electronic device outside the conditioned space, again leaving just the probe in the tested environment?
Have you looed at the Sonoff sensors?
move the electronic device outside the conditioned space, again leaving just the probe in the tested environment?
that is what i have did. the controller itself doing fine - the only thing is that the probe sensor are broken because of wet and humid. so the whole device is unusable. did recalibration but not that lucky as well 
for the moment I only do the semi automatic work with timer device.
