Loss of signal alerts

  • 8
  • Problem
  • Updated 1 week ago
I keep getting alerts for loss of signal, from my new access,  but it appears to be only to myacurite cloud not to weather underground and not to the display. Anyone else???
Photo of Jim Ober

Jim Ober

  • 19 Posts
  • 4 Reply Likes

Posted 3 months ago

  • 8
Photo of Drew Shock

Drew Shock

  • 558 Posts
  • 119 Reply Likes
Hey All

We have to realize at this price point we are dealing with toys. That's why many of us have to tweak the product to get it to work more like higher-end weather stations. Most people probably never even check their data, that's the customer's Acurite probably wants and likes. We are probably a thorn in their side. Of course with the smartHUB the stations work pretty darn well. The Access puts more in the toy category.

If you want a more robust system you'll have to pony up the cash and get a Davis or something from Ambient Weather. Even through the Acurite will have the more expensive Atlas I wouldn't touch it as it will use the  same defunct Access we all have trouble with thus, putting it back in the toy category, and an expensive toy at that.

If your dead set on the Atlas, give it a year or two and see if they can fix the Access issues first.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6682 Posts
  • 1236 Reply Likes
You're comparing a Fine Offset clone to Davis?

The Fine Offset clones (e.g. Ambient, et. al.) are in the same build and price category as the 5n1.  They are produced by a company in China (Fine Offset) and sold to other companies (like Ambient) who brand and re-sell them, sometimes with some value-add.

Search for "Ecowitt" on Amazon, for example.  You'll see some units that look suspiciously like Ambient's offerings, and it's not because they are "knock-offs".  It's Fine Offset product.  Ecowitt is looking to give away some of these units in exchange for YouTube video reviews.  See their recent postings on wxforum.net for more info if you're interested. 

Access is hardly a toy.  It's far better hardware than the SmartHUB, and I think you over-estimate how many people are having problems.  It hasn't even been three months since Firmware 47 was released, but I suspect another will soon be available.

But wunderground's code re-tooling is another story.  That alone is likely going to force Acurite into another firmware update for the Access.  It's very unlikely they'll push a similar update for the SmartHUB, so be warned. 

As for Davis... I have no plans to buy another.  They really are overly expensive and getting far behind the curve as far as technology goes.  They either need to up their technology game considerably, or drop their prices.  The only new stuff Davis introduced at CES18 was in the agricultural market.... nothing for PWS or the "SmartHome" arena.
 
Photo of Drew Shock

Drew Shock

  • 558 Posts
  • 119 Reply Likes
I sure most of the stations at the Acurite 5 in 1 level as well as the 5 in 1 itself are made in China. Of course that doesn't mean they are necessary bad. I did look up the Ecowitt on Amazon and it looks just like the new Ambient station. I was in the microphone business for awhile and it was the same thing, re-branded clones all made in China.

As for the Access, I guess I shouldn't call it toy, not sure it even deserves that status. As for "far better hardware" what good is that if it doesn't work right. My smartHUB rarely misses a data point if you saw my previous post it missed 1 point in 18.5 days compared to 45 for the Access (which is higher and closer to the 5 in 1 and father from my modem/router). If our power is lost for less than 6 seconds the Access goes offline for hours and the smartHUB just keeps chugging along. Even a reboot of the router can cause the Access to go offline.

I'm sure the Access works fine for many people (or at least they think does, they may not be checking their data) but that doesn't help all of us in this forum that are stuck with bad ones. If someone has one that works I would be happy to exchange mine with them. Otherwise I have to pay for shipping to send it back to Acurite who may or may not get it to work.

It's like having a Porsche, Mercedes, or a BMW which has far better hardware than a Geo Metro. But if the Geo Metro is the only one that starts and gets me where I'm going what good are the "better" others?

Did they ever get the one you sent back working properly? I just wish mine worked at least as well as the smartHUB.
(Edited)
Photo of George D. Nincehelser

George D. Nincehelser

  • 6682 Posts
  • 1236 Reply Likes
Acurite designs here in the US.   Flip over your Access for more information.

The Access bugs will get worked out, Drew, just as they were worked out for the SmartHUB.

'Cause we all know how you ragged on the SmartHUB when it first came out, but now you're singing a different tune.

I haven't received a replacement Access yet.  It's not a big deal for me as I have another, and it was a simple matter to turn on wunderground reporting.
(Edited)
Photo of Drew Shock

Drew Shock

  • 558 Posts
  • 119 Reply Likes
The Chinese made microphones were like that also. We designed them here in the US but had them made in China.

I'm not sure when the smartHUB came out because I was not Acurite customer then. What I didn't like was the upgrade. My smartHUB worked fine when I bought it minus a few minor issues and I loved MBW. Then Acurte decided to upgrade the smartHUB and change the website. The smartHUB started having all sorts of reporting issues and you know I don't like the new less useful interface. Yes they did work the issues out after 6 months (except for the rain reset on power loss) and now it's rock solid.

How long do you think it will take to get the Access to work right? 6 months a year? It would be nice if they could work these kinks out before selling these upgrades to the public. The product I originally purchased worked until they forced an upgrade on me twice.

I like the old adage, "If it works don't fix [upgrade] it." If fact I still use an XP machine that's over 12 years old as my main computer and it works fine although maybe a bit slower with the newer programs. But I can still log into work and fix everyone's issues.

If they can get the Access to work like the smartHUB soon, I'd be happy with that.

Keep us up to date whenever they get your Access back to you and what they did to remedy the issue.
(Edited)
Photo of George D. Nincehelser

George D. Nincehelser

  • 6682 Posts
  • 1236 Reply Likes
I expect it will work just fine.  I've been using many Access units, and this was the first actual operational failure I have ever seen (i.e. one that I didn't cause myself with experimentation).

I haven't experienced any repeated failures like some others.   I just happened to be "lucky" and catch a failure where communications to Acurite alone just stopped and monitor it from a network level.
Photo of Drew Shock

Drew Shock

  • 558 Posts
  • 119 Reply Likes
As an experiment I could let the Access report to WU and see if it continues to do so even if it drops the data to MyAcurite. I have been reluctant to do so since it skips so many data points to MyAcurite. It's the dry season now so I don't have to worry about missed rainfall accumulation, which is important to me.
Photo of Jim Ober

Jim Ober

  • 19 Posts
  • 4 Reply Likes
FYI my Access was hooked to WU and lost many data points, misses none with the old Smarthub
Photo of Drew Shock

Drew Shock

  • 558 Posts
  • 119 Reply Likes
JIm that's my hunch too but some have said theirs will report to WU but not MyAcurite.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
"we are dealing with toys"
Absolutely.
The more I watch the Access on the wire, the more I come to understand that this was very likely a quick hack-up based primarily on example code from the hardware vendors.
For instance, DNS queries are *always* sent twice - to the same server. Quite often, the second response is met with an ICMP Destination Unreachable message, indicating that the Access shut down its end of the UDP channel immediately after sending the second request.
Also, traffic channels with WU and Acurite are always closed with a RST flag - even after a completed FIN-ACK sequence. This is the network equivalent of slapping your conversation partner after waving goodbye.
(Edited)
Photo of bpaepke

