Five router firmware builds have just been deemed majorly unsafe, and it isn't the usual patch-it-and-move-on situation. The web interface on these routers has a hidden backdoor password that hands over full admin access, and the username you type doesn't even matter.
Apple discontinued its AirPort Wi-Fi routers in 2018, and it's not surprising given that wireless networking had become a commodity years earlier. Why buy a router when your internet provider's included Wi-Fi is often good enough, and specialists like Eero and Netgear can sometimes offer more for your money?
Mesh Wi-Fi is supposed to fix dead zones without filling your home with Ethernet cables. After all, Ethernet is fantastic, but only if you can easily run the cable from place A to place B, and preferably without it becoming an eyesore.
I've spent a whole lot of money on networking gear over the years, but time and time again, it's some of my cheapest purchases that keep surprising me (in a good way). One of the first was my USB-to-Ethernet adapter, and now, I'll tell you a bit more about my second favorite: a five-port unmanaged gigabit switch.
Pi-hole is one of the simplest and most useful things you can set up on your home network. It acts as a DNS sinkhole that blocks requests to domains associated with known ad servers or trackers. This gives you a far better browsing experience, but if you're only running a single instance of Pi-hole, things can go wrong.
You know that one spot in your house where a call falls apart? You're chatting away, you walk from the couch to the kitchen, and suddenly you cut out.
Most people set up their home router once, connect their devices, and never open the admin panel again. That works fine until the issues come. The settings covered here aren't complicated to change, and most of them take under five minutes. The difference is that once they're done, your network is faster, more private, and a lot harder to mess with.
My home internet is stable now, but that wasn't true just a couple of years ago. I've gone through several terrible ISPs before finding one that actually delivered.
I wanted a new mesh Wi-Fi system badly a few years ago, but simply couldn't afford one. Instead of spending money I didn't have on Wi-Fi networking gear that I didn't really need, I repurposed my old router and it gave me almost everything I was looking for without costing me a dime.
Sometimes you just want to sit in the garden under the shade of a tree and doom-scroll social media. If you have a small or medium-sized garden, then your mesh Wi-Fi system in your home will probably do a decent job of keeping you connected. Especially if you have one mesh unit just inside a window, like I do!
There are only so many Wi-Fi tweaks we can try before finally buying a new router. The good thing about that purchase is that once you get a router, it'll be good for years and years.
There are a lot of different mesh router brands, models, and designs. So much so, that it can be daunting to step into the world of mesh routers for the first time.
Most people worry about outsiders breaking into their home network, but few think about what the devices already inside their home can access. While your trusted devices talking to each other is usually harmless, smart TVs are a different story: many models collect viewing habits, run outdated software, and frankly have little reason to see everything else connected to your network.
For a long time, Pi-hole was the go-to option for anyone that wanted to use DNS filtering on their home network. It is easy enough to set up on any old laptop, PC, or even a low-power Pi and then connect it to your network.
As AI workloads drive soaring cloud bills, more companies are weighing whether to move computing out of public clouds and into their own data centers. But building and operating AI infrastructure is far more complicated than simply buying servers — networking has become one of the biggest technical hurdles.
That’s the opportunity Seattle startup Hedgehog is chasing.
Founded in 2022 by CEO Marc Austin, a Cisco networking veteran, Hedgehog develops open-source software designed to make private AI data centers operate more like hyperscale clouds. It has raised $11 million in seed funding, with plans to raise a series A financing round.
We caught up with Austin for the return of GeekWire’s Startup Spotlight to learn more about the 20-person company, the AI networking boom and what surprised him most about building a startup in one of tech’s fastest-moving markets.
In 50 words or less, give us your elevator pitch?
Hedgehog is open-source software that makes AI networking simple. AI clouds and enterprises use it to run GPU networks the way hyperscalers do — deployed in hours instead of months, operated by DevOps teams instead of armies of network engineers, on open hardware with no vendor lock-in.
What problem are you obsessed with solving?
Time to GPU value. A GPU cluster is the most expensive asset most companies will ever buy, and every day it sits idle waiting on the network is money burning. That wait is rarely the hardware — it’s the fabric: weeks or months of scarce network engineers hand-designing, cabling, tuning, and validating it across proprietary CLIs and locked-in vendor gear.
Meanwhile the people told to “own the network” usually aren’t network engineers at all — they’re platform and DevOps teams. We’re obsessed with collapsing that timeline: declare your network like intent in Kubernetes and go from racked GPUs to inference in hours instead of months — on open hardware, no lock-in, no room full of specialists. Cloud-grade networking without hyperscaler headcount.
What surprised you after talking to customers?
How rarely the buyer is a network engineer. It’s platform and DevOps teams, often at AI clouds who just took delivery of thousands of GPUs who are told “you own the network now.” They don’t want to learn BGP; they want a network that behaves like the rest of their cloud-native stack. The other surprise: they don’t just want to run the network, they want to sell it by carving up capacity for their own customers, like a cloud provider does.
How has AI changed the way you build your company?
Twice over.
Our product exists because AI broke traditional networking. Training and inference traffic melts networks designed for web apps.
And AI changed how we build: we use it heavily across engineering, testing, and go-to-market, which lets a small team continuously test every supported device and configuration in our lab and ship with hyperscaler-grade rigor. AI raised the bar for what a startup-sized team can deliver.
What’s one thing people misunderstand about your startup?
That “open source” means hobbyist. The opposite is true: openness is the enterprise feature. Our customers can audit every line of code that runs their fabric, extend it, and never get locked in. Nearly every competitor markets “open networking” while shipping a proprietary controller. Hedgehog is the only one that actually publishes the repo.
What’s the toughest decision you’ve made in the past year?
Betting entirely on Ethernet. We decided open, standards-based Ethernet would win AI networking and put everything behind it. Watching the industry’s largest AI operators now standardize on that same approach makes us feel good about the call — but saying no was hard.
What’s the one piece of advice you give to other entrepreneurs?
Pick the wave, not just the surfboard.
Product decisions are recoverable; betting against a structural industry shift isn’t. Find the standard, the architecture, or the buyer behavior that’s inevitable, align everything to it early, and be patient while the market catches up to your bet.
We’ll know our company has made it when…
Networking is boring again. When a platform engineer stands up a multi-tenant GPU cloud and the network is just a few lines of declared intent that nobody thinks twice about. When “network like a hyperscaler” describes every AI cloud, not just the giants running on Hedgehog, then we will have made it!
In the previous installment on UDP broadcasting and service discovery, the basics of both were explored, including an implementation in the form of NyanSD and its protocol. Contained in the comment section was a very good demonstration of why one of the most exciting aspects of software development is the opportunity to share your latest creations with other people. This being the ability to get solid feedback on all the points – including any potential boneheaded omissions – that you really should address, whether intentional or accidental.
The most pertinent point raised was definitely that of broadcast addresses and IPv4 subnets, with the latter topic especially being something that the sysadmins at the office would talk about all the time, but which us software developers were always happy to ignore as something that didn’t concern us. Turns out the joke was on me and everyone else – like our esteemed readers – who thought that they could escape the fascinating world of subnets, as today we’ll take an in-depth look at what subnets are and how they are relevant to the world of UDP network discovery.
I somewhat alluded in the first article to the topic of ‘which broadcast address to use’ as being somewhat of a rough topic to figure out, which is clearly why I just stuck to a blatantly ‘works for me’ /24 subnet that usually will work on networks, until it does not.
The short version of ‘what is a subnet’ is to point at the subnet mask that we have been mostly mindlessly mashing into networking configuration dialogs along with the IPv4 address for many decades now. Usually this takes the form of 255.255.255.0, which is just the human-readable version of the actual bitmask. Here the loopback interface already tends to use 255.0.0.0 as its netmask, which is a detail that tends to be easy to gloss over as this is just one of those local OS things.
Putting netmasks in the crudest and simplest terms, they are a bitmask that is used to identify how an IPv4 pool of addresses is split up by defining which bits of the 32-bit IPv4 address identify a subnet. Normally we call the trailing part of an IPv4 address (the .123) the host identifier, with the preceding section the network identifier.
By masking part of this host ID and using it to create a subnet identifier, we can then use this for additional routing, just at the cost of a reduced number of possible host IDs within that subnet.
As an example, the common 255.255.255.0 mask identifies the first 24 bits (3 bytes) of the 32-bit (4-byte) IPv4 address, hence the mask being referred to as /24. With this mask, the remaining host ID bits allow for 256 hosts, of which two are not used for hosts: the first (e.g. 192.168.0.0) and last (e.g. 192.168.0.255) in the range. The last host ID in the range forms the broadcast address for that subnet.
This is why, for a /24 subnet, you can generally get away with just slapping a .255 on the end of an interface’s address, but also why for other subnet configurations it’s likely to explode violently.
To get briefly back to the loopback’s /8 style netmask, this means a single subnet with a maximum of 16,777,214 hosts, which ought to be sufficient for local system networking shenanigans. Its opposite extreme would be the /31 style netmask, which with just two potential host IDs is practically useless.
IPv6 subnetting is similar, but due to the much larger address pool and differences in the protocol this is a whole other kettle of fish that is as likely to send a network administrator’s heart racing in excitement as it is to make the average software developer run away screaming. This can be a fun topic for another day, perhaps.
This overview of IPv4 subnetting also skips over details like the different classes of IPv4 subnets beyond the Class A type here, but those are happily left to sysadmins and kin for now.
In order to thus obtain the broadcast address for a given network interface you need to know two things: the IPv4 address and its associated netmask. From this you can then tell three things: the subnet ID, the broadcast address in that subnet, and the current host ID. Of these we only really care about the the second item.
Although you can obtain the broadcast address yourself by applying the netmask to the address, the OS’s APIs tend to happily give you the precomputed broadcast address. If that’s not your style or not an option, a manual procedure is to:
Login1 in these bits to get the highest possible host ID.If we thus start with a 192.168.0.0/24 network, we end up with 192.168.0.255, while for a 192.168.0.0/26 network with just six bits available the maximum value is 64, ergo we get 192.168.0.63, since we start counting at 0.
With this we can now broadcast UDP packets on any interface without any (major) worries.
A small glitch in the whole above story is that there’s actually another broadcast address, one which is always the same for each interface and can be considered to make the whole preceding explanation completely irrelevant. This being the local, or limited, broadcast address, which is either the best thing since sliced bread or the worst sin ever committed in the history of IP networking, depending on whom you ask.
This cheat code takes the form of the address 255.255.255.255 and if you send a packet on a UDP socket to it, you’ll get happy UDP responses from any service that is listening on the specified port. This raises the point of why you’d not just use this broadcast address on all interface, rather than bother with all the earlier described nonsense.
The only major difference between this local broadcast address and the earlier described directed broadcast address is that the latter can also be used to target a foreign network, instead of just the local network. This makes it a very attractive option if you just want to query the local network with UDP broadcast packets.
As for why you’d not want to use a local broadcast address, I couldn’t really find any references or citations on why this would be the case. Both would appear to be perfectly valid approaches to broadcasting, each with its own pros and cons.
One final topic was my mistaken hardcoding of a /24 style broadcast address in NyanSD. Here reader ziew helpfully pointed me towards the Poco::Net::NetworkInterface::broadcastAddress() function, which seemed perfect. Unfortunately Poco’s implementation at least on Windows 10 appears to be rather broken.
After getting only 0.0.0.0 as broadcast address from this function, I had a bit of a look at what was happening, including checking what I got as subnet mask both for the default index parameter and for the next index. Across two different Windows 10 installations and both GCC in MSYS2 as well as MSVC 2017/2022 with various versions of Poco the returned values were… interesting enough to file a bug report on the Poco issue tracker.
Clearly this isn’t going to be fixed just yet, but on the bright side the horrific atrocity that I committed by hardcoding a /24 broadcast address will still work on basically every home LAN out there that NymphCast is likely to be used on.
Maybe I could just switch to a local broadcast address and that’d be even better. Feel free to torch down this idea in the comments, just be sure to provide solid reasoning and cite your sources.
Writing out the above pretty much clarifies I think why past me got a bit overwhelmed when trying to ‘just do a UDP broadcast thing’. Even just scratching the surface of IPv4 subnets and not even venturing into IPv6 territory makes one already feel a bit antsy.
Certainly, one could totally argue that anything other than a /24 network is unlikely to be encountered outside of certain government and business networks with either very specific needs, very enthusiastic sysadmins, or both, but it’s always better to design software with such real-life scenarios in mind.
SpaceX’s proposed Gen3 network could expand satellite capacity for enterprise connectivity, but the FCC has not approved the 100,000-satellite request. Deployment, pricing and service availability remain unresolved.
The post SpaceX Seeks FCC Approval for 100,000 Gen3 Satellites appeared first on TechRepublic.
AI data centers are running into a network bottleneck as GPU clusters expand. For infrastructure teams, fabric design, congestion control, and interoperability now matter as much as power, cooling, and accelerator supply.
The post AI Data Centers Face a Networking Bottleneck as GPU Clusters Grow appeared first on TechRepublic.
Elon Musk denied a report that SpaceX showed investors an AI device prototype, but the Starlink-xAI connection gives IT teams a reason to monitor the platform risk.
The post Elon Musk Denies SpaceX AI Device Report as Starlink Strategy Questions Grow appeared first on TechRepublic.
