Rev 543 disconnects PING user

[Pirre]

It seems that that last access modification lets a user with SUP pass 2 times the verification status, and disconnects him with reason 1 , think thats CID change :) the momet it verify's the CID second time

[poy (poy)]

probably fixed in rev 544.

[Pirre (pierreparys)]

now the pinger stay's in IDENTIFY state untill the timeout disconnects him, have tryed to see what happens using the pinger in debug mode but there you can only see parts of what he receives , not what he sends

[Pirre (pierreparys)]

Have tryed this with 7 different clients , none has a prob with sending that INF after the users verification, seems its only the pinger that not replys on the ISID, have posted a support ticket on dchublist.

Access.lua does seems completely correct now.

IF the protocol not specifies that the IINF must be send first, then the pinger is wrong.

Just a warning using this rev 544 will cause the hub the disappear from the hublist .... , will post answer from hublist here :)

[Pirre (pierreparys)]

No answer, commited a tmp fix in rev 558

[Pirre (pierreparys)]

Untill DCHubhlist updates pinger .....

[Derek Gal (dchublist.org)]

This was fixed at dchublist.org today.
No ip patch needed as of Sept.09.2018
Pinger now sends BINF - wchich was missing prev.

[poy (poy)]

workaround which sent the hub's INF earlier (before full user login) removed in the next ADCH++ version.
the workaround was limited to an old (now unused) IP anyways.

for reference, that workaround could not be generalized as it could result in information being sent about private hubs without having to log in.