bpaepke

  • 3 Posts
  • 0 Reply Likes
Have the same problem as all of you.  Sensors go offline numerous times a day.  Mine was sent back to them for "repairs" and was returned to me last night after 2+ weeks with them.  Plugged it in at 6pm  By 10 pm all 3 sensors had gone offline.  It eventually recovers by itself but they have gone offline twice more (3 total) and its less than 24 hours.  Those who have sent their units back and hope they will fix the problem should not hold their breath.
Photo of Jim Ace

Jim Ace

  • 169 Posts
  • 25 Reply Likes
I was afraid that might happen, I did not get mine back but it seems they are lost to find a solution.
Photo of Gregory DiCarlo

Gregory DiCarlo

  • 144 Posts
  • 35 Reply Likes
I got mine back a few days ago. I'm still having the same problems. The techs at Acurite are complete morons!
Photo of Drew Shock

Drew Shock

  • 557 Posts
  • 119 Reply Likes
Did Acurite say what they did to "not" fix it? I don't want to send my in if it's not going to do any good.
Photo of bpaepke

bpaepke

  • 3 Posts
  • 0 Reply Likes
They did not, at least not to me.  Here is the email I got
Our Quality Control Specialists have made improvements to your unit, retested and it's working well. The unit is now on its way back to you with the following FedEx tracking number ***************. You will also receive a separate email with tracking information.
Please let us know if there is anything else we can help you with. 

In fairness, I did NOT ask for details on what they did.  I actually think the unit worked better BEFORE I returned it to them.
Photo of Brett

Brett

  • 48 Posts
  • 23 Reply Likes
I got the same explanation of their fix. Unit failed just as before. They shipped me a replacement which I’ve just connected...we will see.
Some observations: I have the access and smart hub both plugged in to the same router, monitoring the same 5 in 1 sensor. Even when it’s working, the access only updates every 5 minutes. The smart hub updates on less than 1 minute intervals. I suspect it’s around 15-30 seconds. That being said, I have a hard time understanding how the access is an improvement.
Photo of Brett

Brett

  • 48 Posts
  • 23 Reply Likes
And as expected, the access lasted less than 3 hours! The Callapatscink Yellowbreeches tab is the access. The Callapatscink Dickinson tab is the smart hub.
Photo of Bruce

Bruce

  • 21 Posts
  • 1 Reply Like
Looks like you're have the time drift issue too. The signal and battery show Excellent/Strong, but the sensor is offline. When the Access unit internal clock drifts more than 5-6 minutes from UTC Acurite stops accepting the data and marks you OFFLINE. But, WU keeps logging your data. So, you know it's not a router, interference, or signal issue.
That's why I didn't bother to send my Access in for them to repair, knew it would be a waste of TIME.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6641 Posts
  • 1232 Reply Likes
That was the theory, but I've found that wasn't true when I did a network analysis.

I suspect the clock drift is actually a symptom, not a cause.
Photo of Brett

Brett

  • 48 Posts
  • 23 Reply Likes
Yep. I’ve done all the free troubleshooting for Acurite I intend to do. This problem didn’t manifest itself until the ver 47 code was pushed out...they need to step up and acknowledge it. The first access I had worked great until the code update. I can understand sometimes things go wrong and Acurite gave me an RMA. After returning it with a lame explanation of what they did with it, and it failed again, I was annoyed. For them to send a replacement and it’s apparently worse, I’m convinced Acurite has no clue as to what to do. I’m in the electronics industry and you don’t send a customer a product with a known defect twice! I really don’t give a rats tail about the $30 I’m out, I consider that a consultants fee to not buy an Atlas (if it ever makes it to the street). I will keep the 5 in 1 and smart hub on line until Acurite shuts down support for the hub or one of them fails. Then I’ll be done with Acurite.
Photo of Steve U

Steve U

  • 449 Posts
  • 56 Reply Likes
George, Do you know what the Access uses for a time base?   Lately, random sensors are coming up yellow.  Sometimes during the day (3 towers, at different times), others at night (5 in 1).  Before 047, things were pretty solid (other than loss of Net recovery)
Photo of Drew Shock

Drew Shock

  • 557 Posts
  • 119 Reply Likes
No fix eh, bummer. If it's a hardware issue will they admit it and fix it?
Photo of George D. Nincehelser

George D. Nincehelser

  • 6641 Posts
  • 1232 Reply Likes
I didn't dig it down that far, but it seems be coming from server at myAcurite, and it is encryted.  However, I should do some more analyais.

It seems the encrytepted comms are getting messed up someway to the point that they are non longer even  attempted, but normal commos pass easily (like tto wunderground).
Photo of Gregory DiCarlo

Gregory DiCarlo

  • 144 Posts
  • 35 Reply Likes
Acurite told me via e-mail that they updated the firmware in my Access to the latest version, and "improved" the antenna for better reception. When I replied back that I already had the latest version (047) and had no issues with reception from the sensors, they did not respond. I have the unit back now, and am still having the same problems with clock drift, and not always reporting to myAcurite. Still always reporting to Weather Underground with no problems.
Photo of Stan

Stan

  • 7 Posts
  • 2 Reply Likes

When your Access goes offline, do both sensors go offline at the same time always or does it seem one does more than the other? I have one 5 in 1 sensor and 6 other sensors using the Access unit. For me, sometimes they ALL go offline at the same time. Mostly, the alerts appear randomly from different sensors in clusters of 3 to 5 sensors at a certain time and sometimes alerts will be reported across a 2 to 15 minute period. There generally appears to be about 6 hour window in-between the alerts events.

Do the sensors come back online by themselves or do you have to do a power cycle to get them back up and running? The repaired Access unit worked fine for about 3 weeks and then the alerts started. The sensors seem to be reporting data fine even with the alerts. I did a full power-off of the Access unit. Power, Ethernet cords and battery removal for about 30 minutes. It worked fine for another couple of weeks and started up with the alerts again. Like some others, I believe that it started sending alerts after a power failure. I cannot be sure since the sensors and the Access unit are at another location. The outages must have been brief because a few clocks had to be reset but not long enough for our backup power generator to come online and report a power outage.

If you are sending to Weather Underground, do you lose connection to WU as well? I do not send data to WU.

What building material is between the Access and the sensors? The walls are 2 by 4 construction with interior drywall and outside vinyl siding. Floors are 2 by with plywood and rugs. The sensors are distributed all around the house. 3 sensors and the 5 in 1 are on the same floor as the Access unit. The remaining 3 are on the floor below.

What is the make and model of your router? Are you using a switch? TP-Link AD7200 Wireless Wi-Fi Tri-Band Gigabit Router (Talon AD7200). The Access unit connects to a TP-Link 8 port Gigabit Switch port and the TP-Link Switch is connected to a router Gigabit Ethernet port. 

What brand of batteries do you have in your Access? I'm using Duracell which I've replaced twice and still have the same issue.

Do you have the Access within 3 feet of any major electronics, router and smartHUB included? If so, please move the Access away from the electronics as far as the Ethernet cable will allow you. I have finally moved the Access unit as far away as I can with the Ethernet cord you provided. The older bridge was much closer to the router using a 2 foot cable (The old bridge sat on top center of the wireless router surrounded by 8 802.11xx antennas) for a year and did not ever have this problem.

I also extensively use 2.4 GHz 802.11N Leviton smart switches and wireless Philips Hue Smart Bulbs throughout the entire house along with a couple of TP-Link Access Points. Again, no problem with the old bridge.

Photo of Stan

Stan

  • 7 Posts
  • 2 Reply Likes
Update. This morning I just checked the outside temperature which the Acurite phone app reported as 53°. I checked the cell phone's weather app and Alexa and they both said 74°. I then checked the Acurite indoor/ outdoor LED display that I got along with my 5 in 1 weather station and it was reporting 74° as well. So I created a 1 day temperature graph in the Acurite phone app and found out that the last time the temperature was reported was 7:34 AM. The current time was about 11:15 AM that I checked it.

I'm still getting alerts on a regular basis after resetting the refurbished Access unit this Thursday, July 5th. Previously, I was able to get temperature readings that were consistent with local weather station and other local weather applications. Now the problem has become so severe that I'm not getting reliable measurements from the Acurite application and website...

Will try to power off/on the Access unit once again. If that doesn't work, I'll reinstall the older Acurite Bridge. I'm not sure if I'll send it back for repair or for a refund. I'd prefer for it to just work because for me, at least, the access unit seems to have a more reliable wireless range. But reliable temperature reporting trumps more reliable wireless capability..
Photo of John Kurzeja

John Kurzeja

  • 21 Posts
  • 1 Reply Like
Hello,My indoor display has stopped connecting to the PC Connect software running on Windows 10.  It seems that a recent Win10 update might have prevented the indoor display from connecting to the PC Connect software.  I moved the display to a Windows 7 machine to see if it stays connected. I will monitor for a few days and see what happens.
Photo of Jim

Jim

  • 21 Posts
  • 1 Reply Like
Double-check your Windows Firewall to make sure that it didn't block the PC Connect after the update.
Photo of John Kurzeja

John Kurzeja

  • 21 Posts
  • 1 Reply Like
Still running great on the Win7 machine. Thanks for your response Jim but I'm pretty sure the problem with the Win10 machine is that the USB ports do not see the display unit.  I don't think the firewall has anything to do with it????
Photo of Jim

Jim

  • 21 Posts
  • 1 Reply Like
My misunderstanding - I inferred a network, not a USB connection between them.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
For you guys that are reporting time drift on firmware 047:

Q1 - how much time elapses before you notice this problem?
Q2 - what sort of firewall policies do you have in place?

Explanation:

I ran some netcaps to see what my Access was doing and learned a few things:
On startup, the Access does this:
  a. requests an IP address using DHCP. If this is successful,
  b. spends a few seconds validating that the IP address it wants to use is really available
  c. sends a name request to the configured DNS server for pool.ntp.org. If this is successful,
  d. <IMPORTANT> sends an NTP query to one of the addresses it received for pool.ntp.org.
  f. sends a name request to the configured DNS server for atlas-firmware.myacurite.com
  g. connects to one of the IP addresses for atlas-firmware.myacurite.com using TLS 1.1 and they exchange data
  h. sends a name request to the configured DNS server for atlasapi.myacurite.com
  i. connects to one of the IP addresses for atlasapi.myacurite.com using TLS 1.1 and they exchange data
 ..lather, rinse, repeat steps h and i about every 3-5 seconds

If you've properly configured your device for Weather Underground, you'll also see:
- name request to the configured DNS server for www.weatherunderground.com
- connection to one of the IP addresses for www.weatherunderground.com
- data transfer using cleartext HTTP 1.1
..this cycle repeats about every 10 seconds.

NOTES:
1. If your configured DNS server fails to respond, the Access will try to make name queries to Google public DNS servers at 8.8.8.8 and 8.8.4.4. If your firewall policies disallow this, then time sync and reporting will be broken.

2. If you disallow outbound NTP to the Internet, then time sync and reporting will be broken.

3. because these overlapped reports occur at relatively short cycles, if your firewall tries to be smart about detecting malicious traffic, the Access requests may appear as malicious traffic and get blocked. This will, of course, cause reporting blackouts  (at least).

4. Setting DHCP option 42 (NTP servers) in your environment will not change the Access behavior, because it doesn't request DHCP option 42.

I've been capturing data from the Access all day, and so far, I've only seen two NTP requests in 5 hours, but the netcap will be running all night, so I should get a better sense of the cycle in the morning.
(Edited)
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
I captured NTP update requests about every 6 hours, thus verifying Bruce's observations.
I'll see if changing my DHCP lease also forces an NTP update for each renewal.
Photo of MacGarage

MacGarage

  • 44 Posts
  • 7 Reply Likes
I had the time drift with my Access failure (mine is on the way back to them).

Before sending in, I turned off all the firewalls on the router and my Macintosh system firewall without a change. I even tried DMZ and the Access was plugged directly into my Spectrum router. My DNS servers are the Google ones. None of that made any difference. Besides, you really should not have to turn off a standard firewall to get a new piece of equipment working properly.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
I agree that turning off your firewall would be a galactically stupid thing to do, and was not what I was suggesting.
What I was doing was trying to map out the communications profile for the Access, and all you need to do is ensure that it can communicate to the Internet using the following ports:

UDP:123 (NTP to pool.ntp.org)
TCP:443 (HTTPS to myacurite servers)
TCP:80 (HTTP to WU)
If you also allow your internal hosts to make external name lookups, you should also allow UDP:53 (DNS to Giggle at least)
(Edited)
Photo of Bruce

Bruce

  • 23 Posts
  • 1 Reply Like
Jim,
In my case the drifting starts right away, but going OFFLINE happens after about 3 hours. When that happens the time drift from UTC is about 5-6 minutes. 
Here're my firewall settings....

The Access unit has a static IP.
When the lease time is 24 hours(default) the drift takes the unit OFFLINE.
When the lease time is 60 minutes the drift does NOT happen.
Changing the lease time is what got MY unit back to providing reliable service. 
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
Bruce,

I think you mean that the Access has an IP reservation. It's not possible to set the IP address statically (at the unit).
By changing the DHCP lease time to 60 mins, you may also be reducing the initial time sync to the same cycle (I can test this easily enough).
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
Yep - verified.
Outside of a restart or the 6hr cycle, the Access will only send an NTP request if the IP address changes. If it has an address reservation, then the IP address lease time gets renewed, but the address doesn't change, so the Access doesn't send a new NTP request.

Nice little conundrum: firewall policy exceptions have to be IP-specific, but if you reserve an IP for your Access to accommodate that (as I have), then you'll see the time drift due to NTP requests only happening ~6hours.

Oddly, I haven't noticed the time drift on mine..?
Afrer I replaced my SmartHub with the Access, I had connectivity problems with the 5N1P, but moving the Access 25ft closer and away from RFI sources seems to have given me a consistent 4 on signal strength.

As everyone else has observed, the Access is far less signal-sensitive and far less RFI tolerant than the SmartHub. This smells like a poor hardware design, as well.
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
Your firewall doesn't look like it has controls for its "stateful packet inspection (SPI)" feature beyond some really basic protocol definitions.
Are there more configuration pages?
What device and code is this running? Maybe I can see something online that might make sense.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
The radio receiver hardware is the same chip (MICRF211) that Acurite has always been using.  The antenna is a clean vertical helical, not the weird bent-wire setup of the SmartHUB.

Most have found reception is equal to, if not superior to the SmartHUB.

As for the clock issue, that might be a red herring.  I once thought myAcurite might be rejecting timestamped data out-of-range, but saw that the Access actually stops sending data to myAcurite while continuing to send data to wunderground.
Photo of Stan

Stan

  • 7 Posts
  • 2 Reply Likes
I reserved an ip address on the router for the Access unit's MAC Address. I'll change the release time and see if that stops the problem with my access unit.. thanks..
Photo of Steve U

Steve U

  • 450 Posts
  • 56 Reply Likes
I use a reserved address from day 1 (and also had one for the smarthub). I have one that just works.
Yesterday I added an 'unknown (owner)" tower that has a signal level of 4.  What is odd is 16% humidity (temp is 67, typ for indoors at night, when my 3 towers all run 45%-99%With the smarthub, I could 'see' the sensor, but it was never usable. The antenna fix helped
Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
16% RH on a tower usually means it is a tower without a humidity sensor element installed. 

They are commonly sold as temperature-only devices at places like Wal-Mart.
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
George, While they may be using the same RF chip, it's entirely possible that they're using it differently. Also, simply changing the antenna geometry is only part of the equation. If the impedance matching is less exact (or correct) than in the Access, that could account for the RFI/sensitivity issues.
Sadly, few people have the equipment required to actually make the distinction between sensitivity and RFI.

..or, it could be poor manufacturing (cold solder joints, etc.) that is causing these sorts of problems (firmware is unlikely to accomplish much in these cases). Those are real PITB to sort out - especially if they're treating the hardware as essentially throwaway from a repair POV.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
This has been thoroughly covered a while back. 
Photo of Bruce

Bruce

  • 23 Posts
  • 1 Reply Like
Jim,
I could not find any other firewall settings.
Router: Linksys WRT3200ACM
Running:  DD-WRT v3.0-r36006 std (05/23/18)
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
Bruce,

I was looking over the DD-WRT wiki and I understand why changing your DHCP lease time changes worked.
https://wiki.dd-wrt.com/wiki/index.php/Iptables_command#Firewall_blocks_DHCP_renewal_responses

By default, your router code blocks DHCP renewals. This forces the HCP-configured client to release its current IP address and run through the whole DHCP discovery process. By forcing this to happen every hour, your Access will also make an NTP request every hour, effectively sidestepping the apparent time drift issue. Since the wiki seems to suggest that the DD-WRT default firewall behavior is to allow all outbound (and relevant response) traffic, I don't think that your firewall is blocking your Access.

..bear in mind that this is only a guess, since I'm not entirely iptables-savvy, but I do understand firewall-speak.
Photo of Bruce

Bruce

  • 23 Posts
  • 1 Reply Like
Jim,
Can you explain (in "I know enough to be dangerous-Speak") why the Access clock has NO drift when my lease time is 60 minutes, but while the lease time is at the default of 24 hours the clock drift starts to be noticeable within minutes?
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
George,

As for the cherry clupeidae, I'm beginning wonder about that, too.
Something I'm not entirely clear on is *how* exactly the Access time is being verified by everyone.
The only place I see where it expresses time is in the "Last Time (UTC)" field on the manglement page. It doesn't even fill in the client timestamps in the NTP requests.
If you don't refresh this page manually, it *will* display an increasingly older time stamp.
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
Bruce,

I'm not entirely clear on how you're determining that the Access clock is drifting..?
Bear in mind that I'm not calling you out - just that I haven't seen a clear test methodology that I've been able to reproduce.

I can't answer why the time drift seems to happen *within minutes* if the lease time is 24hrs, but doesn't seem to happen at all when the lease is only 1hr. I do know that according to my testing, the Access updates it's time reference from pool.ntp.org:
 - every 5-6 hours
 - on restart
 - when forced to acquire a new IP address

I've been watching my Access "Last Time (UTC)" field on the manglement page for the past couple of days and haven't observed anything that I'd call worrisome time drift (not even a whole minute), regardless of IP lease time. Bear in mind that for SSL (HTTPS) communications, the clocks on the client and server can be as much as 5 minutes different without affecting anything.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
For basic encrypted communications like TLS, the clocks can be YEARS off and it won't matter.

Time synchronization isn't an issue until you start using higher-level protocols and applications.  For example, the default 5-minute maximum clock difference of Kerberos authentication.

Even an expired certificate won't matter to the Access, as it isn't enforcing strict certificate checking.
Photo of Gregory DiCarlo

Gregory DiCarlo

  • 145 Posts
  • 35 Reply Likes
What, then, could be causing the Acurite servers to reject updates from the Access?
Photo of Bruce

Bruce

  • 23 Posts
  • 1 Reply Like
Jim,
Here's a screen shot of how I'm seeing the time drift. I'll do a refresh of the Access screen and compare it to the time on the NIST window. The screenshot was captured immediately after the refresh of the Access window. I agree, when the clock is keeping time I'll see small differences of less than a minute. Maybe I need to go back and compare the actual drift of the 2 setups. I may have been too quick to judge that one drifted faster that the other up to the 60 minute renewal. What I saw as "no drift" may have been because I was not watching it for 60 continuous minutes, but rather I'd check it once in while as I was doing other things.
Go ahead and call me out, sometimes that will create the spark that solves the problem :>)

Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
I've found no evidence that they are rejecting updates as I originally thought.

When I monitored the network traffic from a "non-working" Access, there was no traffic on port 443 to myAcurite at all.  However, traffic to wunderground on port 80 was completely normal.
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
George,

the fact that the Access will tolerate that much time offset and doesn't even validate the server certificate expiration is disturbing.
..but that's a different discussion and it goes even further into validating the "toys" statement...

Did you capture that traffic? Does it express prior functionality, then not? Would you be willing to share?

Bruce,

Based on what George has stated,and what I've observed, there is no timestamp offered to WU, although there may be one offered to the Acurite servers (can't see into the SSL traffic). Where WU provides a parameter for a timestamp, the Access says "now" (dateutc=now), allowing the WU servers to use their own sense of time.

If the Acurite servers are detecting time shift, they may be signaling the Access to go away with that noise, but there's no way we can tell from the client side.
Photo of Bruce

