Plugin crash on connection reset.

[Mantrain]

Sorry for the bad labeling. I think the overall issue is in our location however it seems like the plugin does not handle it gracefully.

This crashes and restarts traefik. On traefik 2.9.1 and v0.0.20

| ERROR: ldapAuth: 2023/04/19 11:50:43 restricted.go:51: BindDN Error: unable to read LDAP response packet: read tcp 172.18.0.30:37212->10.234.32.10:389: read: connection reset by peer
   | ERROR: ldapAuth: 2023/04/19 11:50:43 restricted.go:51: Authentication failed
   | ERROR: ldapAuth: 2023/04/19 11:50:43 restricted.go:51: BindDN Error: unable to read LDAP response packet: read tcp 172.18.0.30:37288->10.234.32.10:389: read: connection reset by peer
   | ERROR: ldapAuth: 2023/04/19 11:50:43 restricted.go:51: Authentication failed
   | time="2023-04-19T11:50:43Z" level=error msg="plugins-storage/sources/gop-1395261136/src/github.com/wiltonsr/ldapAuth/vendor/github.com/go-ldap/ldap/v3/conn.go:65:7: panic" module=github.com/wiltonsr/ldapAuth plugin=plugin-ldapAuth
   | time="2023-04-19T11:50:43Z" level=error msg="plugins-storage/sources/gop-1395261136/src/github.com/wiltonsr/ldapAuth/vendor/github.com/go-ldap/ldap/v3/conn.go:443:13: panic" module=github.com/wiltonsr/ldapAuth plugin=plugin-ldapAuth
   | panic: send on closed channel [recovered]
   |    panic: send on closed channel [recovered]
   |    panic: send on closed channel
   | 
   | goroutine 28171791 [running]:
   | github.com/traefik/yaegi/interp.runCfg.func1()
   |    github.com/traefik/yaegi@v0.14.2/interp/run.go:192 +0x148
   | panic({0x32d72e0, 0x448f610})
   |    runtime/panic.go:884 +0x212
   | github.com/traefik/yaegi/interp.runCfg.func1()
   |    github.com/traefik/yaegi@v0.14.2/interp/run.go:192 +0x148
   | panic({0x32d72e0, 0x448f610})
   |    runtime/panic.go:884 +0x212
   | reflect.rselect({0xc00396cc78, 0x3, 0x0?})
   |    runtime/select.go:590 +0x23e
   | reflect.Select({0xc0007f8f20?, 0x3, 0xc024e39a28?})
   |    reflect/value.go:2952 +0xd2
   | github.com/traefik/yaegi/interp._select.func4(0xc008553970)
   |    github.com/traefik/yaegi@v0.14.2/interp/run.go:3760 +0x47e
   | github.com/traefik/yaegi/interp.runCfg(0xc00192ad80, 0xc008553970, 0xc00396cf10?, 0xc001f747c0?)
   |    github.com/traefik/yaegi@v0.14.2/interp/run.go:200 +0x29d
   | github.com/traefik/yaegi/interp.call.func9(0xc008553550)
   |    github.com/traefik/yaegi@v0.14.2/interp/run.go:1438 +0x965
   | github.com/traefik/yaegi/interp.runCfg(0xc0019afc20, 0xc008553550, 0x0?, 0x0?)
   |    github.com/traefik/yaegi@v0.14.2/interp/run.go:200 +0x29d
   | github.com/traefik/yaegi/interp.genFunctionWrapper.func2.1({0x63654c0, 0x0, 0x0?})
   |    github.com/traefik/yaegi@v0.14.2/interp/run.go:1022 +0x487
   | reflect.Value.call({0x303f140?, 0xc0347d2390?, 0x0?}, {0x39e926c, 0x4}, {0xc01cf6e4e0, 0x0, 0xc0007e8230?})
   |    reflect/value.go:584 +0x8c5
   | reflect.Value.Call({0x303f140?, 0xc0347d2390?, 0xc0079bbef8?}, {0xc01cf6e4e0?, 0xc0085533f0?, 0xc002057b70?})
   |    reflect/value.go:368 +0xbc
   | github.com/traefik/yaegi/interp.runCfg.func1()
   |    github.com/traefik/yaegi@v0.14.2/interp/run.go:183 +0x1a7
   | github.com/traefik/yaegi/interp.runCfg(0xc0019af0e0, 0xc02c4ccfd0, 0xaf25e6?, 0xc0020a77a0?)
   |    github.com/traefik/yaegi@v0.14.2/interp/run.go:202 +0x2f1
   | created by github.com/traefik/yaegi/interp.call.func9
   |    github.com/traefik/yaegi@v0.14.2/interp/run.go:1435 +0x91d

[wiltonsr]

Does the problem occur with Traefik v2.10.0-rc2?

It looks like yaegi can't handle your connection error. I made a test using the examples folder with the versions you provided, but I can't reproduce the problem.

Please try a ldapsearch to your server to know if it's working as expected.

[Mantrain]

This crash happens on production, so I am a bit hesitant to put an RC there, but I will look into it.

The plugin functions fine most of the time, ldapsearch tool works every time I use it, however, this is the second crash of this type i see.

I cannot replicate it - for whatever reason, the ldap server forcibly closes the connection. I dont have access to the part of our infrastructure. It might every well be a problem with the ldap server, however it would be nice if it was handled without a panic :)