Verify users land on the right VLAN

Dynamic VLAN assignment fails quietly: the user authenticates, RADIUS returns an Access-Accept, and the device still lands on the wrong network because a required attribute was missing or malformed. Instead of chasing it from the switch, assert the VLAN in the test itself — the probe reads what the Access-Accept actually carries and fails if it's not what you expect.

1. Assert the VLAN with --expect-vlan

--expect-vlan checks that the Access-Accept assigns the VLAN you name (via Tunnel-Private-Group-Id). Match, and it's a PASS; anything else — a different VLAN, or no VLAN attribute at all — is a FAIL, not a shrug:

# assert the Access-Accept puts this user on VLAN 20 — a mismatch is a FAIL
authhound-probe radius test --server radius.corp.com \
  --secret-file /etc/authhound/secret --peap alice --expect-vlan 20

Run it as a couple of representative users — one who should be on staff, one on guest — and you've verified the policy actually assigns what it's supposed to, from the client side, without touching a switchport.

2. Assert other returned attributes

VLAN assignment needs three attributes travelling together — the VLAN ID plus Tunnel-Type and Tunnel-Medium-Type — and the most common failure is returning only one of them. Assert any returned authorization attribute with --expect-attr Name=Value (repeatable), and the probe also prints the attributes it got back so you can see the whole set:

# assert other returned authorization attributes (repeatable)
authhound-probe radius test --server radius.corp.com \
  --secret-file /etc/authhound/secret --peap alice \
  --expect-attr Filter-Id=staff --expect-attr Tunnel-Type=VLAN

3. What each outcome tells you

• PASS. The Access-Accept carries the VLAN (and any attributes you asserted). If users still land wrong, the problem is now downstream of RADIUS — the switch doesn't have that VLAN, the port isn't configured to honour RADIUS assignment, or the value is a name where the switch expects a number.
• FAIL — no VLAN attribute returned. The policy isn't sending it for this user. Check the network policy's RADIUS attributes.
• FAIL — wrong VLAN. The policy matched a different rule than you expected. The printed attribute set shows what it did return — usually a policy-ordering or group-membership issue.
• Only attribute 81 came back (no Tunnel-Type / Medium-Type). The single most common "the VLAN attribute is set but the device stays on the default VLAN" cause — see the KB page below.

Related

• RADIUS dynamic VLAN not working — device on the default VLAN

  The three-attributes-together rule, string-vs-integer, and the switch-side checks — the server-side companion to this test.

• Reference: Tunnel-Private-Group-Id (attr 81)

  What the VLAN attribute carries and the two attributes that must travel with it.

• Wire the probe into your RMM

  Turn --expect-vlan into a standing assertion so a policy change that breaks VLANs alerts you.