Failed to send() control packet

[RalfJung]

I have just noticed this message for the first time in tunneldigger client logs:

Mon May 25 20:04:21 2020 daemon.warn td-client: Failed to send() control packet (errno=1, type=5)!

errno 1 seems to be EPERM. The error is evidently printed here:

tunneldigger/client/l2tp_client.c

Line 795 in 8995046

syslog(LOG_WARNING, "[%s:%s] Failed to send() control packet (errno=%d, type=%x)!",

Type 5 is CONTROL_TYPE_KEEPALIVE. The message appeared twice, then not any more... but still, this seems odd? @kaechele have you ever seen this?

[kaechele]

Haven't seen that yet. But also haven't looked closely. EPERM in our scenario is most likely due to the send buffer not being drained quickly enough. A low memory situation could possibly also contribute to this.
I have been working on asyncio Python 3.7+ rewrite of the broker lately to sharpen my asyncio skills and noticed quite a few weird things both client and broker do (i.e. both client and broker seem to send keepalive packets instead of the broker just responding to the client's keepalive packets).
We can probably backport my findings into this implementation once I finish my research.

[RalfJung]

Yeah I noticed that thing about the keepalives, too... but honestly it would seem rather arbitrary otherwise who responds to whose keepalives, so why not.

I have been working on asyncio Python 3.7+ rewrite of the broker

Honestly if a rewrite happens I'd rather do it in a language where I get help from the compiler to ensure that anything makes any sense... but I'm not doing the work so whatever. ;)

[kaechele]

Honestly if a rewrite happens I'd rather do it in a language where I get help from the compiler to ensure that anything makes any sense... but I'm not doing the work so whatever. ;)

Haha, yes, you're absolutely right. For some odd reason that didn't occur to me. It was more dabbling in Python with asyncio anyway and I wasn't planning on merging it back into this codebase.
Also, I have wanted to learn Go for quite some time now.
Given that I, by now, fully understand how this whole thing works it might be a good starter project.

[RalfJung]

I never wrote any Go (I'm more of a Rust person), but the language is supposed to be easy to pick up so I could probably do some reviewing of that.

[RalfJung]

If I had more time at my hands I'd rewrite client and server in Rust so they could share the packet parsing... okay I'd have to convince the Gluon devs to take on a Rust dependency, not sure if that would work (or if Rust is even available for all these crazy platforms Gluon is built on), but it could still help to have a client in a saner language than C.

But I don't have that time so these are just idle thoughts anyway.