Bruce

  • 23 Posts
  • 1 Reply Like
        " If the Acurite servers are detecting time shift, they may be signaling the Access to go away with that noise, ...."
Jim,
In other words "go away kid, don't bother me with your BAD data"
Have you verified the stoppage of traffic to Acurite when the sensors go OFFLINE due to a time drift?
Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
Disturbing?  Why?

It would just be a gee-gaw in this case... something common for toys.

I don't have a copy of the traffic.  It's a bit hard to capture something that isn't happening.

In any case, Acurite's servers can't reject data that isn't being sent.
Photo of Gregory DiCarlo

Gregory DiCarlo

  • 145 Posts
  • 35 Reply Likes
Then why is the data being sent to Weather Underground, but not to Acurite?
Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
That's the $64,000 question.... Why is it only data to myAcurite that is impacted?

The other question is why it seems to affect a few people consistently, but others rarely or not at all.

Whatever the problem is, it seems to be something internal, and we don't have access to any debug console.  We're completely blind.
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
Bruce,

No, i haven't been able to verify that because I haven't repro'd the time shift. ..at all. My Access always seems to be within a minute of the correct time. I can block NTP from the Access through the firewall and see if it happens.


George,

Regarding your "hard to capture something that isn't happening" comment, I was referring to the possibility that you might have been capturing traffic from the Access prior to the failure state, and so we might have some proxy data to examine. I haven't been able to repro the only consistently-reported fault: lack of comms to *only* myacurite.com, although I hope to have something when I block NTP from the Access today.

The Access ignoring certificate timestamps is disturbing for two reasons:
- it lends no level of assurance regarding the quality of the code ("toys" factor again), but more importantly,
- it raises the question of what other TLS security factors the Access is ignoring. The failure to validate the certificate timestamp suggests that it's only using the public key provided in the certificate without *any* regard to certificate validity (common in vendor-supplied sample code).

I do know that I've never seen the Access perform CRL validation, even though the CRL URL is part of the myacurite.com certificate itself. A DNS spoof or a MITM attack is a basic skill for any self-respecting hacker, and if the server certificate is essentially unvalidated, it's all that much easier for the attacker.

The larger point is, Access is yet another of the rapidly growing IoT (Internet of Things) devices that are so popular with hackers because they're so poorly coded, making for an easily-acquired bot army or foot-in-the-door for APT operators. Once they get that bot or foothold on the internal network, it's a simple matter to include it in their next distributed attack, or thumbprint the rest of the network looking for *more* weak spots.

https://news.sophos.com/en-us/tag/iot/ has lots of articles on the real and potential threat models for IoT devices

.and you're right, lacking visibility into the underlying communications between the Access and Acurite servers, or some form of debug channel, we're totally blind to the defining symptoms, much less the causes.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
You're again making a lot of unfounded assertions.

Just because you don't understand an implementation doesn't mean something is a "toy" or "poorly coded".

There's no real point in using strict certificate checking in this application.  It's pretty much a waste of time and money, and just another "moving part" to break in the system.  Acurite (and other weather networks) want to accept your data.  Why would they throw in an extra and needless barrier to doing so?

There are different levels of security for good engineering reasons.  This one is to move trivial non-sensitive data. 

As for hackers gaining a foothold in the Access (or SmartHUB) itself, that's another matter entirely.  It's also something well-explored via independent intrusion testing by users over the years.

As for your last paragraph, there is absolutely no problem of "visibility" in the communications.  That's all in the open.  What we don't have is simple access to is a console on the processor.
(Edited)
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
Bruce,

I blocked NTP for the Access device after the first successful query, and have been capturing traffic from it since startup. Hopefully, we'll see if there's anything to the time drift problem as relates to MyAcurite communications. If necessary, I'll also play some MITM games with the Access to validate certain statements and assumptions about whether adding TLS was worth the effort. I'm not holding out much hope, since Only some people are reporting this, and I've not seen my Access drifting at all...

George,

