Closed Juan-789 closed 4 months ago
Maybe throw an exception for UnauthorizedCallsign that the calling function can catch and specially handle that case (I.e, on transmission it'd just return the function and not parse)
(I.e, on transmission it'd just return the function and not parse)
This function is going to be called after the packet header is parsed; we did consider having an exception but we want to reserve those for things that are critically wrong. A completely valid packet header can still contain an unauthorized callsign
It seems odd we are parsing unauthorized callsigns, this function is a duplicate of the callsign check code in the parse_rn2483_transmission function. A check that used to return early on unauthorized callsigns but is now allowing them again.
It seems odd we are parsing unauthorized callsigns, this function is a duplicate of the callsign check code in the parse_rn2483_transmission function. A check that used to return early on unauthorized callsigns but is now allowing them again.
The reasoning is because we want to parse and log them. If we are receiving packets from an unauthorized callsign which also happen to follow our packet spec, chances are it just means someone forgot to add their callsign to the list of recognized ones.
I see that the function you mentioned does have the same check. Ideally @Juan-789, this function you are testing could replace that check. The relevant file is here
and its tests