[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: golang-google-grpc + golang-github-google-s2a-go



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.

Attachment: signature.asc
Description: PGP signature


Reply to: