FJD Trion P2 Firmware Upgrade Troubleshooting & Vendor Escalation Support (UK / Region-lock + Device Disabled)
Budget: £50 – £200 GBP
We have multiple FJD Trion P2 3D scanning devices in the UK that cannot complete firmware upgrades via the device’s built-in web/browser UI. The upload step succeeds, but the upgrade process fails due to validation/authorization gates and device-side restrictions. We need an experienced contractor to help us diagnose, document, and resolve the issue to enable firmware upgrades reliably in the UK, and to support escalation with the manufacturer.
Important: These devices were purchased directly from the manufacturer / official supply chain. However, manufacturer support has been slow and unhelpful. We need an independent technical specialist to get this finished, using legitimate, supportable methods.
What we’ve established so far
Device update flow (observed)
1. Browser uploads ZIP to device via HTTP:
POST http://10.33.68.254/upload_file.php
2. Device stores it at:
/var/www/html/upload/update.zip
(Confirmed downloadable from http://10.33.68.254/upload/update.zip)
3. Browser triggers update via WebSocket service call:
ws://10.33.68.254:9090/
Service: /software_update with args {op:1, filename:"update"}
4. Device replies with service_response including status/info.
Two independent blockers identified
• Device disabled gate:
/software_update returns status:-1 and info:"设备已被禁用" (“Device has been disabled”).
• Region/lock cloud validation gate:
The UI performs cloud validation calls (scanner.fjdac.cn + myqcloud.com endpoints).
When offline / partial connectivity, it fails with DNS/TLS errors and logs “地区锁验证失败” (“Region-lock verification failed”).
When online, the UI can reach cloud but some requests return 401 Unauthorized. Console flags like “中国地区锁: true” and “串货标识: true” appear.
We have tooling & evidence
• Multiple DevTools captures (XHR + WebSocket messages)
• JSONL sniffer logs capturing:
• WebSocket frames (/software_update request/response)
• console logs
• network failures to cloud endpoints
• A bilingual technical report summarizing findings (English/Chinese)
• Example WS request/response showing the disabled gate:
• Request: call_service /software_update …
• Response: status:-1, info:"设备已被禁用"
Current complication
A Tampermonkey userscript (“FJD Fix v2.6”) can inject UI states (e.g., “installation complete / restarting”) without proving the backend accepted the update. We need rigorous validation against WebSocket traffic and actual device reboot/version.
What we need help with
We need a contractor to take ownership of finishing this and getting upgrades working reliably.
Primary deliverables
1. Definitive root cause analysis
• Confirm exactly what conditions cause /software_update to be rejected.
• Confirm what cloud validation requires (auth tokens/cookies/headers/region entitlements), including what causes the 401.
• Determine whether the browser environment used by automation differs from normal Chrome (headers/cookies/CORS/origin).
2. Complete capture of region-lock cloud calls
• Produce a reliable capture method that logs full request/response details for:
• scanner.fjdac.cn/.../chinaLockInfo?sn=...
• any related validation endpoints
• relevant myqcloud ping/config endpoints
• Identify required cookies/auth headers or login session requirements, if any.
3. Action plan + vendor escalation package
• Provide a clear list of what FJD must change server-side (disabled flag removal, entitlement/channel correction, token provisioning, etc.).
• Provide a concise technical evidence bundle (logs + call traces + translations).
• Draft an email/escalation note (English/Chinese) to send to FJD.
4. Practical resolution path
• Identify the most likely vendor-supported resolution path:
• backend flag clearing
• correct “Overseas/Global” firmware channel assignment
• provision of an official offline recovery image
• signed authorization token/file/code for upgrades
• Provide step-by-step instructions for our team to validate success.
Nice-to-have
• Validate firmware package structure/signature requirements and version compatibility (e.g., downgrade prevention, channel mismatch).
• Identify if the unit’s SN differs across modules (UI uses B vs C serials) and whether that affects entitlement checks.
Constraints / boundaries
• Work must be legal and supportable. We are not seeking unauthorized circumvention.
• We want to work with the manufacturer’s systems/entitlements, but need technical clarity to compel support.
Required skills
• Strong network debugging (Chrome DevTools, WebSocket protocols, XHR analysis)
• Experience with embedded device web UIs / OTA update flows
• Python/automation skills (Playwright/selenium, traffic capture)
• Ability to reason about auth flows (cookies/tokens/401/403)
• Bonus: familiarity with ROSBridge-style WebSocket messaging, nginx/autobahn stacks.
What we will provide to the freelancer
• Device access on LAN (10.33.68.254 web UI + WS endpoint)
• Existing sniffer scripts + JSONL logs
• Screenshots and prior PDF technical report (EN/ZH)
• Firmware files we’ve attempted (zip + .bin/.deb samples)
Please review the attached PDF before bidding for the project.
Important: These devices were purchased directly from the manufacturer / official supply chain. However, manufacturer support has been slow and unhelpful. We need an independent technical specialist to get this finished, using legitimate, supportable methods.
What we’ve established so far
Device update flow (observed)
1. Browser uploads ZIP to device via HTTP:
POST http://10.33.68.254/upload_file.php
2. Device stores it at:
/var/www/html/upload/update.zip
(Confirmed downloadable from http://10.33.68.254/upload/update.zip)
3. Browser triggers update via WebSocket service call:
ws://10.33.68.254:9090/
Service: /software_update with args {op:1, filename:"update"}
4. Device replies with service_response including status/info.
Two independent blockers identified
• Device disabled gate:
/software_update returns status:-1 and info:"设备已被禁用" (“Device has been disabled”).
• Region/lock cloud validation gate:
The UI performs cloud validation calls (scanner.fjdac.cn + myqcloud.com endpoints).
When offline / partial connectivity, it fails with DNS/TLS errors and logs “地区锁验证失败” (“Region-lock verification failed”).
When online, the UI can reach cloud but some requests return 401 Unauthorized. Console flags like “中国地区锁: true” and “串货标识: true” appear.
We have tooling & evidence
• Multiple DevTools captures (XHR + WebSocket messages)
• JSONL sniffer logs capturing:
• WebSocket frames (/software_update request/response)
• console logs
• network failures to cloud endpoints
• A bilingual technical report summarizing findings (English/Chinese)
• Example WS request/response showing the disabled gate:
• Request: call_service /software_update …
• Response: status:-1, info:"设备已被禁用"
Current complication
A Tampermonkey userscript (“FJD Fix v2.6”) can inject UI states (e.g., “installation complete / restarting”) without proving the backend accepted the update. We need rigorous validation against WebSocket traffic and actual device reboot/version.
What we need help with
We need a contractor to take ownership of finishing this and getting upgrades working reliably.
Primary deliverables
1. Definitive root cause analysis
• Confirm exactly what conditions cause /software_update to be rejected.
• Confirm what cloud validation requires (auth tokens/cookies/headers/region entitlements), including what causes the 401.
• Determine whether the browser environment used by automation differs from normal Chrome (headers/cookies/CORS/origin).
2. Complete capture of region-lock cloud calls
• Produce a reliable capture method that logs full request/response details for:
• scanner.fjdac.cn/.../chinaLockInfo?sn=...
• any related validation endpoints
• relevant myqcloud ping/config endpoints
• Identify required cookies/auth headers or login session requirements, if any.
3. Action plan + vendor escalation package
• Provide a clear list of what FJD must change server-side (disabled flag removal, entitlement/channel correction, token provisioning, etc.).
• Provide a concise technical evidence bundle (logs + call traces + translations).
• Draft an email/escalation note (English/Chinese) to send to FJD.
4. Practical resolution path
• Identify the most likely vendor-supported resolution path:
• backend flag clearing
• correct “Overseas/Global” firmware channel assignment
• provision of an official offline recovery image
• signed authorization token/file/code for upgrades
• Provide step-by-step instructions for our team to validate success.
Nice-to-have
• Validate firmware package structure/signature requirements and version compatibility (e.g., downgrade prevention, channel mismatch).
• Identify if the unit’s SN differs across modules (UI uses B vs C serials) and whether that affects entitlement checks.
Constraints / boundaries
• Work must be legal and supportable. We are not seeking unauthorized circumvention.
• We want to work with the manufacturer’s systems/entitlements, but need technical clarity to compel support.
Required skills
• Strong network debugging (Chrome DevTools, WebSocket protocols, XHR analysis)
• Experience with embedded device web UIs / OTA update flows
• Python/automation skills (Playwright/selenium, traffic capture)
• Ability to reason about auth flows (cookies/tokens/401/403)
• Bonus: familiarity with ROSBridge-style WebSocket messaging, nginx/autobahn stacks.
What we will provide to the freelancer
• Device access on LAN (10.33.68.254 web UI + WS endpoint)
• Existing sniffer scripts + JSONL logs
• Screenshots and prior PDF technical report (EN/ZH)
• Firmware files we’ve attempted (zip + .bin/.deb samples)
Please review the attached PDF before bidding for the project.