Any ideas how I can calculate the response to the challenge code from AT!OPENLOCK to get into engineering mode on my EM7565? It has FCC auth enabled and I’m not able to disable it without unlocking it.
Apparently the algorithm for generating it has changed in this version.

Related forum thread: EM7455, Deactivate Low-Power-Mode

You could send FCC auth with MBIM or QMI too, is this suitable?

The problem is the latest Windows drivers don’t seem to support the FCC authentication command; it works fine on Linux with networkmanager.


As per the posting that you have quoted the guys there were unable to unlock the device there as well, this is because the at!unlock command is used to unlock the level 3 commands (the level 2 commands are unlocked using at!entercnd=“A710”) which are for Sierra Wireless internal use only as they can allow you to perform some pretty dangerous operations and easily brick a unit, allow it to perform outside of spec, etc. Sierra. Level 3 capability is not enabled on any production unit.

The device that Rex_alex was using had to have been individually unlocked for him for a specific reason by someone inside

The response to the at!openlock command is generated by an internal tool.

If you have a specific need then you will need to go back through your commercial channel to get the support to ask for this.



If this is the case and it’s impossible to get into the engineering mode, is there any way to make the driver perform FCC authentication on Windows? This is not mentioned anywhere in the documentation.

Sadly, this modem was OEM from a Lenovo laptop, and they have already refused to give me support on this matter. There are no valid drivers on their website either.



The short answer to this is no. The unit was clearly sold to a PC OEM so as far as Sierra is concerned it is theirs, we cannot support unlocking of it for lots of different reasons.



I would disagree. The customer bought the device so it’s clearly not the OEMs anymore.
But the driver should perform FCC Auth nonetheless. So this might be a bug.

And seeing that Sierra has built in such a customer annoyence (other manufacturers do no such thing) you have a responsibility to fix the bug at least. Or better: don’t ship devices with such a nuisance.

A quick check on the Gobinet source code shows that it’s at least enabled for 9x15 devices, not sure if EM7565 needs that too.

   if (is9x15)
   // Set FCC Authentication
1 Like

It might be possible that it’s detecting it based on the USB PID - the PID 90C3 was what the EM7565’s OEM configuration was, and this is custom (Lenovo?), not recognised by the generic Sierra Wireless driver - so I changed it to 90B1 with AT!USBPID=90B1 which was detected correctly (and is the factory default PID). There are two other PIDs that I’ll try as well, perhaps one enables the FCC authentication mode on the driver.

Just tried this. Sadly, none of the three APP PIDs (9091, 90B1, 90C1) makes the driver do FCC authentication.


We have built a product to a customer specification and they have subsequently bought that product, directly, from us, the requirement was to be able to lock the device down to be used with their hardware only to prevent exactly this happening.

If other customers would like to have a standard product from us that works in an unrestricted way (within the operation specified in the PTS which does not specify FCC auth (which I have still not really figured out what it is)) then they are free to purchase these from any of our authorised distributors.

The FCC auth option remains a level 3 command only and as such I stand by my previous comments on this subject, it is not a bug.



The issue is, this card is in Lenovo hardware, a ThinkPad T580. So if it’s as you say, “to prevent exactly this happening”, the option is preventing use of the card in a genuine Lenovo product. The problem is Lenovo provides no drivers whatsoever that I can find on their website for the EM7565. (And yes - I’ve already tried contacting them about this.)

So the result is I’m forced to use the generic drivers, which are not set up correctly to do FCC authentication.

It probably still is a bug. The driver should send the required message regardless. If it doesn’t it’s a bug.

And now your customers customers want to use the device and they end up here. Facing a (likely?) bug. You know why they are here? Because Lenovo can’t help with those issues, probably because they just forward them to you.


Given the standard product does not support this means that the capability to change it is not a ‘bug’ it is a feature which our customer has chosen to implement i.e. lock it to a specific BIOS, it is not up to us to unlock it. It really up to the laptop manufacturer to support their product (which they do within the T&C’s under which they sell their products), it is beyond our scope, remit and more importantly agreement with the PC OEM to perform these operations.

I do not wish to get into an argument about this but it is a corporate position and generally why questions relating to PC OEM products like this do not get answered on the forum by Sierra people, I tried because it was not initially apparent that this was a PC OEM unit.



It was. “Normal” devices don’t have FCC Auth, so it was clear that this was an OEM device.

The bug I am talking about is that your driver does not send the FCC Auth for the EM7565 on Windows. It is a bug because you send it on the Linux driver (although for the 9x15 series according to source code, but it might still get sent on other devices).
Why is this important? I doubt that Lenovo will alter the drivers they get from you.

Btw I haven’t seen devices locked to a specific BIOS, how would you acomplish that anyway? Those are USB devices. The Lenovo BIOS might check the USB-ID, but that’s not a restriction from your side.

There might be an issue with your drivers, deal with it, don’t redirect users to different places without a positive outcome.

Lenovo T580 uses Fibocom L850-GL 4G LTE-A cat 9 as WWAN option. EM7565 won’t work on it as the BIOS will not white list it.

Might still be whitelisted. The BIOS only checks for USB vendor/product id. Seeing that those modems always have similar ids, it’s not uncommon that they might have the same one. (Can be changed too)

It definitely works and is whitelisted in the BIOS. The EM7565 is listed as an option on the P52s, which is almost a hardware equivalent to the T580, so it is not impossible that it works, however the driver is not listed on the website for either the T580 or the P52s.

Just did some digging around out of desperation and discovered the SwiSetFccAuth exported function in GobiApi.dll which is distributed with the drivers. Sadly, I haven’t been able to work out what parameters it takes yet, since I don’t have access to the documentation… if someone with the SDK could provide me with them that would be awesome.