3 ms·

My home router is an old PC running Linux with some extra 10G ixgbe cards. If you know how to configure it, I'm convinced there isn't a better way: the only rea

My home router is an old PC running Linux with some extra 10G ixgbe cards. If you know how to configure it, I'm convinced there isn't a better way: the only real downside is the power use, and it's not that bad.

frankjr 3y ago
Most of Germany (and Czechia, maybe even Europe?) is still rocking xDSL lines, so at the very least you still need a modem.
ffsm8 3y ago
Where did you find a modem card? I tried to do that a few months ago too, as I'm already running a homelab server 24/7, but couldn't find any cards supporting vdsl nor cable Or do you mean just as a wan connection/router? In that case... Sure, you can do that. I just don't see the value in that, personally.
- jcalvinowens 3y ago
  I don't care about the L2 interface. I imagine I could twist my ISPs arm and spend a bunch of money to end up with the fiber line directly connected to a card in my Linux box... but why? The ISP's upstream equipment is just as vulnerable as a modem, and there's a lot more of it. That's not the point for me. When I had DSL (and later DOCSIS), I just bought my own modems that weren't routers, and used ethernet to connect the Linux router (a raspberry pi 3 originally, yes the DSL was so slow it wasn't a bottleneck!). It was economical because Time Warner charged me something like $5/month to use their modem. There's a lot of reasons I like having a Linux router, a short list: * I have 10G internet from Sonic, in 2020 building a small Linux machine with ixgbe cards was cheaper than any commercially available 10G router with as many ports as I needed (4+). I get line rate through it, no problem. * It runs an open source NAT implementation that is actually correct (although this is less of a problem with commercial routers now than it was back in the day...). Sadly, I don't have IPv6, but the same argument would apply there. * I can run whatever DHCP server implementation I want. * No web GUIs: I SSH to the thing and write config files. * If it blows up, it's just Linux, and all the config files are in git: any machine will do, I don't have to worry about some commercial product disappearing and forcing me to waste an afternoon reinventing the wheel. * I can build and run recent vanilla kernels with all the hardening options enabled. A Linux router spends 99% of its time in the kernel. * The machine is actually fast enough to scan 10G traffic at line rate in software when I want to do that (it's doing all the routing in software, after all). It's really easy, I'd estimate I spend 1-2 hours a year maintaining it.
namibj 3y ago
Given the way mine (not FritzBox) chokes due to NAT being a little stupid when burdened with enough outbound IPv4 dialing, I'd like a PCIe DOCSIS 3.1 (and enough EuroDOCSIS 3.0 to get through bootstrapping, as the ISP doesn't yet support pure 3.1 moderns) modem... I may settle for a 2.5GBASE-T "classic" modern, though, despite the lost control over the TX queue. It's sadly not possible to just presume a TX speed and forgo backpressure from DOCSIS to the packet scheduler that has the knobs to never turn Internet usage off again just to stop other more sensitive Internet usage from lagging.
- jcalvinowens 3y ago
  Even if you had a modem card, there are too many more potential queueing points upstream of it: what you're proposing here would never make any measurable difference in real life. The congestion that makes cable uplinks suck isn't happening at your modem. If you want to run BitTorrent and game at the same time, the router can e.g. limit the BitTorrent flows to something below the minimum guaranteed TX rate, so you know there's no queueing on the modem.
  - jcalvinowens 3y ago
    A random anecdote: Last time I had cable was on Time Warner in the US. It was interesting because they didn't do the token bucket style ratelimiting I've seen from every ISP I've had since: they'd play games with TCP to try and slow down big flows instead. It was weird. So I wrote a little program that transferred files by sending the data over UDP at a constant rate disregarding loss, then reconciling lost bits later over TCP. That allowed me to get almost double the upload bandwidth I was theoretically paying for at the time! But on Verizon FIOS, it didn't work at all, because they really limit bandwidth at the packet level instead of trying to trick TCP into slowing down.

frankjr 3y ago

Most of Germany (and Czechia, maybe even Europe?) is still rocking xDSL lines, so at the very least you still need a modem.

ffsm8 3y ago

Where did you find a modem card? I tried to do that a few months ago too, as I'm already running a homelab server 24/7, but couldn't find any cards supporting vdsl nor cable Or do you mean just as a wan connection/router? In that case... Sure, you can do that. I just don't see the value in that, personally.

jcalvinowens 3y ago
I don't care about the L2 interface. I imagine I could twist my ISPs arm and spend a bunch of money to end up with the fiber line directly connected to a card in my Linux box... but why? The ISP's upstream equipment is just as vulnerable as a modem, and there's a lot more of it. That's not the point for me. When I had DSL (and later DOCSIS), I just bought my own modems that weren't routers, and used ethernet to connect the Linux router (a raspberry pi 3 originally, yes the DSL was so slow it wasn't a bottleneck!). It was economical because Time Warner charged me something like $5/month to use their modem. There's a lot of reasons I like having a Linux router, a short list: * I have 10G internet from Sonic, in 2020 building a small Linux machine with ixgbe cards was cheaper than any commercially available 10G router with as many ports as I needed (4+). I get line rate through it, no problem. * It runs an open source NAT implementation that is actually correct (although this is less of a problem with commercial routers now than it was back in the day...). Sadly, I don't have IPv6, but the same argument would apply there. * I can run whatever DHCP server implementation I want. * No web GUIs: I SSH to the thing and write config files. * If it blows up, it's just Linux, and all the config files are in git: any machine will do, I don't have to worry about some commercial product disappearing and forcing me to waste an afternoon reinventing the wheel. * I can build and run recent vanilla kernels with all the hardening options enabled. A Linux router spends 99% of its time in the kernel. * The machine is actually fast enough to scan 10G traffic at line rate in software when I want to do that (it's doing all the routing in software, after all). It's really easy, I'd estimate I spend 1-2 hours a year maintaining it.

namibj 3y ago

Given the way mine (not FritzBox) chokes due to NAT being a little stupid when burdened with enough outbound IPv4 dialing, I'd like a PCIe DOCSIS 3.1 (and enough EuroDOCSIS 3.0 to get through bootstrapping, as the ISP doesn't yet support pure 3.1 moderns) modem... I may settle for a 2.5GBASE-T "classic" modern, though, despite the lost control over the TX queue. It's sadly not possible to just presume a TX speed and forgo backpressure from DOCSIS to the packet scheduler that has the knobs to never turn Internet usage off again just to stop other more sensitive Internet usage from lagging.

jcalvinowens 3y ago
Even if you had a modem card, there are too many more potential queueing points upstream of it: what you're proposing here would never make any measurable difference in real life. The congestion that makes cable uplinks suck isn't happening at your modem. If you want to run BitTorrent and game at the same time, the router can e.g. limit the BitTorrent flows to something below the minimum guaranteed TX rate, so you know there's no queueing on the modem.
- jcalvinowens 3y ago
  A random anecdote: Last time I had cable was on Time Warner in the US. It was interesting because they didn't do the token bucket style ratelimiting I've seen from every ISP I've had since: they'd play games with TCP to try and slow down big flows instead. It was weird. So I wrote a little program that transferred files by sending the data over UDP at a constant rate disregarding loss, then reconciling lost bits later over TCP. That allowed me to get almost double the upload bandwidth I was theoretically paying for at the time! But on Verizon FIOS, it didn't work at all, because they really limit bandwidth at the packet level instead of trying to trick TCP into slowing down.