xone: Wireless Adapter Support (WiFi)

[Queuecumber]

I figured I'd open an issue for this, I have the wireless adapter "for windows 10", I haven't done much debugging with the xpad driver but I figured support for this is one of your goals. I can help debug this and/or provide any information you might need.

[pikim]

Another update is available.

The init steps are being executed, but some of the received messages differ from the expected ones. The dmesg output lists the differing ones. Up to now there's no reaction from the adapter. Neither does the LED light up, nor it starts sending messages as I would expect. I have no idea why it behaves like this and what else I could try. Maybe some timing is violated or any message wrong.

I think some input from you could help. Sadly haiduc32 didn't respond to my email.

To try this you have to do the following:

• pass a pcap-capture you made on Windows to the script create-xonew-init.sh: ./create-xonew-init.sh ./long-capt.pcap
• install the driver, but replace the xonew_init.c by the file the script generated before, while keeping the filename: sudo git clone https://github.com/pikim/xpad.git /usr/src/xpad-0.4 sudo cp ./long-capt.pcap.c /usr/src/xpad-0.4/xonew_init.c sudo dkms install -m xpad -v 0.4
• connect the adapter and view the output: dmesg
• maybe you have to increase the level before: sudo dmesg -n 8

[alfredkrohmer]

Hi @pikim. Without wanting to degrade your work, but I don't think that you will be able to get the dongle working at all by simply "bit-banging" the protocol that is seen on the USB. There is most probably a MT7612U wifi chip in the dongle that needs proper handling from another driver (because the protocol is non-trivial compared to the XBox 360 dongle) and there are a few drivers out there, but most of them don't really work on current kernels, though. So the steps would be to first find a working driver for the dongle and then try to talk the (kind-of-easy) wireless protocol on top of that driver either by (1) a kernel module which talks to the MT7612U driver/the Wifi instructure in the kernel in general or (2) a userspace driver which sends raw 802.11 frames or (3) a userspace program that controls the dongle with the nl80211 netlink interface (in the same way hostapd controls wifi chips in AP mode).

Unfortunately I won't be able to spend much time on this at least until July. I will try to get the code that I've got so far (that was actually able to connect to the controller and receive some seconds worth of input IIRC :) online on the weekend. That code features approaches (2) and (3) from above and works on any 5 GHz 802.11a dongle that has a proper Linux driver.

[pikim]

Hi @devkid. Your approach sounds much more sophisticated, of course. I thought I'd try it the same way as haiduc32 did and as far as I understand he was quite successful. But you're right: so far it doesn't work and I have not many ideas what else I could try, without knowing more about the protocol. As soon as one byte differs from what I expect, I don't know what to do. I'm also wondering how haiduc got it running this way.

Nevertheless it was interesting to get a little insight into how drivers work ;-)

Could you please explain on which code exactly your work is based or even upload a first draft? Do you know good sources to read about how those wireless chips work? For example, I don't understand the part with the firmware: why must it be loaded every time the device is connected? And in that case, I would expect a very different behavior from the device depending on the firmware that is loaded. That would also mean that one needs to know the protocol, as it may be completely different and proprietary, although running on the same hardware.

[alfredkrohmer]

I've uploaded the code here.

I don't really have an idea how those chips works, I usually rely on the drivers other people wrote for them :) The firmware must be loaded every time because the device doesn't have rewritable memory that could hold the firmware when power is lost. The firmware is usually closed source and only supplied through a binary blob. If the firmware alters the communication protocol, then yes, another driver would be required. But usually the firmware comes bundled with the driver (at least if supplied by the vendor).

E.g., the driver for the Xbone dongle that is available directly from MediaTek does not compile on current kernels. But there are other drivers out there; this one looks rather promising. The last time I tried, I got it to compile and recognize the dongle as a wifi adapter on my system but it crashed the kernel really fast.

[pikim]

Thank you very much, I'll have a look on it.

