Skip to content

Conversation

@gabrielmancini
Copy link

fix the packet parser to retrive the topic name

parse_topic_filters(subscribe, Bin) ->
[{Topic, #{rh => Rh, rap => Rap, nl => Nl, qos => QoS}}
|| <<Len:16/big, Topic:Len/binary, _:2, Rh:2, Rap:1, Nl:1, QoS:2>> <= Bin];
|| <<_:8, Len:16/big, Topic:Len/binary, _:2, Rh:2, Rap:1, Nl:1, QoS:2>> <= Bin];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot seem to find why there is one leading byte before the string length.

@gabrielmancini
Copy link
Author

hello @zmstone, sorry about the lac of the context,

i have try to create an tcp elixir "mqtt proxy" to a broker, and i have using this lib to parse mqtt packets,
and i have tested using the MQTTX, and i really dont know why this is happend, i just find this aditional byte in topics, and when i ignore, my code works.

@zmstone
Copy link
Member

zmstone commented Apr 14, 2025

Hi @gabrielmancini

SUBSCRIBE packet is for server to parse, I have to admit that it's possible that there is a lack of test coverage here in emqtt since it's a client library.

Had a quick look into the server side code (which is extensively tested) here: https://github.com/emqx/emqx/blob/bc7668078c80bf51ad996342e8ee6681adce41a4/apps/emqx/src/emqx_frame.erl#L659-L665

They seem to be the same, and I cannot seem to spot where the leading byte might have leaked from.
It would be great if you can:

  1. Find the root cause (the byte must belong to the leading part of the SUBSCRIBE packet, before topics list)
  2. Add a test case

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

Successfully merging this pull request may close these issues.

2 participants