Can this driver be hacked to support WN725Nv1 (0bda:8179) ?

[alecmuffett]

Hi! Yet another Raspberry Pi question.

I've inherited an old WN725N(v1) USB dongle which - according to research - contains a RTL8188CUS and which is identified on lsusb as:

Bus 001 Device 005: ID 0bda:8179 Realtek Semiconductor Corp.

...which (curiously/annoyingly) is the same ID (0bda:8179) as used by the TL-WN723N(v3) RTL8188EUS

There are a lot of people talking about the WN725N(v2) device which apparently contains a "RTL8188EU" and is a different ID; this one is slightly older, slightly weirder, and has (as mentioned) a clashing ID.

Grepping the source suggests that related devices are supported: ./os_dep/linux/usb_intf.c

        {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8176)},/* 8188cu 1*1 dongole */ \
        {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8170)},/* 8188CE-VAU USB minCard */ \
        {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817E)},/* 8188CE-VAU USB minCard */ \
        {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817A)},/* 8188cu Slim Solo */ \
        {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817B)},/* 8188cu Slim Combo */ \
        {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817D)},/* 8188RU High-power USB Dongle */ \

...in fact this device would probably have been designed around the time of the 8188cu Slim Solo, since that is the numeric next ID.

So I'm wondering what would be needed to get this to work? I presume the reason this dongle is not cited in the driver is because of the ID-clash with a subsequent product.

If I manually add an entry for 0x8179 and blacklist or remove the conflicting driver, what are the odds that this might work?

[edit/ps: there are a handful of pages (eg: http://elinux.org/RPi_USB_Wi-Fi_Adapters) which suggest that suggest the 'v1' dongle should work, but it does not. Latest Raspbian refuses to see it as a potential interface.]

[dlech]

If it really is a RTL8188CUS chip, then chances are pretty good that it will work.

[pvaret]

Possible: yes, everything is possible. :)

A good idea: not sure. When a device based on a chipset purportedly supported by this driver doesn't work, it's often because that device requires custom code to handle its power management (source: Jes Sorensen, author of the rtl8xxxu mainline driver). That can be done, given time, domain knowledge, and either excellent reverse-engineering skills or documentation of the device's specs. But I'm unsure it's worth it, as opposed to just trying out the rtl8xxxu driver and filing a report if it doesn't work.

You may also want to try and file a bug with upstream (Realtek, of which this repo is but a fork with minor compiling fixes), but honestly, I wouldn't hold my breath.