Quoting Michael Kerrisk: | Hi Gerrit, | | [...] | | >> Will submit a bug-fix to netdev and resubmit the updated manpage when this | >> issue has been resolved. | | Where are we with udplite.7 then? | Not forgotten. Patch was submitted to netdev@vger on Monday 30th June, which tried to handle the illegal values consistently, i.e. return EINVAL for * values between 1..7 (illegal as per RFC 3828, 3.1); * values greater than 65535 (since IPv6 jumbograms are not supported as per RFC 3828, 3.5 and since the u16 value internally wraps around to 1..7). The reply came back on Sat 5 July asking not to return EINVAL in the first case. I haven't submitted a new patch so far since I was asking for input regarding these cases. Maybe someone has a good suggestion regarding this? I will either re-post this on netdev very soon or work on a new patch. But can't submit manpage while the API is still not clear. Copy of email posted to netdev on Mon 7 July: > Can I just clarify illegal checksum values, as there are two different cases: > > (a) Values between 1..7 > The specification marks these as illegal in RFC 3828, sec. 3.1. > The Linux UDP-Lite API allowed the user to get away with these illegal > coverage values and documented this fact in udplite.txt. Since I am guilty > of having written this file, I can add that I am not aware that the same > behaviour is specified in another place -- other than RFC 3828. > > (b) Values greater than 0xFFFF > The UDP-Lite checksum coverage field has the same u16 size as the > UDP Length field but, in contrast, IPv6 jumbograms are not supported > (RFC 3828, 3.5). This means that checksum coverage values greater than > 65535 are undefined. > Since the internal field is u16 and since the setsockopt() argument > is `int', there is a need to protect against this range, not only > since the wrap-around can again cause values in the range 1..7. > > Can you and/or other people please provide input what to do API-wise in > the two above cases, since this information is needed for the manpage also? > > These options come to mind: > > (1) Keep behaviour for (a), return EINVAL for (b). > (2) Keep behaviour for (a) and silently ignore values > 0xffff by > replacing these with "full coverage" (0) - problematic if > negative values were supplied. > (3) Return EINVAL in both cases (as sketched by the patch). > (4) Other alternative? Regards Gerrit -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
