[PATCH] Add A5/3 and 4 support

Sylvain Munaut 246tnt at gmail.com
Mon Jun 16 21:24:00 UTC 2014


Hi,

>         /* Notes:
> -        *  - key must be 8 bytes long (or NULL for A5/0)
> +        *  - key must be 8/16 bytes long (or NULL for A5/0) depending on algorithm variant
>          *  - the dl and ul pointer must be either NULL or 114 bits long
> -        *  - fn is the _real_ GSM frame number.
> -        *    (converted internally to fn_count)
> +        *  - fn is the _real_ GSM frame number (unless fn_correct is false),
> +        *    converted internally to fn_count
> +        *  - only top-level osmo_a5 should be considered as part of public API
>          */
>  int osmo_a5(int n, const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul);
>  void osmo_a5_1(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul);
>  void osmo_a5_2(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul);
> +void _osmo_a5_3(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul, bool fn_correct);
> +void _osmo_a5_4(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul, bool fn_correct);

Why the _ prefix ? It's exported and in the header and none of the
other have it. Unnecessary inconsistency.

Same for fn_correct, none of the other have it. The only use for it
seem to be for the test ... but then the correct way is to make the
test compute the real fn from the fn_count before the call, not
pollute the API with a useless parameter.



>  a5_a5_test_SOURCES = a5/a5_test.c
>  a5_a5_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libosmogsm.la
> +a5_a5_test_LDFLAGS = -static

Why is that needed at all ?

If the functions are in the installed header they should be in the .map.


If you don't want the other osmo_a5_x function as part of the API then
first remove them from the header (they shouldn't be used anywhere
anyway) and from the map and make them static. And then don't add the
3/4 to the .h file either and make the test go through the osmo_a5
function.


Cheers,

   Sylvain




More information about the baseband-devel mailing list