Mailing List Archive

Hi,

rapier wrote:
> Is there any documentation (outside of the code) describing the channel
> functions?

The channel functions in the OpenSSH codebase? Probably no.


> I'm looking at using a secondary channel to periodically report back
> receiver side TCP metrics (via the TCP_INFO struct) to the caller for
> flow diagnostics. Alternatively, is there a good place in the code
> base I can use as a starting point to understand the process?

Are you familiar with channels in general? RFC 4254 5. Channel Mechanism.

If you want to control exactly when data from (your metric) channels
are sent on the wire I think you have to do quite a deep dive into the code.

If you care less about jitter then you can maybe look at SFTP but
probably much better any of the socket forwarding.

If you want to implement the metric completely in the application layer
you could investigate creating it in a subsystem, which (like SFTP) is
also just a channel.


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Peter,

On 5/21/21 3:04 PM, Peter Stuge wrote:
> Hi,
>
> rapier wrote:
>> Is there any documentation (outside of the code) describing the channel
>> functions?
>
> The channel functions in the OpenSSH codebase? Probably no.

That was my guess but it never hurts to ask.

>> I'm looking at using a secondary channel to periodically report back
>> receiver side TCP metrics (via the TCP_INFO struct) to the caller for
>> flow diagnostics. Alternatively, is there a good place in the code
>> base I can use as a starting point to understand the process?
>
> Are you familiar with channels in general? RFC 4254 5. Channel Mechanism.

Sort of familiar but only as much as it impacted on HPNSSH. It's been a
while since I read the RFC so thank you for the pointer.

> If you want to control exactly when data from (your metric) channels
> are sent on the wire I think you have to do quite a deep dive into the code.

While I'm not opposed to deep dives I don't need a specific trigger. I'm
really just going to look for an update every N seconds so a timing loop
would work.

Basically, the idea is on connection two channels are open - one for the
user and one for metrics. Every N seconds read the TCP_INFO data from
the tcp socket and send it down the metric channel which writes it to
stdout, a file, whatever.

> If you care less about jitter then you can maybe look at SFTP but
> probably much better any of the socket forwarding.

So socket forwarding... I'll take a look at that.

> If you want to implement the metric completely in the application layer
> you could investigate creating it in a subsystem, which (like SFTP) is
> also just a channel.

Can that ride alongside other actions like SFTP or SCP or even just a
tty? Mostly I'm looking to gather metrics from real world usage. Either
way it looks promising.

Thanks for insight,

Chris
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi Chris,

rapier wrote:
> > If you care less about jitter then you can maybe look at SFTP but
> > probably much better any of the socket forwarding.
>
> So socket forwarding... I'll take a look at that.

Thinking about it again do look at SFTP too;

In particular, sftp-server can run as part of sshd when the command
"internal-sftp" is configured either in sshd_config Subsystem line
or by ForceCommand.

That might actually be a better match for your needs than the
forwarding code - if I understand correctly that you want to extract
metrics from within sshd itself.


> > If you want to implement the metric completely in the application layer
> > you could investigate creating it in a subsystem, which (like SFTP) is
> > also just a channel.
>
> Can that ride alongside other actions like SFTP or SCP or even just a
> tty?

That's exactly how channels work. The ControlMaster/ControlPath
connection muxing also uses channels; a channel is added in the
original connection each time another ssh/sftp/scp command runs
and "connects" through the ControlMaster.


> Mostly I'm looking to gather metrics from real world usage. Either
> way it looks promising.

Nod, yes, a metric channel makes perfect sense.


Kind regards

//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev