Am 25.08.20 um 01:58 schrieb Eric Thorpe: > Hi Arne, > >> - to avoid the 256 byte management limit and multiple commands use maybe >> the same approach as client-auth that allows a longer frame, you can >> still limit that to 1024. > To be clear here, it isn't so much the limitation of the management or > control channel, it's situations where a tun-mtu may be set to say 750 > for example, meaning the data size can only realistically be about 730 > minus INFO_PRE, flags, etc, or OpenVPN or the network will drop the > control channel message. I would not recommend making any changes to > management or the control channel here, simply just have the ability to > send the data in smaller parts. > >> CR_TEXT is challenge response text and those clients that currently >> implement it only allow a single line. I would suggest the following to >> get the patch in a acceptable state: >> >> - Document your authentication method also in management.txt and also >> what IV_SSO flag indicates this authentication method. > Are you suggesting that I do not use CR_TEXT, and instead introduce a > new Challenge Response type (CR_DATA for example)?
IV_SSO=crtext is a basically the AUTH_PENDING variant of presenting the user the text of CR_TEXT and responding with the answer. What you doing seems to be different. And if we add something that is different we should it its own IV_SSO flag to announce itself. And if you need "just" a multiline or longer text than current crtext can give to the user, we still need a flag for this new method, so we can signal if the client supports this. I am just asking that if we add new methods to AUTH_PENDING to properly document them. Arne
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