It's easy enough to divine a device's general network code quality from its behavior on the wire (as I've described above), never mind the odd behaviors being reported by others. Asserting lack of code visibility is a poor defense of code quality.

As far as "making a lot of unfounded assertions", you yourself said that "[Access] isn't enforcing strict certificate checking." Either you know this to be true, or you don't. Until demonstrated otherwise, I'm inclined to take you at your word. I've seen for myself that the Access issues *no* CRL lookups - ever, much less OCSP queries. It's worth noting that the AWS-generated certificate supports both. For a device which purports to implement TLS1.1, this is pretty weak sauce.

Regarding the "extra and needless barrier" - if not to protect sensitive information such as account credentials (which, AFAICT, are not used by Access or SmartHub) by way of encryption, the only other reason to use TLS would be for validating server identity using the certificate CN or UPN fields (both are populated in the MyAcurite certificate). Since the Access provides the TLS1.1 Server_Name_Indication field in the Client_Hello message, and the firmware updates are also performed over TLS using the same server certificate, this seems likely. Unfortunately, failing to validate the certificate itself functionally reduces the added expense of TLS to a state of excess complexity, because the Access is failing to validate the trustworthiness of the certificate which claims to assert server identity. Consequently, delivering a malicious "firmware update" to the device is as simple as a DNS spoof attack. Either this was ignored by those intrusion testers, not reported, or it was deemed unworthy of correction. None of these are good scenarios.

As for hackers gaining a foothold, that's exactly the point of my argument. It's been well-demonstrated that IoT devices are the weakest security links in any network, primarily because of their incomplete implementations of security protocols. These *are* unnecessary complexity because they actually reduce the overall security of an environment while incurring far less benefit.

To your statement about visibility in the communications, I know from my own testing that traffic passing between the Access and MyAcurite servers occurs via TLS encryption. This is not "all in the open." If by that, you mean that you have a reference for this communication, I'm happy to peruse it and withdraw any negative assertions demonstrated otherwise.

By comparison, WU traffic is passed in the clear. Even with device (not account) credentials.

Given that the servers at atlasapi.myacurite.com are also failing to include an intermediate trust certificate reference in the trust chain, it's pretty obvious that the Access doesn't validate the trust list. The server certificate is incomplete, and the client clearly doesn't care.

Half-implemented security is effectively none at all, and all too often weakens overall security. There's plenty of history to demonstrate this. If one of the goals of Access coding was to minimize unnecessary code paths (as it should be for any good product), that goal was underachieved with an incomplete implementation of the most basic functionality for a TLS client.

..but none of this is helping answer (much less solve) the $64K question.
I'll respond later with my test results.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
I'm sorry, but you are simply way out in the weeds.

Good luck with whatever it is you're trying to prove.
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
..and to extend your metaphor: ..that's a response I might expect from one who seems not to care about the topology of the garden or the relevance of the flora.

The only thing I'm trying to demonstrate is whether a failure to acquire time sync causes the Access time to drift as much as has been described, and if so, whether this correlates with communications to MyAcurite. I can only demonstrate correlation, because there is no visibility into the encrypted traffic or the device itself for me to use as "proof".

So far, it's drifted about two minutes over a total of 7 hours since startup, and only about 2 hours since the first NTP failure. It's not looking good for a repro, but then, I never saw significant clock drift before this, either.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
Seriously?  For all your talk you can't figure out how to decrypt the data?  Haven't we been discussing how they chose not to implement strict enforcement?

You might want to check out what the author of Acuparse has already done in this area and integrated into his program.
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
Thanks for the suggestion,
My specific comments about the data encryption on the wire were a note about inconvenience. My comments about the security failure of partial TLS implementation are related, but no less valid for that.


..but to the repro effort...
MyAcurite generated a "no data for over 2 hours" alert as of 0137PDT this morning, about the same time that the Access' clock drift exceeded 5 minutes. WU still showed it as online and current then.  For the record, I *don't* show the same rate of drift as others have (only ~30sec/hr) - that's why it took an overnight run to repro the problem with MyAcurite.
My Access continued to talk to both MyAcurite and WU, but at increasingly irregular intervals for several hours after it was reported as being offline by MyAcurite. Now (0845PDT), it hasn't tried to talk to either of them for over 15 minutes.

A MITM setup might be an interesting step, now.

BTW, the indications on the MyAcurite page are misleading, since neither the 5N1 nor the Access are actually "offline" - my Access was still communicating with MyAcurite services ~@5min and is sending sensor data to WU at increasingly variable intervals (might be the additional overhead of NTP queries being sent ~1sec or so).
(Edited)
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
..and also as reported, the Access couldn't get itself back to a functional state, even after it got a valid time sync. I had to restart it from its manglement page. The MyAcurite site apparently requires at least 2 consecutive reports before it'll change the Access state to "online".
(Edited)
Photo of John Z

John Z

  • 903 Posts
  • 187 Reply Likes
There is no good reason why a crystal controlled time base should drift more than a few seconds per year.

Most of what I have seen posted here on the forum is indicating minutes per day, and almost always "fast", getting ahead of real time. David Pushee, who first posted about this (see thread "Access Time Warp" ) was observing about twenty minutes per hour, and with an odd dependency on network activity.

FWIW, I have observed no drift on the three Access devices I have used for many months.

What this all is suggesting to me is that, for some fraction of the installed base, circuit conditions stack up such that on- board circuit noise gets injected into the crystal oscillator signal and starts clocking up the timers.
(Edited)
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
..either that, or the power brick is injecting line noise, but this is difficult for Joe User to test, and I haven't heard whether the Acurite support folks are examining that.

How are you observing time for your devices? I was using the "Last Time (UTC)" in the Access manglement page, but I found the GMT Unix time field of the TLS Client_Hello message to be a more immediate indicator, since the Access updates it more dynamically.
Photo of John Z

John Z

  • 903 Posts
  • 187 Reply Likes
I am not the network geek that you or George are so I just rely on what the Access home page reports.

I am a circuits guy, though, with a great deal of experience wrangling really nasty problems.

Your speculation about power supply noise is not without merit, but I am placing my bet on processor and/or Ethernet controller noise.

The regulator implementation on Access is less-than-deluxe, and may be responsible for the restart issues many experience after a power glitch. I believe there is adequate capacitance on the power net, with adequate frequency response, to prevent supply noise from getting through, but I could be wrong.

Appreciate your posts so far, as I do those from George. I learn from you guys.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6656 Posts
  • 1232 Reply Likes
I haven't noticed any significant time drift on any my Access units, either.   Even the one that "failed" continued to keep good time.
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
..so odds are looking pretty good that we have a multi-source problem (multiple causes creating a single apparent effect).
At least I can describe a specific repro in enough detail that the folks at Acurite should be able to do their own debugging.

I was once a circuits guy, too (20 years as US Navy electronics tech), which led very neatly into IT with networking and security as my main games.
(Edited)
Photo of Bruce

Bruce

  • 23 Posts
  • 1 Reply Like
Jim,
Great detective work!
It's disappointing to hear of units being returned for this issue and they come back to the owner with the same problem.
John,
Interesting idea about the Ethernet controller injecting noise into the clock circuit. I'll have to move my unit to see if the drift rate changes.
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
T'anxQ- it's something I miss doing, since I haven't been paid for it in about 6 years (been gettin skooled in psychology & music).

It's possible that the Acurite support folks don't have the means or motivation for detailed troubleshooting - I know that many such devices are considered throwaway by many vendors, because the ROI for deep troubleshooting is so low.
Photo of John Z

John Z

  • 903 Posts
  • 187 Reply Likes
Jim,

To my thinking, AcuRite would have done well to build Access on a 4-plane circuit card, instead of trying to get by with two wiring planes. It would have absolved many circuit/noise issues at not much added cost.

Watch for posts from Steve U. He contibutes frequently here ,and his background is very similar to yours.
Photo of Jim

Jim

  • 39 Posts
  • 4 Reply Likes
I haven't even opened the unit yet - don't want to upset the warranty gremlins, yano... ;-)
That said, I've found a mostly-acceptable workaround for my unit's sensitivity problems - I've moved it closer to the 5N1 and further from other electronics.
..one of the advantages of properly prewiring my house during the build is that I have lots of options.
My wife gave me lots of grief for running two CAT6 and one RG6 into the kitchen "I'll *never* use them - it's a waste of cable and time..."
Now the Access sits behind the coffee pot - right where I ran those cables.
It's a shame it's not PoE-capable...
Photo of John Z

John Z

  • 903 Posts
  • 187 Reply Likes
Steve U is successfully using a POE-to-microUSB converter/splitter to run his Access.

Chuck Hast had a terrible time getting his Access to work well in his home. Chuck, who is a ham radio guy, found that his cable modem emits a strong spurious carrier signal right in the Access receive channel. That signal would cause Access's automatic gain control to kick in, effectively desensitizing it. He finally found a spot where Access could work.

Curious, I drove around my neighborhood with a very capable receiver to assess my local environment. I found that about 5 percent of the homes here emit objectionably strong spurious carriers inside of Access's passband, which is about 300 KHz wide at 433.92 MHz. That is awful. Access does a great job of pulling it's sensor signals through the data burst clutter at 433.92 MHz, but an interfering continuous wave signal will keep the receiver AGC activated, suppressing legit data reception. Access probably wouldn't work well in those homes.
Photo of John Z

John Z

  • 903 Posts
  • 188 Reply Likes
Bruce,

Moving your unit should have no effect on this. If this issue is real, the noise is internal and will follow the device.
Photo of Bruce

Bruce

  • 23 Posts
  • 1 Reply Like
John,
Confirmed, no change seen by moving the unit from sitting on top of my network switch.

Jim,
I'm seeing a +3 minute drift per hour (fast) when the router is set to the default lease time (24 hr.). With the lease time of 60 or 240 minutes I see no more than 20 seconds (slower) difference in the time. Must something in the way my router is refreshing the IP address. <shrug> 

