Replacing My Tablet’s Battery

Good Morning from my Robotics Lab! This is Shadow8472 with a side project of the week. Let’s get started!

I’ve had my Samsung Galaxy Tab A 10.1 (2016) since before my new Android device lockout. It’s held out for the most part, but several months ago, it developed a problem where it would lose power while plugging it in or unplugging it. At worst, it would pulse its battery charging picture until eventually moving to a charge meter. The problem grew worse over time, and new power cables didn’t solve the problem. The parts to replace the USB connector and battery were out of my price range. One day, I even made a “Goodbye” backup.

I don’t know how I found this, but a little pressure on the back let my tablet boot again. Sometimes, the battery would register as empty and shut down once Android loaded – even when connected to wall power and the battery showed up as 100% again a moment later.

I zeroed in on the left-middle (viewed from the front in portrait mode) as the place to press. As I got used to this arrangement, I had to keep pressing harder. Eventually, I pried the back cover off with an orange peeler. The battery has two sections, and I’d been pressing on the bottom-outside corner of the upper pack. The battery itself did not appear bloated or otherwise damaged, and continued to work applying pressure directly to the battery pack (DUMB IDEA, by the way; DO NOT TRY) and pressing the tiny, exposed power button.

As it turns out, Android sees the battery as a critical part (unlike laptops), and I don’t have the tools or know-how to simulate one, but some kind of wall-only power mode would have been a courteous gesture, even if it were buried deep within the firmware.

Through another month or two of observations, I learned how the battery failed when I stopped pressing too soon after booting or if the tablet started drawing too much power, such as when turning on when when plugging it in while off. With this, I narrowed my diagnostic to just the battery pack, which I figured was worth trying to replace. Reviews of different compatible replacement batteries said not to expect more than a year out of it – even genuine ones. My guess is that it’s all old stock, changes pushed to the operating system intended to slow battery aging, or a combination thereof.

Replacing the battery once it arrived was only a matter of formality. The screwdriver that came with the kit was worthless, but I had access to a better one. I expected little of the battery, and I got little of it. It’s a step or two above junk, but it’s worlds better than the old one. I just need to be a bit more careful about how I handle my tablet from now on. If it only lasts another year or less, my plan is to replace it entirely.

Final Question

I can’t find any information online about applying pressure to batteries. Do you have any insights? If so, I look forward to hearing from you in the comments below or on my Socials.

Responsibility of the Network

Good Morning from my Robotics Lab! This is Shadow_8472, and today I have a doozy of a network week to cover. Let’s get started!

Meet the Computers

  • Cerberus – the main star today. It is our new hardware firewall running OPNsense
  • Red Router – a tp-link gaming Wi-Fi router fancied up beyond what it should have been
  • LAB – my homelab with a few servers
  • LAN – everything else connected via Wi-Fi or Ethernet

Network Implosion

It all started with revisiting a .lan domain. Cerberus’ extensive webUI left me with the hunch I’d need one machine in charge of DHCP assigning dynamic IP addresses. Red Router’s “operation mode” to work as an access point was hidden in literally the last menu to click through.

It was afternoon and no one would be using the network for the 30 seconds to 5 minutes I estimated switching the LAB and LAN Ethernet cables from Red Router over to Cerberus would take. Nope. No traffic made it through. DHCP mis-configuration? Cue a slow back and forth, bopping a setting from a workstation and trying a different physical configuration. Eventually, Cerberus ended up on my desk with Red Router talking directly to our ISP’s gateway/modem.

Order of events is a bit fuzzy from here, but when the Wi-Fi stopped working, I was without a good access to online answers. I worked the problem into the night. Around 1:00 AM, I knew I had done too much for a clean reversion. For two hours, I worked in loops hoping to spot something different. So much waiting! Cerberus would behave on my desk, then fail when redeployed. Worse: when I re-connected all the wires to Red Router, it started dancing between 192.168.0.1 and 192.168.1.1 every 45 seconds or so. I configured its IP manually, but gave up on Internet by morning at 3:00 AM, preparing to concede to my father’s suggestion earlier about hiring a professional to untangle my mess.

The Next Day

Newtork Loop. In my brain fog, I had Red Router talking to itself on a cable leftover from removing Cerberus for the night. With the house to myself for several hours, I alternated between bursts of intense diagnostics and mental processing. Somewhere in there, I rebooted the ISP’s modem.

Around noon, I realized the extra ports on Cerberus aren’t a switch as is Red Router’s default configuration, but were following firewall rules – which explained its behavior the previous day when I tried a computer from LAB without anything in-between. At around 3 PM, I got a Discord notification while mentally checked out, letting me know the network was back on.

6 PM on the second day: I situated my workstation in Cerberus’ LAN port and a Raspberry Pi in one I named LAN2. I’d previously copied firewall rules from LAN to LAN2 and LAB, but to no obvious effect – until I had the two computers ping each other. LAN2 failed as expected, but LAN’s ping was returned. I corrected the interfaces’ rules to allow them to reach out, and that was it.

Fallout

Without going into too much detail, a subnet shift like this is a major undertaking for networks with static IP servers on them. Not only do the network and computers need to be adjusted, but all traces of the old subnet need to be corrected. NFS clients needed to be told where the server was now, and the NFS server shares needed to be updated about what IP’s were allowed to mount them. I also still have Bitwarden to clients to update at my leisure.

Takeaway

OPNsense is a heavy weight in terms of configuration options. It has a learning curve compared to products simple enough to for Grandma and Grandpa to use. I may have solved my own emergency, but it may be wise to get someone looking at it professionally anyway to grade my work and give me some pointers on rootless Podman mounting NFS shares, or other long-term places where I’ve gotten stuck.

Final Question

I admit: networking is more fun than I gave it credit for before I knew basically anything. I still find it a bit taxing to mentally reach around my mental map, but I manage. How do you visualize networks?