RPiPlay icon indicating copy to clipboard operation
RPiPlay copied to clipboard

Cannot connect to Rpi400 from Mac 12

Open Pucur opened this issue 4 years ago • 12 comments

Hello!

I'm using raspberry pi with stock image, the build was successful, and it doesnt gave back any error message, and when i started i seen in the airplay logo the name of my server, but when i tried to connect, it always failed, and on my terminal, it gaves back this message:

rpiplay: plist.c:765: plist_get_uint_val: Assertion `length == sizeof(uint64_t) || length == 16' failed.

I googled so much about this error but i cant figure it out why it brings it to me.

Please help!

Thanks!

Pucur avatar Nov 06 '21 18:11 Pucur

Please include details about the device you're trying to connect from.

FD- avatar Nov 06 '21 18:11 FD-

MacBook Air (M1, 2020)

and the server is a Raspberry Pi 400 Rev 1.0, using Raspbian GNU/Linux 10 (buster) armv7l (5.10.63-v7l+)

Pucur avatar Nov 06 '21 18:11 Pucur

What OS are you running on the MB Air?

My guess is you're running Mojave, and they changed the format of a field in one of the setup plists.

FD- avatar Nov 06 '21 18:11 FD-

I'm using Monterey, the freshest Im using the notebook system language as English but the keyboard is Hungarian, maybe this could cause this?

Pucur avatar Nov 06 '21 19:11 Pucur

Sorry, I meant to say Monterey instead of Mojave :D I doubt the keyboard language is the culprit here. I'm afraid I don't have a MB running Monterey, but it would be great if anyone who has could debug the plist parsing logic used in RPiPlay's setup process.

FD- avatar Nov 06 '21 19:11 FD-

I have time to figure it out if you wish, where could i find the plist parsing exactly?

Pucur avatar Nov 06 '21 19:11 Pucur

The problem seems to be here: https://github.com/FD-/RPiPlay/blob/c985ce1adb443b07220cd5ae4f1c728d2422888c/lib/raop_handlers.h#L371 Please try to figure out the correct data type of the timing port in the plist. It may e.g. be a string.

FD- avatar Nov 06 '21 20:11 FD-

@Pucur you can get to see the plist that is a problem by using plist_to _xml (in /usr/include/plist/plist.h)

after line 337

plist_from_bin(data, data_len, &req_root_node)

add code

char *plist_xml;
uint32_t plist_length;
plist_to_xml(req_root_node,  &plist_xml, &plist_length);
printf("%s\n",plist_xml);
free(plist_xml);

This should print the plists that are being asked about by the macOS 12 client. There are 3 requests in which the client sends a plist.

Thee server replies each time with a plist "res_root_node" at line 462 of raop_handlers.h

plist_to_bin(res_root_node, response_data, (uint32_t*) response_datalen);

also add, just before this line

printf("response\n)";
plist_to_xml(res_root_node,  &plist_xml, &plist_length);
printf("%s\n",plist_xml);
free(plist_xml);
printf("end of response\n");

and you will also see the plist send back to the client in response to its request

The first request is about pairing and encryption A second occurs when the video setup request type 110 for video comes, A third when the audio setup request type 96 comes.

This should be enough to see what is going on . I have already noticed that some of the plist items in raop_handlers.h are incorrectly/obsoletely specified, but that didn't cause problems so far. Maybe macOs 12 is asking about something that was not asked about before and exposed the error.

@FD-

It would in general be useful to have these plists printed when the -d debug option is used.

fduncanh avatar Nov 07 '21 18:11 fduncanh

@Pucur

There is another place to look.

at line 160 of lib/raop_handlers.h

 plist_to_bin(r_node, response_data, (uint32_t *) response_datalen);

this is where the (possibly invalid) plist properties of the server are sent to the client.

before line 160 add

    printf("begining of sent to client\n");
    char *plist_xml;
    uint32_t plist_length;
    plist_to_xml(r_node,  &plist_xml, &plist_length);
    printf("%s\n",plist_xml);
    free(plist_xml);
    printf("end of sent to client\n");

fduncanh avatar Nov 07 '21 20:11 fduncanh

Here is a useful modern description of the expected plist events, (that shows a few errors/obsoleteness in the current rpiplay plist data sent to the client, refreshRate = int 60 missing maxFPS=int 30 bool heightPhysical, widthPhysical .) I doubt if these are the problem, though.

https://github.com/SteeBono/airplayreceiver/wiki/AirPlay2-Protocol

fduncanh avatar Nov 07 '21 20:11 fduncanh

@Pucur

There are three places where plist_get_uint_val is called ( in raop_handlers.h) for timing_rport, type, and stream_connection_id.

I'm guessing a request was made that sent a plist that doesnt contain the expected entry so when an attempt to read that entry was made, it was not there (not being there means it fails the test of having the right size....), so post the plist_xml that gets printed out just before the failure.

maybe also put something like

printf("getting timing_rport\n");
plist_get_uint_val(.....)
printf("got timing_rport\n");

around each of the three calls to plist_get_uint_val() to find which attempt fails.

fduncanh avatar Nov 08 '21 08:11 fduncanh

@fduncanh

Thanks for the info, i'll look up these places and write back shortly. :)

Pucur avatar Nov 08 '21 08:11 Pucur