Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USB Disconnects at ISO15693 emulation #281

Closed
mschmitt-pf opened this issue Oct 7, 2020 · 7 comments
Closed

USB Disconnects at ISO15693 emulation #281

mschmitt-pf opened this issue Oct 7, 2020 · 7 comments

Comments

@mschmitt-pf
Copy link

Hi,
just updated firmware to 2020-09-28 version and got the issue, that USB Disconnects at ISO15693 emulation when external Reader starts to access the emulated tag.

From Reader side a inventory (0x26, 0x01, 0x00 + CRC ) is requested.

In that moment the USB crashes and need to re-plugged.
Windows 10 x64 reports:
"Windows has stopped this device because it has reported problems. (Code 43) A request for the USB device descriptor failed."

Tried firmware with date 2020-09-11 and the issue does not occur with this version. I can use this version for the moment.

Hope you can find the root cause of this issue.

Thank you in advance.

@maxieds
Copy link
Contributor

maxieds commented Oct 8, 2020

@mschmitt-pf @ceres-c
I am not sure if this is a fix, but a couple of days ago, I responded to a RRG developer's issues with Mifare authentication introduced by code merged recently. My feedback based on a dry read (without live firmware testing) of those source code changes are found here. One of the possible causes for that broken functionality that I observed in the comments to the pull request was that some calls to add the two CRC bytes to the returned buffer were removed. Perhaps that is a patch for the problem observed in this thread?

@ceres-c
Copy link
Contributor

ceres-c commented Oct 13, 2020

Sorry for the late reply.
I haven't faced this issue when I was writing ISO15 code and I was testing the chameleon connected to my laptop via USB. On the other hand: I was using linux and I have not tested this on a Windows install.
Have you tried using a different machine or a live linux distro?

Also: Currently my chameleon is crashing the cdc_acm module in linux when changing SETTING option via minicom/screen. I thought it was the result of a funny flash, but it could be related to this issue and quite an interesting bug. Still, when I asked a friend of mine to test the public codebase with his own chameleon he did not face the issue. I haven't had the time to look into this bug, but it would be interesting to find out why and how the kernel module crashes, since it could lead to interesting developments (we all know usb sucks)

@ceres-c
Copy link
Contributor

ceres-c commented Oct 13, 2020

This evening I spent some time toying with this issue and I had intermittent results.
I built the firmware with the latest commit (410a26a) and it gave me issues. Again, cdc_acm was crashing, but this time around it was not triggered by settings switch. Instead, it failed when I was trying to read the Chameleon with my phone.

I'll look into this in the coming days, I hope

@ceres-c
Copy link
Contributor

ceres-c commented Oct 14, 2020

The issue should be fixed reducing code size: implemented a warning before flashing in #284

@david-oswald
Copy link
Collaborator

Can we close this once #284 is merged then?

@ceres-c
Copy link
Contributor

ceres-c commented Oct 16, 2020

I believe so. Paying attention to code size has solved simiar issues on discord

@ceres-c
Copy link
Contributor

ceres-c commented Jan 31, 2022

This can be closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants