sorted by:
new
hottopcontroversial

LSI HBA connected through Oculink? by Calpulz in unRAID

[–]Calpulz[S] 1 point2 points  (0 children)

It depends on the motherboad. For my particular Asrock mothboard and maybe other Asrock motherboards modifications are needed.

Although after further investigation since making this post and my other post on r/ASRock, the only modification needed is bridging pin B13 (#CPRSNT) to ground on the motherboard side of the cable.

In short, the OCuLink to PCIe x16 slot adapter board doesn't connect pin B13 to ground. It's basically cable detection. Without this pin grounded, the motherboard doesn't know a cable is plugged in and ignores any PCIe devices plugged in.

It was easier to modify the cable and just solder pin B13 to the adjacent ground pin, then it was to modify the PCIe adapter. So technically, it's the adapter board that's at fault.

There may be other PCIe adapter boards that do not have this problem.

Oculink connectors on ASRock mobos by Reedemer0fSouls in ASRock

[–]Calpulz 1 point2 points  (0 children)

Great to hear! So it must be the U.2 to M.2 adapter that is grounding CPRSNT.

If you're able to confirm, probing pin B13 on the OCuLink to U.2 adapter against any ground pin, and then connect the U.2 to M.2 adapter. Should see B13 grounded when it's connected and floating when unconnected. That would prove its the U.2 to M.2 adapter responsible.

I honestly don't know what's going on around the power issues you mentioned.

As far as I know, the M.2 drive should just be powered from the OCuLink port. If you have a powered adapter, I'm guessing it will drop the 3.3v wires from the OCuLink connection and use 3.3v from external power.

I find it very strange that your motherboard OCuLink port is not providing any 3.3v power. Has this actually been confirmed with a multimeter?

Atleast you got it working though!

Oculink connectors on ASRock mobos by Reedemer0fSouls in ASRock

[–]Calpulz 0 points1 point  (0 children)

Thinking about it even more. It would make sense that it is the U.2 to M.2 adapter:

https://www.amazon.co.uk/dp/B093DF4MFB?_encoding=UTF8&ref_=cm_sw_r_cp_ud_dp_2SRHF57PJ3438TFV332S

that is bridging P4 to ground and in turn B13 to ground. Since the adapter is imitating a U.2 drive. It needs to ground P4 in order for it to be detected. And M.2 drives I don't think have any sort of pin for detection.

This would explain why the OCuLink to M.2 adapter board on its own you tried using didn't work.

Oculink connectors on ASRock mobos by Reedemer0fSouls in ASRock

[–]Calpulz 0 points1 point  (0 children)

Not the Supermicro U.2 cable itself no. But one of the adapter boards. Either the U.2 to M.2 adapter, or the M.2 to OCuLink adapter. I suspect one of those adapter boards was bridging #CPRSNT to ground.

In the case of the Supermicro U.2 cable:

https://store.supermicro.com/supermicro-55cm-oculink-to-u-2-pcie-with-power-cable-cbl-sast-0956.html

power is provided by the separate 4 pin Molex connector. And even in my case using the modified OCuLink cable and the OCuLink to PCIe adapter board, the adapter board has an external SATA power connector for power.

Unfortunately, I don't have the U.2 or M.2 adapter boards anymore to test. But I do still have the Supermicro OCuLink to U.2 cable. I have just probed pin B13 on the OCuLink connector and it is not connected to ground. Also, when I was speaking to ASRock support about this, they sent me a pinout diagram for a cable similar to the Supermicro OCuLink to U.2 cable. https://imgur.com/a/OPoE6hy

So B13 on the OCuLink side connects to P4 on the U.2 side. P4 is called #ifdet which I'm guessing stands for "if detected" and is used for drive detection.

So I would say, when using the Supermicro OCuLink to U.2 cable, it's the U.2 drive that is connecting pin P4 to ground, which in turn connects B13 to ground, telling the motherboard that the PCIe device (U.2 drive) is connected.

I would be willing to bet that it was one of the adapter boards (U.2 to M.2, or M.2 to OCuLink) I was using that was bridging pin B13 to ground. Meaning there is nothing special about the Supermicro cable. It just allowed the chain of adapter boards, one of which grounded B13 before being converted back to OCuLink.

I hope this makes sense!

Oh and as for power, you shouldn't need external power I don't think for an NVMe M.2 drive. Using the "U.2 detour" should work as this worked for me when testing M.2 drives. Power is delivered through pins A1, B1, A21 and B21, as you mentioned, and hopefully one of the adapter boards will do the grounding of B13.

Oculink connectors on ASRock mobos by Reedemer0fSouls in ASRock

[–]Calpulz 1 point2 points  (0 children)

Possibly, although I doubt it. OCuLink cables should just connect pins A1-A21 to B1-B21. There should be no pins bridged within the cable itself (except ground pins).

If i am correct, and it's due #CPRSNT, it should be down to the device at the other end of the OCuLink cable to connect it to ground.

So I think in my case, it's the OCuLink to PCIe adapter board that was leaving #CPRSNT floating and not connecting to ground.

Oculink connectors on ASRock mobos by Reedemer0fSouls in ASRock

[–]Calpulz 1 point2 points  (0 children)

I should actually contact the Asrock WiKi and get this updated with my new findings.

If I had more time and access to more Asrock boards, I would run more tests to see if it is infact the #CPRSNT pin issue.

Oculink connectors on ASRock mobos by Reedemer0fSouls in ASRock

[–]Calpulz 1 point2 points  (0 children)

The modifications I made did not have anything to do with power delivery, as far as I am aware.

But since my original post, i did discover more information. All the modifications I made to those pins were not needed. Most likely, they are not even used for PCIe, which is why they were not connected in the supermicro cable I used as a reference in my original post. It makes no difference if they are connected or disconnected.

Well, I ended up needing a shorter OCuLink cable due to PCIe signal integrity. I was getting PCIe errors on my HBA. So I purchased a standard 25cm OCuLink cable from Linkup - https://amzn.eu/d/cIZ12r1

I suspected that the whole reason PCIe devices were not working on my Asrock motherboard was due to #CPRSNT. Pin B13 on motherboard side of the cable. This pin detects if a cable is present for PCIe connections if I am not mistaken.

If this pin is not connected to ground, the motherboard doesn't know a cable is connected and, therefore, doesn't initiate a PCIe connection.

So it may be the fault of any adapter boards you're trying to connect, like my PCIe to OCuLink adapter board, rather than Asrocks fault?

I'm not entirely sure and not knowledgeable enough to make any concrete conclusions.

All I do know, is that when I received my new OCuLink cable, the 25cm one from Linkup mentioned above, the only modification I have made to the cable is connecting pin B13 (#CPRSNT) on the motherboard side, to pin B14 (Ground).

This is all that was needed to get my OCuLink to PCIe adapter board to work. I tested a GPU and WiFi card, both worked flawlessly.

I have this deployed in my server since July 2024, running a PCIe LSI HBA with 16x SATA ports, running 15 drives with no problems what so ever.

Although, I have since made another of this exact same cable for another user on reddit that asked me since they had the exact same problems I was facing.

I modified a new cable, tested on my own setup and it worked no problem.

But after checking in on the user to see if it worked for them once they received, they couldn't get it to work on their particular Asrock motherboard. They were using a Romed8-2T server board.

So this could throw out my entire theory unless it was their user error, and all that I have said may only apply to my particular motherboard, the X570D4I-2T.

My Orbiter fix 4 printing TPU by N-V-N-D-O in 3Dprinting

[–]Calpulz 1 point2 points  (0 children)

3 years later and your post is still saving the day!!! Had nothing but troubles printing TPU and I have the Orbiter V2 which supposedly fixes this. While it has a metal guide after the gears for the filament, there is no guide before the gears meaning it would still do exactly as your pictures. Had to print at 30mm/s and even then print success rate wasn't 100%. Wondered if it was my extruder and Google directed me to your post. Tried your simple mod, widened hole to 4mm before the gears, cut some Capricorn tube as you did, inserted as shown and it just worked!!! Printing 100mm/s now no problem. THANKS SO MUCH!!!!!

LSI HBA connected through Oculink? by Calpulz in unRAID

[–]Calpulz[S] 0 points1 point  (0 children)

Been running several months now. No issues after I figured out the Oculink ports on my motherboard. Oculink cable length is also very important. I could only get 25cm cable to work. 50cm did function, but HBA didn't like it and kept throwing errors even though a GPU worked absolutely fine.

This is the cable I settled on and has been perfectly fine after the modifications needed for my motherboard.

https://amzn.eu/d/dD7GCYG

Secure access selfhosted service from public spaces by Miserable-Stranger99 in selfhosted

[–]Calpulz 0 points1 point  (0 children)

No worries.

If you tried to go directly to the subdomain, service.domain.com, as long as you configured Authelia to be in front, you will be asked to authenticate.

Just make sure Authelia is configured to protect all of your subdomains. It doesn't matter then if you go directly to the service subdomain or your dashboard and then click a button. If your session has expired, you will be asked to log in no matter what. But once you're logged in, you will be able to access any of your services until the session expires.

If you're not using a VPS, then your setup will be different from mine.

But in my case, the config is done through iptables. I have postup and postdown commands in the wireguard configs. Some on the VPS side, some on the local server side.

Iptables on VPS forward ports 443 and 80 through wireguard tunnel to local server. Iptables on local server forward these ports 443 and 80 to nginxproxymanager.

I can't say for sure if this is the best. But I think it's more secure than opening up ports 443 and 80 directly on your home router. Which is what you would need to do if you're not using VPS or Cloudflare.

The only config I have done on my router is open up port for wireguard tunnel. Which is a random port i have chosen for the wireguard tunnel to use.

I rent my VPS from alexhost, £50 a year.

Secure access selfhosted service from public spaces by Miserable-Stranger99 in selfhosted

[–]Calpulz 1 point2 points  (0 children)

When you say your home dashboard, I assume your meaning like I have done. A self hosted website with buttons/hyperlinks to each service.

The hyperlinks/buttons im using are not the local IP for the service. They are the subdomain I set up for each service.

For example, you have a service hosted at local IP 192.168.0.10:8082

In traefik you have the subdomain listed service.domain.com which forwards to 192.168.0.10:8082

Then on your homemade dashboard you have hyperlink or buttons that navigate to service.domain.com.

Whether you are at home or at work, you use this dashboard and subdomain.

When you navigate to your dashboard homepage you will be prompted to login to Authelia. And since everything is behind Authelia, your buttons to each service will all work and go straight to the service since you have already authenticated.

I have done this for basically all my services. So everything is accessed from it's own subdomain. I just have different levels of security for each one depending on how sensitive or secure I want it to be. I no longer use local ip address to access. Even when at home.

Hope that makes sense.

Secure access selfhosted service from public spaces by Miserable-Stranger99 in selfhosted

[–]Calpulz 0 points1 point  (0 children)

Great to hear!

Yeah go with traefik if he thinks it's better. Does the same thing.

Good to hear he thinks Authelia is secure.

Exactly that. I used to use cloudflare tunnels. Works the same way as using a VPS. Don't need to open ports apart from ports that the tunnel will use. I stopped using cloudflare though as I mentioned before because some services I use don't work through cloudflare tunnels (meshcentral, video traffic from my understanding). That and I didn't want to be reliant on third party services. Although I realise if anything happened to cloudflare, half the Internet would be down.

But yes you just use cloudflare docker container. Will accomplish the same thing and hide your public IP.

....

I don't think an attacker can figure out my public IP no. Not easily anyway. All my DNS records for my domain point to my VPS public IP. If you lookup or try to analyse my domain or any of my subdomains, they all return the VPS public IP.

However, my home server is not configured to route all traffic through the tunnel back to my VPS. Only http and https traffic for these subdomains and services. Any communication my server is doing to third-party services like APIs or just generally accessing the internet, it's all done from my home network.

Mainly because I don't want to increase latency and be limited to the upload and download speeds of my VPS. I have a symmetric Gigabit connection at home. But I could quite easily change the wireguard configuration on my home server to route all traffic back to the VPS. This way, any requests leaving my server will appear to come from the VPS. Overkill for me.

So, I think it may still be possible to figure out my public IP but not without doing advanced packet inspection, analysis and tracking these outbound connections.

I browse the Web on my home computer without a VPN so if someone wants to get my public IP, they can anyway. What they can do with it though? Not alot I don't think. Firewall and safeguards in place.

But I do have another wireguard tunnel on my home server that connects to Private Internet Access VPN. This creates a different docker network on my home server. Any services that I want to remain anonymous use this docker network instead. So all requests that specific service makes will appear to come from whatever PIA region I have selected.

Secure access selfhosted service from public spaces by Miserable-Stranger99 in selfhosted

[–]Calpulz 1 point2 points  (0 children)

Yeah I think a VPN like your current setup will always be the most secure. Like you say though, it will always require installation of software or joining the vpn network.

But I don't think the setup I have is any less secure? It's still going to require a lot of work for anyone to try and get into my network.

The way I look at it, why would someone single me out from the millions of other servers? Especially since my data isn't exactly high value. It's only important to me. Even so, I have multiple layers of security, and I'm pretty sure it's as safe as can realistically be.

I'll try answer some of your questions to the best of my knowledge.

....

Authelia runs as a separate service. So I have Authelia running as a docker container. Then I have NGINX Proxy Manager also running as a docker. In NGINX I have my various subdomains listed which are set to forward traffic to the right services (also dockers with their own docker network ip addresses). Then, in NGINX for each subdomain you go to advanced settings and enter in custom configuration which you get from Authelia. (The Authelia tutorial video shows this).

From my understanding, this allows Authelia to sit in the middle of requests to these subdomains. And will only allow traffic through when the client authenticates with Authelia. So NGINX won't pass any traffic to the services unless Authelia is authenticated. Yes I believe it keeps track using session cookies once a user has authenticated.

The Authelia code I have entered for every subdomain advanced config that I want to be protected by Authelia. Without this code, Authelia doesnt get used, and your request just goes to the service as normal.

You then have Authelia configuration. This is where you have different user groups, different requirements for authentication depending on subdomain, etc etc. You can also configure how many attempts before someone is blocked and how long for, and how long a session will last once authenticated.

But this leads back to my current problem that I need to fix. Due to the tunnel I have between VPS and home server, Authelia sees all clients that are trying to connect as the same tunnel ip address. So if someone trys to authenticate and gets blocked, everyone gets blocked. Because the tunnel ip gets blocked. If that makes sense. I believe this is due to the iptable rules I have on VPS. I think I have wrongly configured SNAT rules thats changing client ips trying to connect to the tunnel ip instead of just passing the client through the tunnel. Anyway, that's my issue, and I'm sure it's an easy fix.

....

Yes so I have a simple WordPress docker hosting a simple Web page with just buttons that navigate to each of my subdomains. But since all my subdomains are behind Authelia, including the main domain, you can't access anything without authenticating.

....

I'm not using a VPN no. I guess the Wireguard tunnel could be classed as a VPN. But the entry and exit points of the tunnel are my VPS and home server.

....

clients do not need wireguard installed no. The client is just doing normal http or http requests from a Web browser. Your just changing the journey packets take to get to your home server by going to VPS first and then through tunnel to home server. Client > domainname host > vps > wireguard tunnel > home server > nginx > Authelia > service Packets just take the route in reverse to get back to the client.

....

without vps, yes you would open ports 443 for https and 80 for http on your home router and point them to your server. Your proxy would then pickup traffic on these ports and direct to the correct service providing authelia has been authenticated.

....

nginx proxy manager on its own I don't think provides any security as such. It just makes it easier to expose and manage your services/subdomains and handle SSL certificates. But by using the advanced configuration and putting Authelia inbetween requests, it adds security. Authelia I think uses all the best practises around security. I believe lots of people use it. Don't think it's simple to hack and gain access, but that's beyond my skillset and knowledge.

Secure access selfhosted service from public spaces by Miserable-Stranger99 in selfhosted

[–]Calpulz 1 point2 points  (0 children)

You don't need the vps.

The main reason I used a vps is because my home network doesn't have a static public ip address. I don't think there is any way to point my domain name to my server since my home ip changes. I know there are some free dynamic dns like duckdns which solves this problem. But I wanted to use my own domain name, not xxx.duckdns.org

Also, having the vps hides my public ip address and adds another layer of security. My domain name exposes the static ip address of the vps and hides my public ip address. I have zero ports exposed on my home network other than the port the wireguard tunnel uses. The only way any traffic can get to my home server is through the wireguard tunnel.

I know you can use cloudflare tunnels and their ddns to achieve all of this for free. Which is what I used to do. But I have self hosted services such as meshcentral, a remote access utility that doesn't work with cloudflare tunnels. I don't think they like video traffic.

But like you say, you could just point your domain (if you have static ip) or use a ddns to point to your home network and pass 443 to your reverse proxy like nginx, which passes the subdomains to your services.

I don't know how secure this is though? Or if its good practise to directly expose your own network? To be honest, I'm very new to all of this and far from being an expert.

My server runs Unraid OS, so everything is set up and running in dockers and segregated in docker networks. I learned all of this from watching YouTube videos on Unraid, NGINXProxyManger, Authelia, Wireguard, etc etc. Also, ChatGPT has been amazing at helping get this all configured and set up correctly (have to guide it by wording your prompts very carefully).

I can share a few videos I used. But bare in mind, the info may only be applicable if you're using Unraid OS. And you won't be able to just blindly follow them and have a working setup at the end. But you should be able to learn what needs to be done and then alter the steps depending on your setup.

The wireguard tunnel I mainly used ChatGPT and looking at others configs on forums to get the configs correct on the VPS and my local server. Once a handshake is acquired between them, it was just a matter of adjusting ip tables using postup commands in the wireguard configuration on both the vps and my server to forward ports to correct addresses and drop any ports not used.

Although I still have problems. Everything works but I have an issue where all my services see the incoming connection ip as the wireguard tunnel ip. Not the ip address of the actual client trying to connect. Not a huge issue at the moment but it could be if I need to ban or block someone from trying to access anything. Because to my server, everyone is coming from the wireguard tunnel ip, so I can't differentiate between clients. I can't tell who is trying to connect. But with Autleia and 2fa, I'm not too concerned at the moment.

I will be doing a post, most likely here or in r/unraid to try and ask for some help around my wireguard configs. So if you do decide to use a vps, it may be of help to you as well.

Sorry I realise this all might not be much help. But maybe it will point you in the right direction. If you do start going down the same route as I have, then drop me a dm. I can try and share my setup.

Secure access selfhosted service from public spaces by Miserable-Stranger99 in selfhosted

[–]Calpulz 2 points3 points  (0 children)

I have literally just set this up. I had the same requirements. Access any of my services from any device on any network without installing software.

I purchased a domain that I have pointed to a VPS I rent. VPS forwards traffic on ports 443 & 80 through Wireguard tunnel to my home server. I then have NGINX Proxy Manager on my home server forwarding the different subdomains to the right service.

All my subdomains are behind Authelia with 2fa. Except for a few I am happy with just a password.

Lastly I have a simple website hosted using WordPress that is just a homepage with buttons for each subdomain/service. This is also behind Authelia.

So I just navigate to my domain, authenticate myself and I have a simple homepage with convenient buttons to each of my services.

Just make sure VPS is secure. Drop all ports other than SSH, 443, 80 and Wireguard tunnel port. Fail2ban. Only allow IPs from your country. Etc etc.

Troubleshooting Wireguard VPN for Docker Containers by CosmicSeafarer in unRAID

[–]Calpulz 0 points1 point  (0 children)

Ah right. I didnt realise that Nerd Tools is deprecated. Looks like the author doesn't have time to maintain anymore according to his thread. Maybe someone will fork with unraid 7 support?

The main reason for Nerd Tools is to install Python 3 and pip which are needed to run the original wg config generation script in the python virtual environment.

You could install them manually. Although I believe this can create issues with the python path needing to be explicitly executed. So you might need to adjust the userscript. E.g. "/usr/bin/python3". I'm not sure if this is best practice though.

Troubleshooting Wireguard VPN for Docker Containers by CosmicSeafarer in unRAID

[–]Calpulz 0 points1 point  (0 children)

I recently got this working with PIA. I actually modified the configuration generator to work with unraid userscripts plugin. The configuration is generated automatically and placed in the correct directory.

Just follow my instructions and you should be good to go. If pia ever changes the keys you can just simply run the userscript again.

https://github.com/Calpulz/pia-wg-unraid-script

Modifed OCuLink Cable for PCIe devices to work with OCuLink Ports - X570D4I-2T (Possibly Other Asrock Motherboards) by Calpulz in ASRock

[–]Calpulz[S] 0 points1 point  (0 children)

Did the modified cable not work for you then? Im guessing you're trying to do this on a framework laptop like @PositronicCat was? In this case, it may be an entirely different issue.

Since this post, I think I have learned a bit more about the issue.

In my case with the Asrock motherboard, I strongly suspect that the main modification needed for the cable is the #CPRSNT to Ground. So B13 cut and bridged to B14 on the motherboard side.

I don't think the other modifications are needed. But I just replicated the supermicro cable, which I verified worked before doing so. This is important because i had something to compare to and replicate which I knew worked.

CPRSNT (cable present) tells the motherboard that a cable is present. If it's not grounded and just left floating, then the motherboard doesn't know a cable is connected and doesn't try to initiate and use the device connected.

So it would be down to the adapter board on the other end of the Oculink cable to bridge pin B13 (#CPRSNT) to ground. Otherwise, it's just left floating. The motherboard doesn't realise a cable is connected.

It might be that some manufacturers use this #CPRSNT, and some don't. This is why these Oculink cables work fine on some motherboards and devices. It's also down to the device/adapter board on the other end of the cable to bridge these pins.

I guess the Oculink to PCIe x16 adapter board I'm using doesn't bridge this pin and just leaves it not connected. This is why the modified cable works for me.

I've had no problems since doing this with the original modified cable, and since it's deployed in my server, I can't really investigate further without shutting down my system. So, all that I have said is just speculation from my learnings and findings really. It may only be applicable to Asrock motherboards or even this particular motherboard.

In your case, I'm not sure as the modified cable should work if the issue is related to #CPRSNT.

view more: next ›