I tried the driver from https://github.com/jurobystricky/Netgear-A6210 and get the attached output via dmesg. Looks also promising, I think. And seems to be stable so far. a6210.txt

[haiduc32]

@pikim, I actually sent you 2 mails.. can you please check your spam/trash folders?

some thoughts:

• there are some timing issues, some delays are required between some of those initialization messages (please check my code for that)
• the code works with my dongle/controller so there might be some hardcoded serials/ids, check my google doc for the data that I used and spot the serial/ids (check all of them as I might have mixed data from different people): https://docs.google.com/document/d/1AyrhC3gnVAmZyjlCGeJmPauCopRkLN56NyjHiuj8b14/edit (red and blue bytes)

a third thought: if you have the latest controller or updated your controller, then all bets are off.

[alfredkrohmer]

@haiduc32 The blue and red bytes starting with 62 and 7e are the MAC addresses of your dongle / controller.

[pikim]

@devkid I had a look on your code and I like that approach, as it's not as tentative as the the other one.

I also had a look a the driver you linked to and after that it seems to me that most of the initial USB communication does configure the wireless adapter (I tracked down some packets from the USB dumps). But as we don't know how the firmware works that configuration does not help us.

Does that mean the MS adapter can only be used as standard MT7612U adapter? Did you use it this way? But what about eventual IOs then? What do you think?

[alfredkrohmer]

But as we don't know how the firmware works that configuration does not help us.

Does that mean the MS adapter can only be used as standard MT7612U adapter?

I would suggest to not spend time on "porting over" the initialization code from the drivers that are available but instead to actually use the adapter as a standard WiFi adapter and implement the protocol to talk to the controllers on top of that layer.

Did you use it this way?

