In todays problem I have had a UCK-G2 auto update. It had gotten itself stuck on “Getting Ready”. This caused the network app was unresponsive.
So the basic steps I used to get the device back on track. Open the settings page, Enable SSH and get the LAN IP.
Connect to the UCK through SSH ssh root@[uck ip] with the password defined in the admin console.
ls /usr/lib/unifi/data/backup and take note of the latest version .unf there. 6.2.26.unf will be used in the example. once you have the filename SCP the backup out to your computer. You might choose to download more then one.
When the device reboots SSH back in and run. ubnt-systool reset2defaults
Once the device is back (again) https to it and configure it for the cloud. It will do its update again to the latest version. Network might take 5-10 minutes to come online, once its up and running with the default configuration. Upload the backup you downloaded at the beginning.
Because the device uses ‘overlayfs’. If the device gets the already installed version uploaded again. it does not seem to trigger a filesystem rebuild. No matter how many times you uninstall and reinstall UniFi and MongoDB. There will always be a ‘stats db’ present and it forces the database to be perpetually re initialized. Installing a previous version will downgrade the device. but running factory defaults Seems to reinitialize the diff filesystem and gets it going again from a known point.
Had two 11th Generation Intel CPU’s come past my desk in the last week. One was a Z490 and the other a Z590. Both were Gigabyte Aorus Boards. CLOCK_WATCHDOG_TIMEOUT seems to be reproducible with nearly every execution of UserBenchmark.
When running UserBenchmark they both would get to Core 2 of the CPU tests, freeze and throw this error. Once I had them throw a WHEA_UNCORRECTABLE_ERROR. That time the faulting module was GenuineIntel.sys.
Anyway, in BIOS under the CPU optimisations disabling “Adaptive Speed Boost” corrects this error. There must be a issue with how GigaByte has implemented this function. There is not much info around the internet about CLOCK_WATCHDOG_TIMEOUT, the general push seems to be to install some sort of device driver scam ware.
Ive been having issues with the MYOB API on Premier 2021 Server Edition.
Ever since 2021.2 I have been unable to upgrade the MYOB API service with the server installer. The API installer would ask the location, and whether to self sign the certificate that protects the API endpoint. Uninstalling the API service will also appear to proceed then fails.
As far as the install logging goes, none of it was helpful. And the MYOB help focuses solely on .NET 4.5 and updates.
To fix this issue. you will need a certificate bundle in PFX format. I did not have to enter the password for the bundle at all. Which is a indication the software does not attempt to install it.
A PFX bundle has to contain a public and private key. These are used to secure the API endpoint from an adversary using a packet sniffer. PFX bundles from unknown sources should always be considered dangerous, and should never be imported to your certificate store.
With the PFX bundle in the filesystem of your server, open the API installation wizard, found in “C:\Program Files (x86)\MYOB\AccountRight\API_Installer”. When the installer asks whether to use a self signed, or user provided certificate. Choose user provided and select the certificate bundle filename. When the installer fails, you will be able to uninstall the MYOB API application with add/remove programs. Once the MYOB API is completely removed. When you rerun the installer from the location above. This time choose self-signed and the latest API service should install correctly.
Update for 2022.1
The MYOB Api Service Must be stopped in the Services Controller. ‘Services.msc’
This morning my users woke up to Office 365 had updated. One of these updates seems to cripple Outlook 365. The issue that has been observed is that when you open an email the body either blank, or shows a single line. depending on the size of the window.
To roll back to a previous version, using InTune management login to https://manage.microsoft.com/ and open the App deployment policy for your Office 365 suite.
Set Remove other versions to Yes, Version to install to Specific, Specific Version to 2103-13901.20400
Click Review and Save.
Any clients that were deployed with InTune will reinstall office once all the apps have been closed.
A client wont downgrade while office apps are open. To force a downgrade ask the users to ‘sync’ in Settings\Accounts\Access Work or School, Select the configured work location and click Info then Sync.
Trigger a Sync remotely, but unless the office apps are closed the downgrade may not complete immediately.
After the downgrade users will see a splash screen that says, please wait while we update office.
A user can after the InTune sync elect to downgrade office with the Update Now button, which will deploy the administrators chosen update.
The Kindle DX is very much a legacy device. Amazon don’t have much information on it available online. Most of the software update and help guides no longer exist. I also found plenty of resources on identifying your kindle, but there were no downloads available.
So the Kindle DX, it has no wifi, but has the world-wide 3G network (whisper net). The problem is that the Root Certificates in the device have expired. So there is no SSL, which means no Registration/Deregistration. The Kindle store is browsable, I think its because the site is HTTP. but HTTPS for downloads.
Back to getting your Kindle working. There are a few guides out there, but no links to downloads. the download I found on a 3rd party site was not for my DX.
OK. to get your serial open settings, Home -> Menu -> Settings Under device info you will find your serial number. The current software version of your Kindle will be at the bottom.
Check your Software version
If your software version is not 2.5.8. Download the “Download this file” link corresponding to your Kindle serial number. If you are already on this version, goto step 2.
Using the USB on your computer. Copy it to the ‘root’ of the Kindle’s USB disk.
While still in the settings page, press menu then Update Kindle.
Update the Kindle Services
If your software version is not 2.5.8. Download the “Kindle Services Update” link corresponding to your serial number.
Using the USB on your computer. Copy it to the ‘root’ of the Kindle’s USB disk.
While still in the settings page, press menu then Update Kindle.
If for any reason the Kindle ‘disconnects’ from your computer while copying the updates on, try another computer or cable. and if ‘update this kindle’ does not appear active in the menu, choose restart instead. The Kindle usually triggers all available updates on reboot.
If the kindle was not unregistered correctly before a factory reset it will come to live with the previous account. you can at this point unregister and reregister.
Windows 10 power policies have some strange behaviours when applied over time. Negative issues seem to arise between SCCM, GPOL, and MDM deployments. Then the issues are exasperated by Windows Update when Windows 10 performs a major update. I have also heard of home users losing control of their power sleep settings.
In the work environment when some computers are upgraded from Windows 10 1809 to 1909 – 2004 using windows update, or the update assistant. The strange power related settings happened when they became MDM aware. Our power policy here is 5 minutes screen off, 10 minutes sleep when on battery. Then 60 minutes screen off and 65 minutes sleep when on AC. This is because of the needs of the organisation. All our computers are mobile and we do not want to have a machine on in a bag to cook itself.
In our domain it has been through all the various architectures, from way back when NT 4.0 was new. It was upgraded all the way through to Windows Server 2016. Hybrid joined to Office 365 and Azure AD.
All the power settings have been unlinked from Group Policy, and are only provided via Intune. Through a ORM-URI custom policy. But for some computers, not all. The AC sleep is 7 minutes 30 seconds. Even though the user dashboards appear to display the correct timeouts. If the computer is completely reset using a base Windows 10 1909 or 2004 build. Then Joined to the domain and enrolled in MDM all the power settings function as expected.
All the different user dashboards. Whether in control panel, or the new settings menu, registry, InTune or Group Policy have no effect when changing the windows power policy. The settings dashboards appear to display the chosen timeout. but in practice the computer is stuck to sleeping between one to seven minutes. The only solution which works persistently appears to be a reinstall of Windows.
Eufy wireless cameras consist of a NVR called the home base and the cameras. The home base is marketed as WiFi 2.4 and sub GHz wireless.
The cameras appear autonomous and use the sub GHz for command and control. When a camera performs a recording. The 2.4GHz wifi will startup and the home base will store the recording on the MMC/SD card plugged into the home base.
The DoS attack works the same way as a normal WiFi deauthentication attack. The MAC of all the devices is readily available. The SSID is hidden but still discoverable. And the said appears to be generated in the same way as a home router.
The way the attack is most successful. When the camera wakes run airdump-ng. Then use airreplay-ng to deauthenticate against the bssid. When the camera reconnects it will display the ssid of the base station.
When you get the ssid of the base station. Start up airbase-ng and start an AP spoofing the ssid of the access point and turn up the power. Script some deauthentication runs on the base stations bssid. When the camera reconnects it will begin dumping all its footage out addresses to the wrong bssid.
Most of the footage is discarded in this process.
I would expect this attack would work on most WiFi based cameras. Eufy cameras are also susceptible to deauthentication on the broadcast address, ff:ff:ff:ff:ff:ff.
The UniFi range of products includes switches, access points and routers. I have recently come across a interesting quirk with how the wireless repeater mode works.
As you may or may not be aware, you can extend your network footprint automatically with UniFi access points. They will when enabled automatically peer access points together. In an effort to establish a virtual cable and keep the network segment connected. I have recently observed two instances with my own UniFi network that could be a show stopper.
When a access point device is installed in a location, powered on and connected to the network. While it is not adopted to a controller (the process of exchanging authentication information). It will wait in limbo for a controller to arrive, and adopt it. The problem with this is, if the access point is connected to the private network its possible to adopt it wirelessly. Adopting the access point is a straightforward process. Bring an access point near, and click adopt. This will provide connectivity to everything on the access points ethernet socket.
When a access point is removed it is possible to use it to gain access to the network. When it returns within range it will automatically change into wireless uplink mode. And provide connectivity to everything on the access points ethernet socket.
So, when #2 occurs. If a access point is stolen. UniFi has a mechanism to deal with revoking permissions. However if you forget the device while it is in a disconnected state. The access point will not be ‘reset to factory’ automatically. It will continue to perform its meshing duties all the while maintaining ‘managed by other’ state.
Detecting such an attack like #1 would be your devices will appear “managed by other”. Detecting such an attack like #2 would be to have rogue AP’s detection enabled. Because this does trigger the Rogue AP prompt. In your UniFi console. Only while the device is connected will it say managed by other.
In both these scenarios. There is full ethernet transit enabled. and the entire network is functioning normal.
What mitigations I would like to see from Ubiquiti?
Disable the radio after a period of time waiting to be adopted. power cycling it should reset the timer on the wireless adoption sequence.
Incorporate a mechanism for an administrator to ‘roll’ (automatically or manually). The meshing keys on the access points. this way the credential caching issue should not persist forever.
Configuring the gateway parameters in console.thethingsnetwork.org is not as important as it appears. Here in Australia the ‘thethings.meshed.com.au’ appears to apply arbitrary filtering on our gateways. It is the only router in this region (AU_915). so from time to time when this filtering is an issue we will swap to another router. We also don’t use thethings.meshed.com.au for applications much. because integrations are not as configurable, and we have to use a ‘special’ dashboard.
So the issue here is the “frequency plan” setting seems to only be for statistics. As is the “Router” configuration. It can be set to anything, it does not appear to mean much. When set to anything you can forward packets in anywhere. and by the Things Networks own documentation. A unregistered gateway will still work. but the packets it received will be stamped untrusted.
So back to the problem. When you use ttn.opennetworkinfrastructure.org as your router. All downlink packets are enqueued against the channel plan for EU_868. When this happens the gateways here in Australia to discards the transmission. Even though the gateways frequency plan is defined correctly in the dashboard. This lets me to believe that value is only for statistics.
The only way to overcome this problem appears to use the correct router for the region. Which for AU_915 is the infrastructure hosted by Meshed. And I guess we will have to put up with the arbitrary filtering.
Working OTAA compatible TTN Routers
Make sure the gateway has min/max TX freq set. Does work-around meshed for OTAA
So ensure you set your router DNS entry to one that corresponds to the table above. Otherwise the things network appears to tell the gateway to TX on an out-of-band channel. and a misconfiguration on the end of the operator could mean transmitting on licensed spectrum. and potentially prosecution. Despite every other effort being made to be compliant.
I expect the only reason why the US router works is because the downlink channels match both AU_915 and US_915