Application error 0x1 (remote)

[hivenet-mathieu-lacage]

Hi,

I got the following logs while running a client which was attempting to establish a connection to a relay:

2024-12-19T10:58:05.182Z        INFO    net/identify    identify/id.go:427      failed negotiate identify protocol with peer    {"peer": "QmYPwNuMCDMC1QKR6hQZH6XFZkqfwf6ruE4pRECAZh7VAm", "error": "Application error 0x1 (remote)"}
2024-12-19T10:58:05.182Z        WARN    net/identify    identify/id.go:399      failed to identify QmYPwNuMCDMC1QKR6hQZH6XFZkqfwf6ruE4pRECAZh7VAm: Application error 0x1 (remote)

I traced the above to be a quic error of type InternalError (0x1) returned by the remote over the stream that was established.

Now, I am trying to figure out what could make a remote do this. My best guess is that the remote has reset the stream which might make the underlying quic code decide to send back an InternalError.

 516 func (ids *idService) handleIdentifyResponse(s network.Stream, isPush bool) error {
 517         if err := s.Scope().SetService(ServiceName); err != nil {
 518                 log.Warnf("error attaching stream to identify service: %s", err)
 519                 s.Reset()
 520                 return err
 521         }   

But I do not have any logs on the remote with the message from line 518 despite enabling DEBUG logging with GOLOG_LOG_LEVEL=debug. I also have that remote setup with an infinite limits resource manager so, I feel this is not a serious lead.

Would anyone, by chance, have a hint as to where I should be digging into to figure out what might cause the remote peer to return this quic internal error when attempting to negotiate the identity protocol over a stream ?

[marten-seemann]

Internal error would be a transport error, not an application error.

[hivenet-mathieu-lacage]

Internal error would be a transport error, not an application error.

I think you are saying that this error is generated by the code in p2p/transport/quic and if so, yes, this is what I had in mind but what I am trying to understand is what is making the code in transport/quic generate this error.

Are there known application-level patterns that could trigger this type of behavior ?