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.
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.
Welcome back, aspiring hackers!
The density of WiFi access points in modern cities has now reached a point where a large-scale surveillance system may be able to identify almost anyone who walks near a router, even if that person is not carrying a mobile phone. Researchers from the Karlsruhe Institute of Technology (KIT) have published a scientific paper describing this kind of system and the technology that makes it possible.
At the center of this surveillance method is a feature called beamforming, which first appeared with the WiFi 5 (802.11ac) standard in 2013–2014. The basic idea was introduced with WiFi 5, but it became much more refined and effective with WiFi 6 (802.11ax), where the technology matured into something more practical.
Beamforming, also called spatial filtering, is a signal processing technique used to send and receive wireless signals in specific directions rather than spreading them evenly in every direction. In simple marketing language, this is often described as a router that “does not broadcast equally everywhere anymore, but instead follows the user with a focused beam.” That description is not wrong, but it leaves out the technical depth behind the idea.
From an engineering point of view, beamforming works by combining several antennas into a group called an array. When the signals from these antennas are timed and lined up correctly, they boost each other in certain directions. In other directions, they cancel each other out. The result is a signal that is far more focused and efficient than older systems, which simply broadcast outward in every direction at once.
Beamforming gives both senders and receivers the ability to focus on signals coming from one direction while blocking out noise from others. Because of that, the technique is used not only in WiFi, but also in radar, sonar, seismology, wireless communications, radio astronomy, acoustics, and biomedical engineering.
As radio waves move through space, they do not simply travel in a straight, clean line. They interact with the world around them in many different ways. They can pass through objects, reflect off surfaces, become absorbed, become polarized, bend around obstacles, scatter in different directions, or refract as they cross boundaries between materials. This means that when a WiFi system sends a signal and later receives it back, the final result contains information about everything the signal encountered along the way. By comparing the expected signal with the received one, it becomes possible to measure interference and use that information to correct transmission errors. But that same interference also reveals details about the environment itself.
For example, when a person enters the path of a WiFi signal, the signal changes. Human bodies affect radio waves in measurable ways. The signal may weaken, shift, scatter, or behave differently depending on movement, posture, and position. If researchers analyze these changes carefully, they can infer a surprising amount of information about the surrounding environment. They may detect whether people are present, what they are doing, and in some cases even who they are.
This whole research area has grown into a separate field known as WiFi Sensing.
Most WiFi Sensing research is presented as useful and harmless, and in many cases it really is. It can support smart-home features, occupancy detection and other practical applications. But the privacy concerns are obvious. When these methods are combined with activity recognition and the massive spread of WiFi hotspots, they can reveal highly sensitive information. One of the most troubling possibilities is that someone could be identified in the range of a hotspot and then tracked over time without ever knowing it.
There are several ways a person can be identified through WiFi. One important method relies on analysis of Channel State Information (CSI), which is sent at the physical layer of WiFi communication. CSI is detailed and useful for WiFi sensing. It gives a rich picture of how the wireless channel behaves. The problem is that CSI is not always easy to access. In many cases, it requires modified firmware and specialized hardware support, which limits how widely it can be used in practice.
The table above compares roughly 25 different systems, evaluating them across several key dimensions. The Paper column lists the name of each system, while the Identities column shows how many different people each system is capable of distinguishing between. The Accuracy column then reflects how reliably each system correctly identifies a person. On the technical side, the Pre-Processing column describes the signal processing techniques each system applies to clean and transform raw WiFi data before passing it to a machine learning model, and the Model Architecture column identifies what type of model is used. The Perspective column shows how subjects were positioned or moving during data collection, such as standing orthogonally, performing gestures, or typing keystrokes.
Beamforming entered the picture for a different reason. As mentioned earlier, it was introduced in WiFi 5 to improve throughput and make wireless communication more efficient. But beamforming also depends on environmental information that is similar to CSI. The difference is that this information is gathered on the transmitter side rather than the receiver side.
The key new dimensions here are the Inference column, showing the wide variety of tasks these systems tackle, from respiratory rate monitoring and crowd counting to sign language recognition.
In a typical beamforming setup, client devices send something called Beamforming Feedback Information (BFI) back to the access point. BFI is a condensed snapshot of current signal conditions. It tells the access point how the wireless channel looks so that it can adjust its transmission for better performance.
The key difference between CSI and BFI is that BFI is transmitted back to the access point without encryption. This makes it much easier to collect using standard, off-the-shelf hardware, without needing any special software modifications. That significantly lowers the bar for potential misuse. The privacy concern gets even more serious when you consider that the IEEE is already working on making WiFi sensing an official standard through the upcoming 802.11bf update and based on the current draft, without putting strong privacy protections in place.
Researchers at KIT showed that people can be identified using only BFI data, even when they are not carrying a smartphone or any other wireless device. The method does not depend on a person bringing along a tracked gadget. It works using ordinary WiFi devices already present in the environment and already communicating with one another.
As radio waves move through space and interact with the human body, they create patterns that can be captured, analyzed, and compared. In that sense, the process starts to resemble imaging, almost as if the wireless system were building a rough picture of a scene without using a camera. The result is not a photograph in the normal sense, but the data can carry enough structure to support identity inference.
“The technology turns every router into a potential surveillance device,” says Julian Todt, one of the study’s authors. “If you regularly walk past a café that has a WiFi network, you could be identified without your knowledge and later recognized by government agencies or commercial companies.”
That is a serious warning, and it captures the core concern very well. Intelligence services and cybercriminals already have many easier ways to monitor people, including compromising CCTV systems or intercepting video communications. But wireless networks are different. They create a nearly invisible surveillance layer that already exists in a huge number of places.
Unlike earlier approaches that depended on LiDAR sensors or on reflection-based systems using walls, furniture, and human bodies, this method works with standard WiFi equipment. By collecting BFI data, researchers can build representations of people from several different viewing angles. These representations are then used to distinguish one person from another, even when the number of people is large. Once the machine learning model has been trained, the identification process can happen in just a few seconds.
The study involved 197 participants. The researchers reported that they were able to identify individuals with nearly 100% accuracy, regardless of viewing angle or walking style. That is an impressive result, but it did not come easily. To reach that level of accuracy, the model needed a substantial amount of machine learning training. Each person in the training set performed around 20 walking passes before the model was trained.
During the research two TP-Link Archer BE800 routers were used. The experiment relied on channels 37 and 85. It also used two non-overlapping 160 MHz channels in the 6 GHz band available under WiFi 6E. The hardware included Intel AX210 WiFi network adapters.
The researchers stress that the technology is powerful, but also potentially dangerous. The risks are especially serious in authoritarian states, where systems like this could be used for large-scale population surveillance. In such settings, the ability to identify people without their phones, without cameras and without obvious visible monitoring would be a major privacy threat.
For that reason, the authors strongly recommend that privacy protections and security safeguards be built into the upcoming IEEE 802.11bf standard from the start, rather than added later as an afterthought.
In fact, WiFi-based sensing has become so effective that some modern routers already include motion-detection features right out of the box, and manufacturers openly advertise them.
Features such as WiFi Motion Detection allow homeowners to monitor activity inside their homes through mobile apps, using nothing more than changes in WiFi signal patterns.
A feature designed for convenience in a home can also become part of a much broader surveillance system when deployed at scale.
As an additional note, several tools already exist that monitor wireless activity in nearby environments. They don’t work exactly the same way as the techniques we covered earlier, but they’re still useful.
Pi.Alert scans devices connected to a WiFi network, detects unknown devices, and sends notifications when devices unexpectedly disconnect from the network. It is often used as a practical awareness tool for keeping track of what is present on a home or local network.
WireTapper discovers nearby wireless signals, including WiFi networks, Bluetooth devices, hidden cameras, vehicles, headphones, televisions, and cellular towers. It gives the user a broader view of the wireless environment around them, which can be useful for awareness and inspection.
We also have an video on this topic with Master OTW and Yaniv Hoffman. In the video, OTW explains how hackers can use SDR, AI, and Wi-Fi signals to detect human movement through walls, how the technology works, and talk about practical ways to defend against it. Feel free to check it out.
As modern routers gain advanced sensing, they can also become tools for observing and identifying people through the way their bodies interact with wireless signals. The KIT research shows that this is a practical technology that can identify individuals with remarkable accuracy using ordinary WiFi hardware. Although WiFi sensing can be valuable for smart homes and automation, it also raises serious privacy concerns. Privacy protections will need to become just as important as performance improvements.
If you’re interested in Wi-Fi security, our Wi-Fi Hacking training can help you gain the necessary experience. This attack vector is often underestimated, and many organizations are vulnerable to it. It is definitely valuable in penetration testing.
The post Wi-Fi Hacking: Wi-Fi Can Now Identify You Without Your Phone first appeared on Hackers Arise.
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.
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.
