Embedded/Network Software Engineer

Job summary

The role involves transitioning a working prototype of a cloud SDK and multi-tenant layer into a production-ready service. Key tasks include implementing device identity, hardware bring-up for non-reference platforms, and hardening network features.

Job details

This is not a greenfield project. We already run a working platform: the TIP OpenWiFi (uCentral) cloud SDK plus an in-house multi-tenant layer above it (Organisation -> Site -> Device model, canonical device catalogue, Keycloak/OIDC role-based access control, audit trail) and a React operator console. Real access points, switches and site gateways are provisioned end to end in our lab today. You are joining to take that from a working prototype to a supportable production service, and to extend it onto hardware and customers it does not yet support. Reference-grade access points work: upstream TIP images exist and they connect to our controller today. Everything else is the job. Non-reference access points are blocked at device authentication. Our switch targets are driven through a vendor command-line interface whose real behaviour differs from its documentation in ways you only find on the hardware. The site gateway is our own OpenWrt-based image and it needs to survive a customer site with no one on it. This is a device-software role with a real bench, a serial console and hardware that will lie to you. Key Responsibilities: Device identity on the hardware. Implement the device side of mutual TLS enrolment and certificate renewal: what identity is on the unit, who signed it, how it is replaced in the field, and how a device that has lost trust gets it back without a truck roll. The lifecycle policy is set with the platform architect; the device-side implementation is yours. Non-reference hardware bring-up. Add and maintain OpenWrt target support for non-reference access points, switch platforms and x86 site gateways: board support, wireless driver triage (ath11k, Broadcom and equivalents), serial and JTAG debugging, boot and recovery paths. uCentral client integrity. Diagnose and fix persistent WebSocket session behaviour between the device and the gateway - reconnection, backoff, certificate validation state, and UCI and ubus configuration state synchronisation. Configuration that reports as applied while the device runs something else is a defect class we take seriously. Firmware build and release. A reproducible, signed image build in CI that feeds controller-driven firmware campaigns, with a working rollback path. Network feature hardening. VLAN tagging and per-site scoping, 802.1X and RADIUS, WPA3, captive portal redirect hooks, wide area network failover and remediation on the site gateway, and the device-side half of our configuration model. Required experience: Expert C and C++ in a resource-constrained embedded Linux environment. Deep, hands-on OpenWrt: build system and buildroot, UCI configuration framework, ubus, package and feed management. Practical X.509 and public key infrastructure in an embedded context: certificate chains, mutual TLS, provisioning device identity at manufacture or in the field. Wireless driver and hardware/software boundary debugging - kernel logs, serial console, crash triage on Qualcomm and/or Broadcom silicon. IEEE 802.11ax and 802.11be, WPA3, 802.1X and RADIUS, VLAN and bridging fundamentals. Python and shell for build tooling and test harnesses. Valuable but not required: Direct TIP OpenWiFi or uCentral client experience. ath11k or Broadcom wireless driver contributions. Switch firmware or vendor switch command-line automation (OpenLAN switching, ONIE, or comparable). Routing and multicast on embedded Linux - PIM, IGMP snooping, VRRP. Hardware root of trust, TPM or secure element provisioning. What success looks like in the first 90 days: Device authentication resolved on at least one non-reference platform, with the failure mode and the fix documented. A signed firmware image built by CI and successfully pushed through a controller-driven upgrade campaign, including a tested rollback. A device-side change that is verifiably applied: the device reports what it is actually running, and divergence from intent is detectable from the controller. What We Offer At GuestTek, you won’t just have a job, you will have the opportunity to build your career while working with innovative technology and a global team. Competitive compensation and comprehensive benefits Hybrid Work Environment Opportunities for career growth and professional development Exposure to innovative technology, AI, cybersecurity, and global projects Collaborative and supportive work environment Opportunities to work with teams and customers around the world Challenging projects that make a real impact A culture that values innovation, teamwork, and employee contributions

What you’ll do

The role involves transitioning a working prototype of a cloud SDK and multi-tenant layer into a production-ready service. Key tasks include implementing device identity, hardware bring-up for non-reference platforms, and hardening network features.

Requirements

Requires expert-level C/C++ skills in embedded Linux and deep hands-on experience with OpenWrt and PKI. Candidates must have practical experience in wireless driver debugging and a strong understanding of IEEE 802.11 standards and network protocols.

Benefits

• Competitive Compensation • Comprehensive Benefits • Opportunities For Career Growth • Professional Development

Listed skills

• VLAN · Preferred
• C++ · Preferred
• Python · Preferred

Other relevant skills

Identified from the job description. Confirm important requirements above.

• C
• C++
• OpenWrt
• Embedded Linux
• X.509
• Public Key Infrastructure
• Mutual TLS
• Wireless Driver Debugging
• IEEE 802.11ax
• IEEE 802.11be
• WPA3
• 802.1X
• RADIUS
• VLAN
• Python
• Shell Scripting

Job areas

• Software
• Engineering
• Technology
• Consulting