For the testing when writing that code I used the builtin WiFi in my laptop (it is the only 5 GHz "dongle" I own). But I tested the adapter again with the driver you linked to and it seems to be working quite ok (it was able to scan for WiFi networks, but I didn't get it running in AP mode).

But what about eventual IOs then? What do you think?

What do you mean with IOs? As soon the adapter / driver is working in AP mode (or is accepting raw packets for transmission) you have everything that is needed to talk to the controller.

[pikim]

But I tested the adapter again with the driver you linked to and it seems to be working quite ok (it was able to scan for WiFi networks, but I didn't get it running in AP mode).

In the meantime I stumbled upon another repository which could be interesting. Maybe the changes from here could be helpful? But I didn't try that version, yet.

What do you mean with IOs?

Anywhere in the MT7612U or A6210 drivers I read something about input and output pins that can be set or read. Under special circumstances it could lead to problems, for example when one output has to be set. Or when it must not be set to avoid hardware damage.

[pikim]

But I tested the adapter again with the driver you linked to and it seems to be working quite ok (it was able to scan for WiFi networks, but I didn't get it running in AP mode).

In the meantime I stumbled upon another repository which could be interesting. Maybe the changes from here could be helpful? But I didn't try that version, yet.

Of course my last statement was rubbish: the code doesn't run in AP mode, because they threw it out some months ago as they didn't need it.

Do you have an idea what was the problem with Ulli Krolls mt7612u? Did you try it recently or some time ago? I spent some hours to get it compiling, but I didn't get further, yet...

[braxion]

@pikim: any news or success at this issue?

[pikim]

@braxion Unfortunately not. I didn't proceed with the xpad approach. I like devkids suggestion to use the adapter in a real wifi mode as it seems more promising. Unfortunately the drivers I tried so far don't really work at the moment. But as Ulli Krolls mt7612u is under permanent development, I hope it will be working soon. If not I'll try to proceed with xpad anyway.

[alaindesjardins]

I was going to buy a bluetooth version of the xbox one remote since the wireless adapter doesn't work but then I realized I wouldn't be able to use my Elite Controller since there is no version of that with bluetooth.

I hope you guys figure it out since I know I can't. I appreciate it :)

[FliesWithWind]

Hey guys,

Any news on the development? I'm planning to buy 2 bluetooth controlers and wireless adapter, since from what I've heard bluetooth won't handle two controllers. Really wish I could use it with my raspberry. I could try helping out a bit with the development.

[alfredkrohmer]

No progress from my side so far. I'll have more time starting from July.

[thkrz]

@FliesWithWind, two Xbox bluetoothcontroller work good under Linux. I gave up on the wireless adapter as well, and bought the bluetooth version of the controllers. Just make sure you have the right adapter Class 1/EDR.

[yjbbrqw]

Can someone give a summary of work done since the issue was submitted? I'd like to help . (Althogh xone controller works fine via BT on my linux, but it's still annoying being unable to use my wireless adapter.

[Adubbz]

From what I can tell the actual implementation is still up in the air, so here's my summary of the information known so far. It's mainly just mashed together what people have said in a number of issues. Someone feel free to correct me if anything is missing.

The wireless adapter is a MediaTek MT7216US NIC, which is a WiFi adapter capable of using the 5.2 and 5.8 GHz bands (https://fccid.io/C3K1713, https://github.com/paroj/xpad/files/139111/TDS_XboxOneControllerPlusWDAforWindows_1510A.pdf).

Under Windows, there is a stock driver for the adapter itself (mt7612US.sys), a custom protocol driver (xboxgip.sys (Xbox Game Input Protocol)) utilising that, and a standard HID stack on top of GIP. It has been observed that WiFi packets were sent as long as the controller is connected to the dongle (i.e. power on and the X LED being on), and beacons are always sent. WiFi dumps for button presses and powering on/off the controller can be found at http://dl.devkid.net/uNqiOXi32H2Ul-_pEZtUHw/xbone-wireless.tgz. Images of the adapter board can be seen here https://github.com/360Controller/360Controller/issues/156#issuecomment-231540802

There is firmware included for the adapter (FW_ACC_00U.bin) with a striking similarity to https://github.com/openwrt/mt76/tree/master/firmware (mt7662_firmware_e3_v1.9.bin), the open source driver for the MT76x2 family. This firmware presumably must be loaded every time during initialization as the device lacks rewritable memory to hold it when the power is lost.

There have been numerous captures of the USB traffic using tools such as USBPcap (http://desowin.org/usbpcap/index.html). Packets in these captures have a base packet header appended following the format specified here: http://desowin.org/usbpcap/captureformat.html. The basic pattern which can be observed from this is as follows:

1. Adapter polls for device
2. Controller says it's alive
3. Adapter requests basic configuration information
4. Controller says it's a usb 1.1 device that's not powered by the wire and supports remote wakeup
5. Adapter requests more config information
6. Controller identifies itself as a proprietary interface -- presumably Microsoft specific -- and lists 8 endpoints that probably map to the buttons
7. Controller sends extra packet that's not standards compliant but is probably used as part of the configuration
8. Adapter and controller handshake to confirm they understand each other
9. Adapter and controller ping back and forth with each other very frequently, with the controller including status information that probably includes buttons currently pressed

There are two schools of thought surrounding how this should be implemented:

1. Recreate the packets sent in the USB captures
2. Find a wireless driver for the dongle itself, and implement the Xbox GIP protocol on top of that

haiduc32 has documented some features of the initialization and control USB packets here: https://docs.google.com/document/d/1AyrhC3gnVAmZyjlCGeJmPauCopRkLN56NyjHiuj8b14/ and managed to receive input commands from the controller via wireless on macOS: https://github.com/haiduc32/360Controller/blob/master/WirelessGamingReceiver/OneWirelessGamingReceiver.cpp

devkid has done some work investigating the WiFi protocol. Raw 802.11 MAC frames appear to be being sent over the USB connection, taking the form documented over at https://github.com/paroj/xpad/issues/25#issuecomment-258642789. devkid's additional notes can be found at https://gist.github.com/devkid/4b3bd50760504d1b93ea684cfd3ed895

Sources: https://github.com/paroj/xpad/issues/14 https://github.com/paroj/xpad/issues/25 https://github.com/360Controller/360Controller/issues/156

[pikim]

There are two schools of thought surrounding how this should be implemented:

1. Recreate the packets sent in the USB captures
2. Find a wireless driver for the dongle itself, and implement the Xbox GIP protocol on top of that

The point with solution 1 is that one also receives the detected WiFi networks all around and must be able to handle the changing names and so on. Could be possible, but it would be better to understand the communication. Therefore solution 2 would be preferable but at the moment there's no working driver available for the MT7612U. Ulli Kroll is working on one and apparently there are plans to modify OpenWRTs mt76. While the first one crashes after a short time, modifying the second one for USB usage hasn't even begun.

There would be a third solution by using WiFi dongles that are known work under Linux, but I have neither such a dongle nor the knowledge to do this. But it could be learned, I think. So if anyone knows a 5GHz dongle that is well supported it would be great to know.

[tatsujb]

I have a Tl-wn823n I don't know if it would do the job or not.

[pikim]

In the meantime I sold my WLAN only controller and I plan to buy a Bluetooth version or a completely different controller. But that means that I won't work on this topic any more. Sorry guys!

[noabody]

Thanks to you and everyone that contributed to this, "the hard fight". Sometimes those fights aren't won but hopefully you took something valuable away from it.

[alfredkrohmer]

@noabody As far as I'm aware of, the controller tries to connect to any valid "dongle wifi network" it sees. If the button on the dongle was pressed before, the dongle just accepts the connection.

[goldsteal]

Any update on this?

Not actually sure which one I have but given that "lsusb" only gives out "Bus 003 Device 020: ID 045e:02e6 Microsoft Corp." I assume it is the wireless LAN i.e. wifi version?

[tadly]

@goldsteal all versions are lan. The newer ones just additionally supports BT. The receiver is for lan only (does not have BT. You have to "provide" that yourself.) Just put your controller into pairing mode, whip out your phone and see if a it shows up in the list of available bluetooth devices. <- Easiest way of testing.

[goldsteal]

@tadly Will try that... Thanks.

[kylewlacy]

For anyone else who's been following this issue, I opened bounty for the sister issue in 360Controller about the Wireless Adapter (360Controller/360Controller#156). I'm hoping that a bounty for that issue will lead to a solution for both projects. I left a comment about the bounty and a collection of resources about this issue over there: https://github.com/360Controller/360Controller/issues/156#issuecomment-421885062

[Two-Tone]

Holy hell, that's a huge bounty.

Question! Why use that repo's issue instead of this one?

[kylewlacy]

@Two-Tone I actually use Linux day-to-day but I have used 360Controller before and I expect to use it in the future. I had to decide between opening the bounty for the 360Controller project or the xpad project. I ultimately decided on 360Controller mainly because it seems to be more popular (more stars, more contributors), so the impact of adding it to 360Controller will be bigger.

Of course, I'm really hopeful that someone will be able to add it quickly to this project once the patch has landed (I might even take a stab at porting it myself if it doesn't seem too difficult)

[Two-Tone]

There may be more users and more contributors to that project, but you'd likely get noticed by many more developers overall since a large chunk of the Linux user base are developers due to how technical it can be, while a large chunk the user base on MacOS is not because it's not aimed at them.

[goldsteal]

I just added 5 bucks to the bounty. :D Just to show I still want this.

I am also pretty sure that when it's working in one project it will be easier to consider for the devs of xpad etc. to implement it since they can reuse some of the code - as long as the licenses allow it.

So maybe someone will take another crack at it. We shall wait and see. Also: a 1000$ seems like a high bounty for one guy with some spare money. Hope you can afford it mate. Don't be too stupid. Bankroll management is an important skill and all ;) That being said it's probably still more than deserved for anyone who can get it done considering how much full-time development this will probably need if you just price it at the going rate of a really good software engineer.

[go0ro0]

$15 also added, I am hoping for eventual support for android, specifically Nvidia Shield.

Regards

[JMmontilla]

Any news?

[tremendoza]

Any chance any of the work going on here could work on the internal Xbox one WiFi/sync board. I'm messing around with it and got 2 USB devices that windows sees both as "Marvel Wireless Device" with Hardware IDs USB\VID_1286&PID_2045 and USB\VID_1286&PID_2040. Thanks.

[CodeCanna]

So I'm guessing this isn't going anywhere soon? I have Windows 10 and would like to to help if possible.

[medusalix]

I had some success during my recent experimentations with the wireless dongle: post. As there were only a few responses to my post on the 360Controller issue, I'm hoping that this will get more attention right here. Please help me out with the additional Wireshark captures I need to continue the development of the driver.

[sudo-tee]

I really hope that one day it will be compatible.

[Littleweisheit]

@paroj medusalix have release the Wireless Adapter source code. https://github.com/360Controller/360Controller/pull/935#issue-323670882

[alfredkrohmer]

Partially working implementation for Linux that displays the input data on the terminal: https://github.com/devkid/xboxone-wifi-controller

It utilizes the kernel driver for the chipset in the dongle (limitation: it only allows to broadcast beacons on channel 40) and sends/receives packets over a raw socket. It kind-of-works, but not reliably (I get constant reassociation requests that lead to short drop outs of input data, I haven't figured out why, though.)

[medusalix]

@devkid That's really awesome! Especially considering your gist was a great starting point for my reverse engineering efforts. Unfortunately, I can't help you with the reliability issues you have, as the MT76 Linux driver is much more complicated than my simple macOS implementation 😄. Also, you should definitely get in touch with @atar-axis, he's the maintainer of xpadneo.

[wgpierce]

Thanks @medusalix for the contribution and congrats on the bounty. I'm willing to fund a similar bounty in the footsteps of kylewlacy to accelerate the Linux development. But, I'm not sure if the bounty would belong to xpad in this issue, xpadneo in this issue or another separate driver because it's neither bluetooth nor wired.

[antimech]

Hello guys. I have Xbox One X controller with wireless "Windows 10 only" adapter. Let me know how I can help you please.

[wgpierce]

OK as promised, I've created a similar bounty in the footsteps of kylewlacy at https://www.bountysource.com/issues/81215868-port-the-dongle-driver-from-osx for the xpadneo project for Linux support of the driver. I've created the bounty on xpadneo, but I'd count it towards whichever repo eventually has the code, whether that be xpad, xpadneo, or another repo.

@medusalix @devkid @atar-axis @paroj have a look!

[goldsteal]

Contributed the usual 5$ "I am still here... sometimes." Bonus.

Awesome to see that this went somewhere. :)

[ibex-are-goats]

Looking forward to getting the low latency xbox adapter working in raspberry pi linux apps!

[medusalix]

It's finally ready for testing 😄. I'd really appreciate your feedback concerning the compatibility with certain controllers and the older dongle, so please try give it a try.

[ibex-are-goats]

It's finally ready for testing . I'd really appreciate your feedback concerning the compatibility with certain controllers and the older dongle, so please try give it a try.

I'm hyped to congratulate you for your success so far! Thank you for contributing this to the community so we can all have some fun. :) I look forward to everyone testing this for you and giving lots of good feedback. Happy december everyone!!!

[wgpierce]

Excellent work @medusalix and all others who worked on implementing support for the Xbox One wireless adapter.

@paroj in light of medusalix's xow (a userspace driver), should this issue be closed? Would any future kernel-mode driver implementations (such as bytewarrior's initial implementation) be outside the scope of xpad?

[paroj]

yes, a kernel mode implementation would be out of scope, similar to how this does not handle the Bluetooth devices. I will close this and reference the xow driver in the readme.