Thanks to both, I've been learning new stuff :>)
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
It seems possible then, that your time drift is non-linear, possibly validating John's suggestion about some circuits operating too fast/hot (or perhaps your Access can't cool itself properly - it's just convection-cooled).

Nothing about IP address assignment via DHCP involves time information other than maximum elapsed time for lease renewal and expiration (they're actually different).
Photo of Bruce

Bruce

  • 23 Posts
  • 1 Reply Like
I ran 2 tests (60,240) to see if I could see the time get corrected when the lease time expired. No drift.  I dunno why it works but leaving a setting of 60 or 240 minutes in the lease time fixes the drift and I have NO sensor drop-outs. With the default lease time the drift was noticeable at the first 5 minute reading and my sensors start dropping off within 3 hours. The room is air conditioned and the unit doesn't feel warm. I do think I have a unit that has some issue with the clock running fast, but if AcuRite keeps insisting that the sensor drop-out is due to signal strength or noise there's no point in sending it back.
Photo of John Z

John Z

  • 903 Posts
  • 188 Reply Likes
To clarify, when I said "hot, fast", I did not mean to imply thermally hot. I meant to suggest chip devices that are at the high performance end of their manufacturing process distribution, devices that switch really fast and draw maximum specified current. These would generate the greatest logic noise.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
Regarding the noise generation, that's true, but as you also pointed out before, better circuit design should have accommodated that.
Current network technology that is operating at the edge of its capabilities on 100Mb networks is pretty weak sauce.

Granted, these aren't isn't supposed to be Mil-Spec devices, but a little more QC would have been nice...
Photo of John Z

John Z

  • 903 Posts
  • 188 Reply Likes
George,


My guess is that not a large fraction are seeing this clock issue, but that those who are consistently report .


It may be that only those devices that have processors or Ethernet controllers on the "hot, fast" end of the performance distribution are involved. Speculation, of course, and we may never know the answer.


Hope you are strong and well.
(Edited)
Photo of George D. Nincehelser

George D. Nincehelser

  • 6684 Posts
  • 1236 Reply Likes
Thanks.  Things are about at the 100-day mark and I'm getting ready for another round of tests.  So far so good...
Photo of bpaepke

bpaepke

  • 3 Posts
  • 0 Reply Likes
So my returned unit now works worse than it did before I sent it back to them. Here is the reply I got from support just an hour ago.

We have had a few users experience the same difficulty, and this step has proven to improve the situation in some of these cases. We would recommend that you rotate the Access, say 90-180 degrees at a time until you can find a spot that works well. After rotating, leave the Access in the location unless you go back offline. If you do go offline try rotating again. The best experience we have found that if the Ethernet port is 12 o'clock and the blue light is 6 O'clock, between 6 and 12 facing the 5N1 outside provides the best reception.
Please contact us again if you need further assistance.

BTW, I don't have a 5N1, I have three separate sensors located in various places around my house so rotating the Access to cover all 3 according to their suggestion, is impossible.

Probably time to give up on this and seek a different solution.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
Part 2 of the traffic flow saga...

I decrypted the update traffic from the Access and was amused to find yet another case of protocol abuse. The Access sends an HTTP POST request with content-length:0 and all of the data as query parameters. <sigh> That's a GET mechanism, folks... ..and it populates the HTTP Host field with atlasapi-development.myacurite.com - completely different from the atlasapi.myacurite.com it places in the server_name_indication field or the DNS query it issues for that service. IOW, it just doesn't care who its talking to as long as it responds "HTTP/200 OK" to it's traffic (if it cares that much).

More interestingly to the assemblage herein, the Access *does* communicate time to the MyAcurite servers as a "dateutc" field, which is expressed in UTC format to the whole minute, i.e., YYYY-MM-DDTHH:MM:00 (seconds are always 00). In contrast, it only sends the text "now" in that field to WU.

Although Acuparse was useful in simplifying the setup for decryption (thx, George), it's not displaying the data and apparently not forwarding to myacurite.com properly (unit shows as offline after a few minutes). Acuparse does connect to and communicate with the MyAcurite servers, they just don't seem to like what it has to say. I'll have to engage in a bit of troubleshooting before I can set up another time drift test to see whether the MyAcurite servers are rejecting the Access update request when the Access time > 5 minutes.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6684 Posts
  • 1236 Reply Likes
I didn't imply that Acurparse was going to display the data.   I gave it as an example of decrypting the data.  

Yes, a timestamp is sent by the Access to myAcuite.   That's well-known.   Wunderground uses "now" for simplicity, but you can send a timestamp if you need to report older (or unreported) data.

I'm not sure what you mean by "protocol abuse".  The reporting method used by Acurite, wunderground, and a few other weather networks are closely related.  They have evolved over time but still retain traces of their legacy.   This is not at all unusual.  

Acurite has different APIs for different purposes.  That is not unusual, either.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
No, you didn't - Acuparse did. That's it's whole purpose in life - to accept, parse and interpret the data sent by an Access or smartHub. As to why it isn't doing that, it may be related to why it also isn't communicating properly to MyAcurite services (another stated feature).

I described in detail what I called protocol abuse. SSL and HTTP are well-defined protocols, both of which are used incompletely or incorrectly by the Acurite devs.

My point about the timestamp was trying to determine if the MyAcurite services use this to validate the communications, since the Access reports its time in detail during this exchange (BTW, seconds *are* populated in the dateutc field - my previous tests just happened to occur at :00 seconds each time - figure those odds).

Historical data notwithstanding, the apparent failure state is when the Access reports data more than 5 minutes in the future (the clock drifts fast). Until I can see how the servers respond, I can't say for certain if the servers are rejecting the report, or the Access is just finally giving up in spite of a successful response.

Again - if you have a reference for this communication, I'm happy to review it. It'll save a LOT of unnecessary testing and may actually help focus the testing.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
..and just to clarify, Acuparse itself isn't decrypting the data. This happens at a combination of the operating system and the Apache web system levels. Acuparse itself never sees the encrypted traffic.

Regardless, shouldn't be overly difficult to create a mini-proxy that will simply regurgistate the traffic between the Access and MyAcurite. I just need to sit down and find or write it.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6684 Posts
  • 1236 Reply Likes
Now Max doesn't know what he's doing, either?  

"Protocol abuse" refers to attacking a system or network.  It doesn't mean a protocol is being used incorrectly.

Again, just because something isn't being done the way you think it should be done, doesn't make it "wrong".

For example, you asserted that the "POST" should be a "GET" because the content length is zero and the data is in the query line.  No.  This technique is used when you want each request to be treated individually, regardless of any repetition.  

"GET" is idempotent.  "POST" is not.  Choosing which is "best" to use is up to the API designer, often taking into account the specifics of the back-end design.

It's hardly "protocol abuse".
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
<chasm type='sar'>Yes, George, that's what I'm doing - I'm choosing specific people, none of whom I've never even heard of, to insult. You got me.</chasm>

Protocol abuse (misuse, if that satisfies your sensibilities) is also using a protocol in ways not defined or provided for in relevant RFCs.

My comment about "that's a GET request" was pointing out that they're sending a POST request that specifies the inclusion of form data, the length of which is set to 0, while sending all the data in the URL query fields, rather than the form data they supposedly specified, but set to 0 length. IOW, They used a POST like a GET. This "smells like" leftover protocol experimentation, particularly when you consider that the host field contains a server name not used in the TLS connection or DNS query.

..but you're right - this is a single-use Web application, not intended to support clients or services other than those they built, so I'll leave the HTTP critique alone, funny though it is.

I still intend to build a simple reverse proxy to capture the traffic between my Access MyAcurite so that I can determine whether the server is rejecting "future data" or the Access is just giving up. Unfortunately, Acuparse didn't provide that function reliably.

Once again - if you have references for this communication, I'm happy to review it.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6684 Posts
  • 1236 Reply Likes
It doesn't matter what you think it "smells like".  It's a valid, legal method.  For example, it's often used when you need to be sure all requests get through to the server with no caching.  

Maybe this discussion will help you understand that this is not "leftover protocol experimentation".  https://stackoverflow.com/questions/611906/http-post-with-url-query-parameters-good-idea-or-not

FYI, Max is the author of Acuparse.... the guy whose work I suggested you examine.  
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
First, I wasn't commenting on Acuparse's protocol usage, but Acurite's. If you're saying Max is both, then so be it. My only comment about Acuparse is that it wasn't behaving as advertised, and I wanted to investigate why this might be (yano - troubleshooting). I'm not sure what you think I'll gain by examining his work until I have it working properly.

The communications I commented on was traffic from the Access, not from Acuparse. I used the certificate .key file used by Acuparse in Wireshark on my Acuparse host to decrypt the traffic between them. Acuparse itself seemed not to see, accept, or understand the request from Access (part of troubleshooting effort is determining which).


As far as the "valid, legal method", there's actually quite a bit of dissent on that point in your linked discussion. Since Acurite isn't using REST, that part of the discussion, while interesting, isn't really relevant. The response by Tim Lovell-Smith is the most concise, IMHO. As I read it, he both rejects and (sorta) supports your interpretation:

- "RFC 3986 defines HTTP query strings as an URI part that works as a non-hierarchical way of locating a resource"

- "If a web browser is the primary way people are accessing your web application, and application/x-www-form-urlencoded is the Content-Type they are posting, then you should follow the rules for that Content-Type. And the rules for application/x-www-form-urlencoded are much more specific (and frankly, unusual): in this case you must interpret the URI as a set of parameters, and not a resource location."
-- AFAICT, the Access is not making use of a web browser (ridiculous amount of overhead for embedded code on a limited-use device), so there's no specific requirement to abide by this.

..but more to my previous point:
- "Generally, the server can interpret query strings according to whatever rules it wants"

As I said in my prior "but you're right" comment - this is how the folks at Acurite chose to implement their HTTP-based communications. It is apparently not intended to support clients other than those they build (much less browsers), and unlike their TLS usage, appears to present no immediate threat to their customers directly or by proxy, so any further discussion on that point is fruitless.
..so back to my reverse proxy. Acuparse is interesting, but I only used it as means to set up an Apache instance that might offer some interesting views on my Access data. Since I'm more concerned with how the Acurite service responds to "future data" from a time-traveling Access, what I really need is a basic proxy, not an interpreter.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6684 Posts
  • 1236 Reply Likes
I only directed you toward Max and what he has done before.  You don't need to use Acuparse for anything.  It was only provided as an example that looking through the encryption is very doable.  

Likewise, the stack overflow conversation was presented as an example to show that the POST technique is something developers have been talking about for a long time, and not something someone at Acurite just conjured up out of thin air.  

If you actually need a pre-built debug proxy server, there are tools for that... like Fiddler or Charles.  They are serious over-kill for what you want to do, but I'll throw them out there anyway.
(Edited)
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
Since I already built an Ubuntu VM with Apache for Acuparse (it depends on Apache for TLS decryption and HTTP handling), configuring Apache as a revproxy isn't too hard - lots of instructions on the Interwebz, I dun already dood it.

I don't need interpretation a la Acuparse (the queryfields a pretty self-explanatory) as much as I do a transparent HTTP pass-through mechanism between the Access and the AWS service so that I can see the service responses. An SSL reverse proxy suits this purpose perfectly.

I have the private key for the Apache revproxy instance installed in Wireshark, so it can decode the traffic on the client side of the two connections to give me HTTP visibility within the TLS session and data persistence in the capture file I'll save.

Gathering data and hopefully, I'll be able to provide something actionable for the AcuRite folks.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6684 Posts
  • 1236 Reply Likes
They already know.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
..they already know - what, exactly? Brevity without clarity isn't very useful...

From what I'm able to glean from the various posts and comments about these problems, their repro efforts seem limited to antenna and firmware updates. I'm running the latest release (047) and I can repro (a variant of) the problem.
Photo of George D. Nincehelser

George D. Nincehelser

  • 6684 Posts
  • 1236 Reply Likes
They already know what the issues are.

This board does not reflect what is going on with their testing programs. 

You likely won't hear anything on this board until fixes have already deployed. 

 
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
..yeh, that's pretty much in keeping with how most sustained engineering teams operate. Too many details in the public realm make for a lot of misunderstanding.
..still, I'll continue the effort for my own edification, if nothing else.
Photo of Bruce

Bruce

  • 23 Posts
  • 1 Reply Like
Please do, I'd like to know what you find out since Acurite doesn't want to share even the most basic info.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
I will, but bear in mind that I can only describe what happens in my own forced-failure circumstances. It may not be completely relevant to anyone else's.

Like George said - we don't have any form of visibility into the device itself, so we're wholly dependent on proxy data such as what I'm gathering.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
..sorry for the delay, too many other things demanding my time, too...

The Ubuntu Apache reverse proxy is set up and my device shows green on the MyAcurite dashboard. I can see what the device sends, and how the service responds.

There are a couple of Apache configuration tweaks specific to this traffic that took some sorting, but it's all good, now. I'm happy to package up the .conf files and the configuration details if anyone wants it.

I'll respond tomorrow (it takes that long for my Access to drift far enough to fail) with my results, assuming it repro's again.
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
We now have repro and complete conversation data.

Unlike my last repro, my Access continued communicating with MyAcurite and WU AWS services after the failure condition began, so the failure behavior, at least for the time drift scenario, seems to be somewhat inconsistent (validating the apparent difficulty in nailing it down).

It seems pretty clear that the MyAcurite services are expressing dissatisfaction with the time sent by the Access, probably because of the response difference, but it's unclear whether that response affects the Access behavior.

So as not to clutter the thread, I'll leave my data and repro steps on my OneDrive share (link to follow).
Photo of Jim

Jim

  • 41 Posts
  • 4 Reply Likes
Data and summary repro instructions are at https://1drv.ms/f/s!ApzjxpUiJyMSiNVxvJtfK6F4OIx1Sg