Tom Parkin <tparkin@katalix.com> writes: > On Tue, Jan 23, 2024 at 18:05:23 +0100, Simon Josefsson wrote: >> Tom Parkin <tparkin@katalix.com> writes: >> >> > Hi Simon, >> > >> > On Mon, Jan 22, 2024 at 20:15:11 +0100, Simon Josefsson wrote: >> >> golang-github-katalix-go-l2tp >> >> https://salsa.debian.org/jas/golang-google-grpc/-/jobs/5191076 >> >> === RUN TestBasicSendReceive/5:_send/recv_[::1]:9000_[::1]:9001_L2TPv3_IP >> >> level=info function=transport message=retransmit message_type=avpMsgTypeHello >> >> level=info function=transport message=retransmit message_type=avpMsgTypeHello >> >> level=info function=transport message=retransmit message_type=avpMsgTypeHello >> >> level=error function=transport message="socket read failed" error="resource temporarily unavailable" >> >> level=error function=transport message="transport down" error="transmit of avpMsgTypeHello failed after 3 retry attempts" >> >> transport_test.go:388: test sender function reported an error: >> >> failed to send Hello message: transmit of avpMsgTypeHello failed >> >> after 3 retry attempts >> >> panic: test timed out after 10m0s >> > >> > This test is failing to send a packet over an IPv6 L2TPIP socket: it >> > will depend on the go runtime support for L2TPIP (which has been in >> > for ages), and also the kernel having the l2tp_ipv6 driver loaded. >> > >> > I'd sort of expect to see messages along those lines when trying to >> > open the socket, though, rather than tx/rx failing :-/ >> > >> > I'm not at all familiar with the environment of the Salsa test >> > pipeline -- could you expand on what the configuration is here? >> >> Thanks for looking at the logs Tom. I don't really know much about the >> environment except for these pointers: >> >> https://wiki.debian.org/Salsa/Doc#Runners >> https://salsa.debian.org/salsa-ci-team/pipeline/ >> >> Does it setup a server on ::1 properly? Any outbound connections? Only >> http(s) is allowed. > > So I *think* the runtime env is a VM using the "Google Container-Optimized > OS". The fact that the socket opens successfully but the packet is > apparently lost is suggestive of some kind of firewalling. I'll see > if I can figure anything out from the Google docs. > > The tests work OK when run manually and when run as part of the > package build here, so I think it must be something specific to the > pipeline VM but I'm not sure what at the moment. > > In terms of the test configuration, it basically opens a socket for > each end of the connection and verifies it can send/receive over those > sockets. It's the same test code for each configuration. This problem happens for others: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063746 Interestingly the failure seems arch-specific: https://ci.debian.net/packages/g/golang-github-katalix-go-l2tp/ It could still well be that something in salsa and debci VM, and the #1063746 reporter's machine, that is causing this -- but it seems this clearly happens often enough, and is causing build failures checking reverse dependencies of several packages going into experimental, so it would be nice to fix it. Do you have any ideas? Could some test be disabled or silenced somehow? I'm ignoring build failures in golang-github-katalix-go-l2tp meanwhile. /Simon
Attachment:
signature.asc
Description: PGP signature