On Tue, Dec 31, 2024 at 06:51:39PM +1030, Jack Burton wrote:
> This patch allows iscsid(8) to connect successfully to & use a wider
> variety of iscsi targets.
> 
> It solves three current issues and makes a start on a fourth one:
> 
> 1. Some common iscsi targets refuse to complete SECNEG if we do not
> send a SessionType proposal, even for normal sessions (which
> according to RFC7143 is supposed to be the default).  Currently
> iscsid(8) only sends a SessionType proposal for discovery sessions.

I think it is fine to send this all the time if it makes some iscsi
targets happy.
 
> 2. Some common iscsi targets complain if we send the same proposal
> more than once during login (in SECNEG and/or OPNEG).  Currently, if
> iscsid(8) sends MaxConnections or MaxRecvDataSegmentLength at all
> then it keeps sending them over & over again throughout OPNEG until
> the login phase succeeds or fails (but if they're not accepted the
> first time, it will always end up failing).
> 
> 3. RFC7143 requires a response to every (non-declarative) proposal and
> some common iscsi targets enforce that requirement.  Most proposals can
> be made either by the initiator or by the target.  Since iscsid(8)
> currently only sends between 0 and 2 proposals in OPNEG, many common
> iscsi targets end up sending proposals to us, which we don't handle.

I think 2 and 3 are mainly a problem that the negotiation is not correctly
implemented. I never had many targets to test and most of them I used
always used defaults and did not like any other value. So I could never
properly play with the negotiation phase.

At least reading your #2 makes me think that iscsid does not properly
handle rejected values.

So if I understand you correctly we should send out every non-declarative
key=value pair so that the target can just reply to those.
Now for some of the parameters iscsid is very flexible and so it is maybe
tricky to define good initial values.
I really need to read Section 6 of RFC7143... right now I dislike to send
out default values all the time (feels like an inelegant solution to me).
 
I will check out your diff anyway and see what I can cherry-pick already.
-- 
:wq Claudio