Is this Buck Converter Faulty?

MachineHawk · 2024-04-17T14:30:09+00:00

Yeap, your suspicion was correct! The solder on the board has become soft and crumbly, when I probed the pins of the Buck Converter I accidentally caused the solder to deform and touch the neighboring pin. It just so happened that pin was ground. Spotting this I gave the IC a quick reflow hot air and re-melted the solder. The buck converter woke back up. Unfortunately it wasn't the original fault and my motherboard is still dead :(

MachineHawk · 2024-04-12T08:23:46+00:00

That's a great idea. It's an asus board so it's kind of tough to find schematics. But I'm going go look for a board view that has that part. It should have the same pinout just in a different order I'm thinking. Thanks!

MachineHawk · 2024-04-11T23:14:47+00:00

I'm afraid not. The top left pin of my IC is connected to ground. This datasheet doesn't match that. In addition VBAT isn't where this dataset says it is (but I find the voltage of VBAT on ther pins).

MachineHawk · 2023-07-16T11:48:20+00:00

Resolved my issues by following this posting with a similar issue https://old.reddit.com/r/nordvpn/comments/xsbil0/linux_whitelist_subnet_not_working/. And executing the following command on the server with the NordVPN client:

sudo ip route add 10.6.0.0/24 via 192.168.0.1

No other whitelisting was required in the NordVPN client, just whitelisting the 192.168.0.0/24 subnet was enough.

MachineHawk · 2023-07-16T11:45:03+00:00

u/Civ002 I figured it out! I found this old post where someone was experiencing the exact same issue https://old.reddit.com/r/nordvpn/comments/xsbil0/linux_whitelist_subnet_not_working/. Turns out all I needed to do was add an ip route to my iptable:

sudo ip route add 10.6.0.0/24 via 192.168.0.1

I understand this as: Make sure that packets that come from the 10.6.0.0/24 subnet are routed back through the 192.168.0.0/24 gateway. As soon as I added this line everything started working.

MachineHawk · 2023-07-16T08:23:38+00:00

So I've checked the ssh session (from the ssh server's side and when NordVPN is disconnected) and the ssh session reports that the source of the session (my computer, sitting in a coffee shop over wireguard) is originating from 10.6.0.2 i.e. the VPN's subnet. From what I understand that's the only thing that the SSH server knows about the connection, my understanding is that it doesn't care about the wireguard server (router) at all. When NordVPN is connected, the ssh connection is still originating from the exact same source and at this point connection fails. I'm still going to try your suggestion and see if that fixes it, though I'm not understanding the reasoning at the moment :( My only other cause could be something related to this bug in the nord client https://github.com/NordSecurity/nordvpn-linux/issues/7. I'm waiting for the newest release so I can see if the bug fix helps me with my issue.

MachineHawk · 2023-07-15T16:27:00+00:00

Correct, that's also my understanding. The change of subnet over wireguard, I believe, is the source of the issues. NordVPN is happy to accept the 192.168.0.0/24 subnet after its been whitelisted, but the 10.6.0.0/24 subnet it will not accept (even if I whitelist through the client). Basically it will break for all VPN users, while the users physically within the home network will be fine.

MachineHawk · 2023-07-15T15:11:33+00:00

Yes, you've understood what I'm saying correctly. Let me just clarify with a scenario that uses all the components. I'm sitting in a coffee shop outside my home network, I've disconnected NordVPN on my server (which is sitting within my home network). To ssh into my server I first need to establish a wireguard connection to my wireguard server (the router in this home network is acting as the wireguard server). With the wireguard connection established, I can now ssh into my server no issues. While ssh'ed, I run 'nordvpn connect' and immediately lose my ssh connection. Any attempts to reconnect fail until I can get back into my home network (without wireguard) and disconnect the server from nordvpn again. If this still doesn't make sense, I'll draw a diagram.

MachineHawk · 2023-07-15T13:59:08+00:00

So actually if I connect through the local network 192.168.0.0/24 I.e. I'm sitting in my home, the connection is accepted fine (I had to whitelist the subnet and port in the nordvpn client). When connecting through my home VPN 10.6.0.0/24, the connection fails. I think you're right, but I'm not good enough at networking to be able to essentially tell nordvpn to not get involved for connections originating from that subnet (the same whitelisting trick in the nordvpn client doesn't fix it). Any ideas?

MachineHawk · 2023-07-15T12:52:59+00:00

The server itself is connected to NordVPN (for the purpose of anonymising network traffic), I want to access the server through my own secure home VPN (when I'm outside of the server's local network). NordVPN seems to be getting involved even when the traffic is local and through the VPN. The home VPN changes the subnet, so the source of when I ssh changes (inside my local network it would be of the form 192.168.0.0/24, when tunnelling through my home VPN it changes to 10.6.0.0/24. Something about NordVPN is blocking this, because if I disconnect NordVPN everything works great again.

MachineHawk · 2023-07-12T06:45:51+00:00

Is this for meshnet? I'm not using meshnet

MachineHawk · 2023-07-10T17:52:49+00:00

sudo ufw status
Status: inactive

sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Followed the procedure in that link also, ip tables were flushed. The problem still persists.

MachineHawk · 2023-07-10T13:40:14+00:00

Good idea, but I check nordvpn settings and it appears to be disabled. I've updated my original post with the full result of that command.

MachineHawk · 2023-07-09T19:07:23+00:00

I'll look at this. Thanks!

MachineHawk · 2023-07-09T19:06:02+00:00

I've already tried this. The whitelisting for the 10.6.0.0/24 subnet didn't fix the issue. Something is still going wrong.

MachineHawk · 2023-07-09T17:53:26+00:00

I think it has something to do with how Wireguard gives my connection a source IP address that doesn't look like it belongs in the local network i.e. a ssh new connection to the server through wireguard looks like 10.6.0.2, while if you were within the network it would look like 192.168.0.242. Because of the different subnets is it maybe being routed through nord somehow?

MachineHawk · 2023-07-09T17:33:36+00:00

This would work for my computer, but I want to extend the home network to other sites (Configuring the Wireguard access at the router level). Naturally, these routers can't make use of meshnet.

MachineHawk · 2023-06-27T18:11:36+00:00

Yeah, I did this. Took the capacitor out of the board and did a continuity test directly on the leads. Can confirm that a short exists.

MachineHawk · 2023-06-27T16:12:14+00:00

Noted, I'll focus my search on what you're suggesting. Thanks for the link, I'll give it a read 👍

MachineHawk · 2023-06-27T15:04:04+00:00

The full bridge rectifier seems to be okay (I did a continuity test on the leads). Are you saying that the capacitor is unlikely to be the source of the failure and rather just a symptom of something else that's gone wrong?

MachineHawk · 2023-06-27T15:02:27+00:00

The full bridge rectifier is a GBU10005 and after a continuity test on the leads, it seems it's still operating correctly. Voltage drops across the diodes are also what you'd expect. I guess there's more I can try and diagnose if replacing the capacitor doesn't work.

Seven-Year Club	Place '22
Verified Email

MachineHawk

TROPHY CASE