• 2 Posts
  • 6 Comments
Joined 1Y ago
cake
Cake day: Jun 15, 2023

help-circle
rss

I don’t think I quite explained the situation well enough: my server only has 1 ethernet port (same as my PC), otherwise I wouldn’t have bothered with vlans (well, I would still have bothered, since my house still only has one “backbone” cable running through it, but I would have configured it on the switches only).

Anyway… a few of the things you say/imply go against my understanding of networking, so one of us would better go back RTFM as you suggest :) (just kidding - most probably I just don’t understand what you mean)


So the request goes trough but the replies are discarded ? That could actually be it!

I think there was an option to allow that… I’ll search it and give it a try. Thanks!


[SOLVED] Weird (to me) networking issue - can you help?
I have two subnets and am experiencing some pretty weird (to me) behaviour - could you help me understand what's going on? ---- Scenario 1 ``` PC: 192.168.11.101/24 Server: 192.168.10.102/24, 192.168.11.102/24 ``` From my PC I can connect to .11.102, but not to .10.102: ```bash ping -c 10 192.168.11.102 # works fine ping -c 10 192.168.10.102 # 100% packet loss ``` ---- Scenario 2 Now, if I disable .11.102 on the server (`ip link set <dev> down`) so that it only has an ip on the .10 subnet, the previously failing ping works fine. ``` PC: 192.168.11.101/24 Server: 192.168.10.102/24 ``` From my PC: ```bash ping -c 10 192.168.10.102 # now works fine ``` This is baffling to me... any idea why it might be? ---- Here's some additional information: - The two subnets are on different vlans (.10/24 is untagged and .11/24 is tagged 11). - The PC and Server are connected to the same managed switch, which however does nothing "strange" (it just leaves tags as they are on all ports). - The router is connected to the aformentioned switch and set to forward packets between the two subnets (I'm pretty sure how I've configured it so, plus IIUC the second scenario ping wouldn't work without forwarding). - The router also has the same vlan setup, and I can ping both .10.1 and .11.1 with no issue in both scenarios 1 and 2. - In case it may matter, machine 1 has the following routes, setup by networkmanager from dhcp: ``` default via 192.168.11.1 dev eth1 proto dhcp src 192.168.11.101 metric 410 192.168.11.0/24 dev eth1 proto kernel scope link src 192.168.11.101 metric 410 ``` - In case it may matter, Machine 2 uses systemd-networkd and the routes generated from DHCP are slightly different (after dropping the .11.102 address for scenario 2, of course the relevant routes disappear): ``` default via 192.168.10.1 dev eth0 proto dhcp src 192.168.10.102 metric 100 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.102 metric 100 192.168.10.1 dev eth0 proto dhcp scope link src 192.168.10.102 metric 100 default via 192.168.11.1 dev eth1 proto dhcp src 192.168.11.102 metric 101 192.168.11.0/24 dev eth1 proto kernel scope link src 192.168.11.102 metric 101 192.168.11.1 dev eth1 proto dhcp scope link src 192.168.11.102 metric 101 ``` ---- ### solution (please do comment if something here is wrong or needs clarifications - hopefully someone will find this discussion in the future and find it useful) In scenario 1, packets from the PC to the server are routed through .11.1. Since the server also has an .11/24 address, packets from the server to the PC (including replies) are *not* routed and instead just sent directly over ethernet. Since the PC does not expect replies from a different machine that the one it contacted, they are discarded on arrival. The solution to this (if one still thinks the whole thing is a good idea), is to route traffic originating from the server and directed to .11/24 via the router. This could be accomplished with `ip route del 192.168.11.0/24`, which would however break connectivity with .11/24 adresses (similar reason as above: incoming traffic would not be routed but replies would)... The more general solution (which, IDK, may still have drawbacks?) is to setup a secondary routing table: ```bash echo 50 mytable >> /etc/iproute2/rt_tables # this defines the routing table # (see "ip rule" and "ip route show table <table>") ip rule add from 192.168.10/24 iif lo table mytable priority 1 # "iff lo" selects only # packets originating # from the machine itself ip route add default via 192.168.10.1 dev eth0 table mytable # "dev eth0" is the interface # with the .10/24 address, # and might be superfluous ``` Now, in my mind, that should break connectivity with .10/24 addresses just like `ip route del` above, but in practice it does not seem to (if I remember I'll come back and explain why after studying some more)
fedilink

Simplest tool to maintain local mirrors of git repos?
I want to have a local mirror/proxy for some repos I'm using. The idea is having something I can point my reads to so that I'm free to migrate my upstream repositories whenever I want and also so that my stuff doesn't stop working if some of the jankiest third-party repos I use disappears. I know the various forjego/gitea/gitlab/... (well, at least some of them - I didn't check the specifics) have pull mirroring, but I'm looking for something simpler... ideally something with a single config file where I list what to mirror and how often to update and which then allows anonymous read access over the network. Does anything come to mind?
fedilink

If going the route of a backup solution, is it feasible to install OpenWRT on all of my devices, with the expectation that I can do some sort of automated backups of all settings and configurations, and restore in case of a router dying?

My two cents: use a “full” computer as your router (with either something like OPNsense or any “regular” linux distro if you don’t need the GUI) and OpenWRT on your access points.

Unless you use the GUI and backup/restore the configuration (as you would with proprietary firmwares), OpenWRT is frankly a pain to configure and deploy. At the moment I’m building custom images for all my devices, but (next time™) I’m gonna ditch all that, get an x86 router and just manually manage OpenWRT on my wifi APs (I only have two and they both have the same relatively straightforward config).

It’s a pain that I know can be solved with buying dedicated access points (…right?)

Routers and access points are just computers with network interfaces (there may be level-2-only APs, but honestly I’ve never heard of any)… most probably your issue is that the firmware of your “routers as access points” doesn’t want to be configured as a dumb AP.


man this is getting real popular (kinda like “why not both?” a while ago)


With the very limited number of drives one may use at home, just get the cheapest ones (*), use RAID and assume some drive may fail.

(*) whose performances meet your needs and from reputable enough sources

You can look at the backblaze stats if you like stats, but if you have ten drives 3% failure rate is exactly the same as 1% or .5% (they all just mean “use RAID and assume some drive may fail”).

Also, IDK how good a reliabiliy predictor the manufacturer would be (as in every sector, reliabiliy varies from model to model), plus you would basically go by price even if you need a quantity of drives so great that stats make sense on them (wouldn’t backblaze use 100% one manufacturer otherwise?)


In your shoes, I’d put the money in a proper case (eg. fractal node 304/804) rather than an USB enclosure (no, you don’t need hot-swap for a home server): besides the performance issues of USB (which may or may not be an actual issue depending on what you plan to do with the NAS), having a single box makes everything simpler.

For components to fill up the case, you can look at second-hand computers on ebay.

As for the OS, if you are not familiar with linux you may want to look at truenas scale (which is linux).

If you never built a PC, you’ll have to do a lot of research not to buy incompatible components… otherwise you could rely on a friend/shop or stick to sinology and similar.