How to filter out telnet negotiations from client?

[geetotes]

On my telnet server, I have two event listeners:

telnetInput.on('sub', function(option, buffer) {
...snip...
});

socket.on('data', function(data) {
....snip...
});

When I receive a NAWS, the negotiation string also gets passed to my socket. I thought that

socket.pipe(telnetInput).pipe(process.stdout);
process.stdin.pipe(telnetOutput).pipe(socket);

Would filter the input and output to the socket in some way, but I guess not?

tldr; I'm getting an 7-bit ASCII negoation string when I do NAWS that my other socket chokes on; is this an expected behavior?

[blinkdog]

Sorry about the delay. I didn't have my e-mail filters set up correctly, so the notification for this issue was buried for a little while.

TelnetInput should filter negotiations from the incoming stream.

My only thought here is that you've got this:

socket.pipe(telnetInput).pipe(process.stdout);

This means that the "socket" object is the pure raw incoming input. Any events processed on the socket object will not have gone through any filters yet, including TelnetInput. Thus, with this line, your data handler will certainly see the incoming negotiation:

socket.on('data', function(data) {
....snip...
});

After the raw input is piped to TelnetInput, the handler for sub-negotiations kicks in to filter/handle the incoming negotation:

telnetInput.on('sub', function(option, buffer) {
...snip...
});

My suggestion is that TelnetInput is a Transform stream, so it itself is a regular stream that supports all the same events that other streams do. So change:

socket.on('data', function(data) {
....snip...
});

To:

telnetInput.on('data', function(data) {
....snip...
});

I think that should help. TelnetInput should only pass along the data that wasn't part of a TELNET negotiation or sub-negotiation.

[marado]

One can't easilly replace socket calls with telnet-stream object calls, tho, since you have both input and output on the same object with a socket, while the same doesn't apply on telnet-stream objects. I mean, if you have a load of code with calls like socket.write and socket.on, you'd have now to start separating them in telnetOutput.write and telnetInput.on calls, right?

[blinkdog]

telnet-stream v1.0.3 has a new TelnetSocket class to handle the case described by @marado