MapToStruct: Field not found: MTU

[Elara6331]

I have updated my computer (running Archlinux), and have begun receiving the following error: MapToStruct: Field not found: MTU

BlueZ version: 5.62-1
Dbus version: 1.12.20-1
go-bluetooth version (from go.mod): v0.0.0-20210812063148-b6c83362e27d

This issue seems to be caused by the BlueZ 5.62 update as downgrading the package makes the issue disappear.

[muka]

The package has not been updated recently, probably some API has changed sent from my phone

…

On Sun, Oct 24, 2021, 02:01 Arsen6331 ***@***.***> wrote: I have updated my computer (running Archlinux), and have begun receiving the following error: MapToStruct: Field not found: MTU BlueZ version: 5.62-1 Dbus version: 1.12.20-1 go-bluetooth version (from go.mod): v0.0.0-20210812063148-b6c83362e27d This issue seems to be caused by the BlueZ 5.62 update as downgrading the package makes the issue disappear. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#143>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZKVIUPLOAY5O7WRKXL5TUINEEBANCNFSM5GSZHWJQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[Elara6331]

I thought this might be an issue with using an old version of go-bluetooth, but it still happens with latest, so I think something changed in BlueZ 5.62

[muka]

Ok, I'll keep this open and provide an upgrade when I can commit some time. Feel free to move forward and provide a PR eventually. Thanks

[tomaszkubacki]

I've got similiar issue

go run main.go discovery

the output is:

ERRO[0000] Error: MapToStruct: Field not found: Roles
exit status 1

(default - current Ubuntu 21.10)
Bluez version : 5.60

[OrgansWithoutBodies]

https://patchwork.kernel.org/project/bluetooth/patch/20210826164211.2936133-1-david@lechnology.com/ the API change in question that caused this afaict

[muka]

Merged PR #145 Please reopen if it still an issue

[sbinet]

the fix from #145 hasn't been incorporated into master. was it on purpose?
(I was a bit confused to get the same error even though I did go get -u github.com/muka/go-bluetooth@latest)

[muka]

If it is on 5.62 master may not be aligned as it usually align with ubuntu releases (21.10 ships 5.60).

Can you try with branch bluez/5.62 or regenerate the sources using this command BLUEZ_VERSION=5.62 make all

Thanks

[sbinet]

I could fix the error by explicitly specifying the commit from the bluez/5.62 branch.
my question was more on whether it was on purpose that fix wasn't merged into master.
and it seems it was, as you follow Ubuntu releases.
thanks :)

[muka]

The code is generated from bluez docs, it is possible that the modification has been overwritten by code generation

[sbinet]

it seems to me they live on 2 different branches.

* 9857391 (origin/master, origin/HEAD, master) added usage section
* 48824ca override MediaPlayer1.Track to an actual type, fix #133
| * 1c7f879 (HEAD -> v5.62, origin/v5.62) generated v5.62
|/  
* 62e38ae (origin/v5.60) update docs
* 7bf4032 - fix parser on broken properties - remove experimental from file names
*   b99792b Merge pull request #145 from OrgansWithoutBodies/master

to reiterate: 1c7f879 is working fine on my ArchLinux box. (well, the MTU issue is not there)

[muka]

Thank you, I will try to standardize the releases!

[andig]

I‘ve just had this reported in evcc-io/evcc#2627. I‘m not sure how to proceed: downgrade to working commit or upgrade master? Upgrade underlying Alpine image?

[muka]

On master you should find the version compatible with 5.60. There are also branch with different bluez version

[andig]

User is running 5.63 (evcc-io/evcc#2627 (comment)) which should have MTU as far as I understand. master shows mentioned error. I had expected user to run older bluez version and hence have the error, but why with 5.63?

[muka]

Could you try to use branch/5.62 ?

https://github.com/muka/go-bluetooth/blob/bluez/5.62/bluez/profile/gatt/gen_GattCharacteristic1.go#L117

[muka]

I added the versioning reference on README and also generated a version for 5.63. I cannot test it right now, feel free to open PR with improvements

[andig]

Could you try to use branch/5.62 ?

How do I do that?

❯ go get -d github.com/muka/go-bluetooth@bluez/5.63
go get: github.com/muka/go-bluetooth@bluez/5.63: invalid version: version "bluez/5.63" invalid: disallowed version string

[muka]

Good point, I added git tags and should play better with go get

go get github.com/muka/go-bluetooth@bluez-5.63

If you have suggestions on how to structure versioning of the module in a way that fit your use case I am happy to discuss.

[andig]

For reference: golang/go#51281

If you have suggestions on how to structure versioning of the module in a way that fit your use case I am happy to discuss.

I'm lacking the bluez insights to do so. Have asked user to retest 5.63 branch.

[andig]

I think the problem I've had is that I've upgraded master from

github.com/muka/go-bluetooth v0.0.0-20211122080231-b99792bbe62a

to

github.com/muka/go-bluetooth v0.0.0-20211227073548-985739196620

The first commit had MTU, the latest nicht. Not sure how that happened as it seems that MTU is a feature of newer bluez releases?

[muka]

Master refer to 5.60 which may not have MTU?

[andig]

Right. What is confusing is that master had MTU in an older commit:

go-bluetooth/bluez/profile/gatt/gen_GattCharacteristic1.go

Line 117 in b99792b

MTU uint16

[muka]

It's my fault, I merged a contribution with that part but other that was broken. Recent commits fixed that. Dbus versions need to be addressed but I need to find a proper way. Do you have an idea?

[andig]

That's good because the failure is now explainable. I have unfortunately no suggestion about dbus- I'm only consuming this module without deeper Linux experience.

[muka]

Glad it is solved, my question is about a good way of managing go library versions in respect to the underlying blueZ version.

[andig]

Two options I could imagine:

• separate go-bluetooth and go-bluetooth/bluez modules with different versions OR
• go-bluetooth gets a version policy of supported bluez versions (assuming you can support multiple ones at the same time). One release per bluez version with patches to previous versions per policy (i.e. only last 3 bluezs will be supported).

[muka]

Thank you, I will evaluate the effort for those approaches. It's definitely something to address. Please close if resolved. sent from my phone

…

On Tue, Feb 22, 2022, 11:49 andig ***@***.***> wrote: Two options I could imagine: - separate go-bluetooth and go-bluetooth/bluez modules with different versions OR - go-bluetooth gets a version policy of supported bluez versions (assuming you can support multiple ones at the same time). One release per bluez version with patches to previous versions per policy (i.e. only last 3 bluezs will be supported). — Reply to this email directly, view it on GitHub <#143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZKVKILS3CE3HV3DTY243U4NS4JANCNFSM5GSZHWJQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[andig]

Resolved for me per #143 (comment)