Validate_metadata: INTERNAL:Illegal header value

[u27p20]

Hello Everyone,

I am currently working on a project using the Kuksa CAN Provider to get data from the Kuksa Data Broker and provide it to the CAN interface. For this setup, I am using certificates and an authentication token that were generated separately. However, when I use these generated tokens, the Kuksa CAN Provider gives an "Invalid Metadata Error." I am unsure why this error occurs, and I have conducted several tests to investigate the issue:

First Test: Tested the Kuksa Data Broker and Kuksa CAN Provider without an authentication token.

• I established a connection between the Kuksa Data Broker, Kuksa client, and Kuksa CAN Provider, setting the provider to vss2dbc mode.

• To test the communication, I set a value from the Kuksa client using: "setTargetValue Vehicle.Body.Mirrors.DriverSide.Pan 85" I could see the corresponding message in the vcan/CAN interface, confirming that the Kuksa CAN Provider is functioning as expected without an authentication token.

Second Test: Tested the Kuksa Data Broker and Kuksa CAN Provider with the default JWT authentication token (https://github.com/eclipse-kuksa/kuksa-common/tree/main/jwt)).

• I used the provide-all.token, and the communication between the Kuksa Data Broker, Kuksa client, and Kuksa CAN Provider was successfully established.

• I verified this by testing with the Kuksa client and observing the candump in the vcan/CAN interface.

Third Test: Used the Kuksa Data Broker with generated certificates and a Python application acting as a Kuksa client.

• Started the Kuksa Data Broker with generated certificates.
• Started the Kuksa client with a generated authentication token.
• Used a Python application as a Kuksa client with the generated token to receive VSS data.
• Successfully established the connection and tested the application with the generated tokens.
• Sent Vehicle.Speed data from the Kuksa client, and the Python application was able to receive it.

This confirms that the generated tokens work correctly with the Kuksa Data Broker and Python client.

Fourth Test: Used the Kuksa Data Broker with generated certificates, the Kuksa client with the generated token, and the Kuksa CAN Provider.

• Started the Data Broker and Kuksa client with the generated token, and the client connected successfully to the Data Broker.
• Started the Kuksa CAN Provider with the same generated token.
• However, I encountered the "Invalid Metadata Error" with the Kuksa CAN Provider. Error logs are below:

  E0830 11:39:30.128952735  947885 call.cc:1095]                         validate_metadata: INTERNAL:Illegal header value
  Traceback (most recent call last):
  File "/home/avl/workspace/apps/kuksa-can-provider/./dbcfeeder.py", line 625, in <module>
  sys.exit(main(sys.argv))
  File "/home/avl/workspace/apps/kuksa-can-provider/./dbcfeeder.py", line 590, in main
  feeder.start(
  File "/home/avl/workspace/apps/kuksa-can-provider/./dbcfeeder.py", line 124, in start
  self._kuksa_client.start()
  File "/home/avl/workspace/apps/kuksa-can-provider/dbcfeederlib/databrokerclientwrapper.py", line 110, in start
  self._grpc_client.authorize(token=self._token, **self._rpc_kwargs)
  File "/home/avl/.local/lib/python3.10/site-packages/kuksa_client/grpc/__init__.py", line 706, in wrapper
  return func(self, *args, **kwargs)
  File "/home/avl/.local/lib/python3.10/site-packages/kuksa_client/grpc/__init__.py", line 982, in authorize
  resp = self.client_stub.GetServerInfo(req, **rpc_kwargs)
  File "/home/avl/.local/lib/python3.10/site-packages/grpc/_channel.py", line 1178, in __call__
  ) = self._blocking(
  File "/home/avl/.local/lib/python3.10/site-packages/grpc/_channel.py", line 1146, in _blocking
  call = self._channel.segregated_call(
  File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 554, in grpc._cython.cygrpc.Channel.segregated_call
  File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 423, in grpc._cython.cygrpc._segregated_call
  File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 417, in grpc._cython.cygrpc._segregated_call
  File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 258, in grpc._cython.cygrpc._call
  File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 304, in grpc._cython.cygrpc._call
  File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 62, in grpc._cython.cygrpc._raise_call_error
  ValueError: metadata was invalid: [('authorization', 'Bearer <my_generated_token>\n')]

In all the tests, I have used the VSS_4.0.json and given that the tokens work fine in other scenarios, I am unsure why it fail with the Kuksa CAN Provider. Could you please help me understand why this error occurs and how to resolve it?

Thank you in advance for your assistance.

[lukasmittag]

hey @u27p20 how does your json file look like? should be something similair to this https://github.com/eclipse-kuksa/kuksa-common/blob/main/jwt/provide-all.json as you mentioned. E.g. what scope etc have you specified?

[lukasmittag]

Another point that would be interesting did you feed the token with Bearer your_token? Because the internal method of the kuksa-can-provider is using the kuksa-python-sdk and thus this function to authorize https://github.com/eclipse-kuksa/kuksa-python-sdk/blob/331737c6dd367de87a70ec3bf3750283f1882da4/kuksa-client/kuksa_client/grpc/aio.py#L355 and this expectets only the token and adds the Bearer in front.

[u27p20]

Hello @lukasmittag ,

Thanks for your reply.

Yes, my JSON file is similar to provide-all.json. Please find the attachment for JSON file.

I use this JSON file to generate a token and only add the generated token to the provide-my-all.token file. However, when running the kuksa-can-provider, the .token file is read, and the same error is displayed.

When I use the same .token file with kuksa-client, the token works correctly.

[erikbosch]

Hi!

How do you provide your token to the CAN provider? Kuksa has support for both including the token itself directly in the config file or to reference the file name. If file name is used it reads the content and strips any trailing newlines.

if self.token_or_tokenfile is not None:
            if os.path.isfile(self.token_or_tokenfile):
                self.token_or_tokenfile = pathlib.Path(self.token_or_tokenfile)
                self.token = self.token_or_tokenfile.expanduser(
                ).read_text(encoding='utf-8').rstrip('\n')
            else:
                self.token = str(self.token_or_tokenfile)

In your log there is a trailing \n:

ValueError: metadata was invalid: [('authorization', 'Bearer <my_generated_token>\n')]

... which may cause the problem. It would be interesting to know how you specify the token in your config file (or by other mechanism?) If you give a file link you could check that the token file does not have content we (currently) cannot handle, like unexpected blanks before newline (\n \n). If you give the token directly we need to check where the newline comes from. A snippet of the token part of the config file (anonymized, but with kept blanks/newline) could be useful for us to look at.

[u27p20]

Hi @erikbosch

The issue was with the \n character. Thanks for your help! I'm now able to establish a connection with the server.