[Prism54-devel] X2 firmware file format

[Jean-Baptiste Note]

Hello Sebastien, dear list,

Sebastien B <sebastien.b at swissinfo.org> said :
> Hello,
> I've got the GW3887-based WG111 from DG4OAQ today :)

That's great !

> There is a real problem with the firmware. I took the 2.7.0.0 firmware from 
> the XH8196 driver and prepended an X2 header that I took from the USB logs. I 
> just edited a field which is surely the size of the firmware to make it match 
> the length of the 2.7.0.0 firmware. It didn't work. I'm afraid the firmware 
> in the XH8196 is only for ISL3886-based PCI devices.
> Here is what the driver printed to the syslog (there seems to be race 
> conditions or similar bugs messing all up...) :

Yep, the driver is not really tested, as you may have understood :)
about this driver : given that i didn't need it up to now for reverse
engeneering, i'm thinking about "bringing it down" (removing it from
public disctibution, leaving it available privately). It seems it'll be
used by few people anyways, and we have no right, according to the
license, to redistribute modified versions of it, and i don't want to be
tainted for redistributing it illegally.

> So, if you find an USB Windows driver which contains a firmware that features 
> a "bra" compatible with the UMAC library in the XH8196 driver, I am really 
> interested. I posted some time ago an simple program which can be used to 
> check easily whether a firmware is compatible, I'll put it up in a tarball 
> with Makefile and so, so that you can use it easy.
>
> I'm willing to carry on any other test with the device.

0/ I completely agree with you about the nature of the firmware. This is
not what we want, only for 3886. I'm very upset about the possibility
that the softmac we have may not be able to parse the bra for the 3887
firmware (the different API in the usb driver points to another, more
recent, softmac library).

1/ Did you try to extract the firmware from the USB logs ? This is what
i did at first for the standard USB devices, and it works really well,
this way you're 100% sure to get what is sent to the device. Then use
this precise firmware to carry out your tests. Or maybe i missed
something and this firmware has an incompatible bra ? -- in this case
i'm really pessimistic (see above).

2/ The protocol in those devices seems to be text-based. Unless you're
reading ascii very fluently, i'd advise you to take the USB logs and
print the ASCII characters corresponding. Only up to the end of firmware
upload and 10 next packets. The rest is basically the same as in the
other devices.

3/ As you may have seen, the protocol expected in the XH driver and the
one embodied in the USB logs is not the same. Just for a quick
difference, the USB logs show a packet sent that is "<<<<" for
reinitialization, where the driver only sends one "<". There are many
other discrepencied. You may need to adjust this in the driver; having
no device, i didn't care to do it.

4/ For these devices, if we get but one OK firmware and corresponding
frequency change packets, we're done, as the freq change packets seem to
be the same and only bound to the firmware uploaded.


Now, as far as protocol reverse-engeneering is concerned : what i'd
really like now is a driver able to provide logs for HostAP mode... Is
the TIVO driver able to handler this ? Is there any source code
available ?

Back to work now...

-- 
Jean-Baptiste Note
+33 (0)6 83 03 42 38
jean-baptiste.note at wanadoo.fr