tor 2012-03-01 klockan 23:37 +0100 skrev Peter Stuge: > > You only need to track the sequence number of the pending packets > > you currently expect a response to. > > And all previous packets which have not yet been responded to. The > problem is that sending anything with want reply = 0 means that no > response is expected, yet there is one.
I argue that it's perfectly fine to ignore the error response if you do not expect a response. Please put want_reply aside for now. That's unique to GLOBAL_REQUEST packets, not general flag for SSH packets. The only thing it adds to this discussion is to show that the same packet type may or may not expect a response depending on it's content. > > Getting UNIMPLEMENTED as response to a packet you are not expecting > > a response to can safely be ignored I think. > > It depends on what the packet was, but all sent packets which could > possibly return UNIMPL would have to be recorded, if UNIMPL sent by > the server out of the blue can be distinguished from actual > responses. UNIMPLEMENTED responses are identified by the sequence number of the packet they respond to. > If that does not matter, then simply ignoring UNIMPL always works > too. Not when you expect a response. For example the case just discussed with a want_reply keep-alive request sent before connection service is active would hang if implemented right and UNIMPLEMENTED is ignored. > > It's not really about global requests as such. You may in theory > > see UNIMPLEMENTED as response to any packet. > > Sure, but not all packets have a want reply field. If want reply = 0 > it will be not very nice for libssh2 to have to keep track of the > packet anyway because maybe there will be a response. Yes. Have never said anything along those lines. Only the opposite, there is no need to track packets to which you do not expect a response. > > In this specific case it's seen because global channel requests > > (keep-alive) are sent before the connection protocol is activated. > > The keepalive is a global request, unrelated to any channel, it only > lives inside the session. "Note that both the client and server MAY > send global requests at any time" so it's fine to send it also before > userauth is completed. No it's not. The connection protocol needs to be activated first (SSH_MSG_SERVICE_REQUEST "ssh-connection"). You can not use connection protocol messages without the connection protocol active. > I was hoping that they already were sent without other outstanding > packets, but since they are not, the only other easy fix I can think > of is to always ignore UNIMPLEMENTED in _libssh2_packet_requirev(). Yes and is why I proposed that for now we should ignore and warn. Long term we probably need to deal with them, which requires keeping track of the sequence number of packets one expects a response to so the error can be correctly routed up the stack to the application. This requires a bit of changes in transport api to indicate if responses are expected or not when sending a packet to transport. Regards Henrik _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
