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

[Test Failed] TestDiscovery expects announcement for device type 0xffff which is no valid MEI #33697

Closed
Apollon77 opened this issue May 31, 2024 · 4 comments · Fixed by #33715

Comments

@Apollon77
Copy link
Contributor

Apollon77 commented May 31, 2024

Test issue(s)

I know that TestDiscovery.yaml is a chip internal test but it expects that the announced device type is 0xffff which is not any valid MEI definition for a Device type according to chip specs. The highest allowed non-manufacturerspecific devicetype should be 0xbfff (aka 49151).

Even tho the chip test applications are just reference implementations I think they should not use out of range data and formally invalid IDs

Platform

No response

Anything else?

No response

@Apollon77 Apollon77 changed the title [Test Failed] TestDiscovery expects announcement for device type 0xffff which is no valie MEI [Test Failed] TestDiscovery expects announcement for device type 0xffff which is no valid MEI May 31, 2024
@bzbarsky-apple
Copy link
Contributor

bzbarsky-apple commented Jun 1, 2024

It's running against all-clusters-app. There is no "valid" device type that can be used for that thing, obviously....

Probably it should just use a vendor-scoped device type in one of the test vendor namespaces.

@Apollon77
Copy link
Contributor Author

Probably it should just use a vendor-scoped device type in one of the test vendor namespaces.

that would be the most simple option, I agree

@bzbarsky-apple
Copy link
Contributor

One other note: the test expects whatever device type id is specified on the command line, defaulting to 0xFFFF. When running it against anything other than all-clusters-app, the right data should be passed on the command line.

bzbarsky-apple added a commit to bzbarsky-apple/connectedhomeip that referenced this issue Jun 3, 2024
We were claiming a device type of 0x0101 in the Descriptor DeviceTypeList on
endpoint 1, but claiming a device type of 0xFFFF (not even a valid value) via
DNS-SD advertising.  Align our advertising behavior with the data model values.

Fixes project-chip#33697
@Apollon77
Copy link
Contributor Author

@bzbarsky-apple ahh ok yes I could override that setting ... will look into this too.thank you

@mergify mergify bot closed this as completed in #33715 Jun 5, 2024
mergify bot pushed a commit that referenced this issue Jun 5, 2024
…33715)

* Fix advertised device type for all-clusters-app to match data model.

We were claiming a device type of 0x0101 in the Descriptor DeviceTypeList on
endpoint 1, but claiming a device type of 0xFFFF (not even a valid value) via
DNS-SD advertising.  Align our advertising behavior with the data model values.

Fixes #33697

* Address review comment.
@github-project-automation github-project-automation bot moved this from Todo to Done in [Build] Build Issues Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants