Introducing Wireless Links to Obelinf

The wired side of your network is documented down to the port. Cables have records, switches have interfaces, and VLANs have names. The moment two buildings are joined by a wireless bridge, or a backhaul carries a site’s traffic, that documentation usually stops. The link lives in a spreadsheet, in an installer’s memory, or in a vendor controller that will be replaced before anyone exports it.

Obelinf now models those links directly. A wireless link is a record that connects exactly two wireless interfaces, the wireless equivalent of a cable, and it sits in the same inventory as the devices, VLANs, and wireless LANs it depends on. This release also gives wireless interfaces a real type, adds access point and station roles to wireless LANs, and links an SSID to the VLAN it delivers clients into.

At a Glance: Where Wireless Links Live

A Wireless Link Is the Wireless Cable

Think of a wireless link the way you think of a cable. A cable joins two interfaces and is documented once rather than duplicated on both devices. A wireless link works the same way: it has a side A and a side B, both of which must be wireless interfaces, and it carries the details that belong to the connection itself, such as distance and authentication.

Because a physical port terminates one link at a time, Obelinf enforces the same rule here. A wireless interface can be the endpoint of only one wireless link, so you cannot accidentally document two bridges on the same radio. The other half of the rule is just as useful: interfaces with a wireless type are rejected as cable endpoints, so a point to point bridge is never recorded as a cable by mistake.

What a Wireless Link Record Holds

A wireless link record keeps the facts you would otherwise scribble on a diagram. The two endpoints are required. Everything else is optional, which matters when a link is planned but not yet installed. An optional SSID names the network the link bridges, so a point to point link can carry the same name as the wireless LAN it serves. Status tracks whether the link is connected, planned, or decommissioning, and distance records the span with a unit.

Authentication is recorded per link, because a dedicated backhaul often runs its own settings rather than inheriting the LAN’s. The record carries an auth type (open, WEP, WPA personal, or WPA enterprise), an optional cipher, and an optional pre shared key. A description field holds the context that does not fit anywhere else, such as which roof or tower each end sits on. The endpoints are deliberately fixed after creation, so moving a link means recording a new one and the change history stays honest about when a bridge actually changed.

Wireless Interfaces, Now a Real Type

Wireless links only make sense if the system knows which interfaces are wireless. Interface types are now recognized against a known list, covering the 802.11 families (a, g, n, ac, ax, be), 802.15.1 and 802.15.4, the cellular types gsm, cdma, lte, 4g, and 5g, and a generic other wireless option.

This is what lets Obelinf validate a link. Both endpoints must be wireless, and a wireless interface cannot be terminated by a cable. Wired interfaces are unaffected and continue to use cables exactly as before. In practice you create a device interface with a wireless type, and from that point it is eligible for a wireless link and for the wireless LAN roles below.

Associating Interfaces with Wireless LANs

Knowing that an interface is wireless is only half the picture. You also want to know what it does. A wireless interface can be associated with one or more wireless LANs, and each association carries a role: access point or station. An access point broadcasts the SSID, and a station joins it.

That role is the difference between a list of radios and a map of the wireless network. When you are tracing why a client lands on a particular VLAN, or which radios serve a given SSID, the association tells you where to look. It also keeps the inventory honest when a radio changes job, because the role is a field you update rather than a note you forget.

Wireless LANs Now Carry VLAN, Status, and Auth

The first wireless release stopped short of linking an SSID to a VLAN. That gap is closed. A wireless LAN record can now point at the VLAN it delivers clients into, carry a status, and store authentication settings. Status covers active, reserved, disabled, and deprecated, which is enough to mark a network that exists in the controller but should not be advertised.

The VLAN link is the one that changes how the wireless layer reads. Instead of holding the SSID to VLAN mapping in your head, the wireless record names the VLAN directly, and the VLAN record stays the single place those identifiers live. Authentication moves to the same record, so the security model you set in the controller is captured where the network is described.

Wireless Links on the Topology Diagram

Wireless links appear on the topology diagram as their own edge, drawn separately from cables. That means a site reads the same whether its segments are wired or wireless, and a device linked by a bridge shows the connection instead of appearing isolated.

The distinction matters most at the edges of a network. A branch joined by a wireless bridge, or two racks connected by a point to point link, are exactly the places where the topology usually goes blank. Showing wireless links as first class edges keeps those gaps visible instead of leaving them to memory.

Available over the API and MCP

Wireless links, interface wireless LAN assignments, and the new wireless LAN fields are all available over the REST API and through the MCP server. A provisioning workflow can create a link when a bridge is installed, and an AI agent can answer questions about your wireless inventory from the same data your team reads. Read only API keys can list wireless records but cannot create, update, or delete them, so an assistant you have granted read access cannot quietly change your documentation.

What It Costs

Wireless links share the wireless allowance with wireless LANs and groups. The free Personal plan includes 10 combined, which is enough to document a homelab or a single small office, and paid plans remove the cap. You can see the full breakdown on the pricing page.

Start Documenting Your Wireless Links

The fastest start is the bridges you can already name. Create the wireless interfaces with their correct types, add a link for each pair, and set the status and distance while the details are fresh. From there, attach the radios to their wireless LANs, record the VLAN each SSID delivers, and the wireless layer stops being the one part of the network nobody can point to.

You can create your account for free at obelinf.com and record your first wireless link in minutes.