Receiving specific TCP commands with nodejs and handling them

Question

I have a device in my local that sends JSON data through TCP:

ex. {"cmd": "listactions", "id": 13, "value": 100}

The data is send from 192.168.0.233 on port 8000 (I've checked this with wireshark)

I would like to (with my homeserver) intercept those specific commands with nodejs & send them through with pusher .

I have very little experience with nodejs & can't seem to get this working. I tried the following:

net = require('net');

var server = net.createServer(function(sock) {
    sock.setEncoding('utf8');

    sock.on('data', function (data) {
        // post data to a server so it can be saved and stuff
        console.log(data);

        // close connection
        sock.end();
    });

    sock.on('error', function (error) {
        console.log('******* ERROR ' + error + ' *******');

        // close connection
        sock.end();
    });

});

server.on('error', function (e) {
    console.log(e);
});

server.listen(8000, '192.168.0.233', function(){
    //success, listening
    console.log('Server listening');
});

But it complaints about EADDRNOTAVAIL , from research I've learned that this means the port is in use... Which I don't understand because I'm able to with Wireshark.

What's the correct way to do this?

Answer 1

Wireshark doesn't listen on all ports. It uses a kernel driver (with libpcap or winpcap) to "sniff" data off the wire. That is, it doesn't sit in between anything. It's not a man-in-the-middle. It just receives a copy of data as it is sent along.

Your application needs to listen on that port if you expect it to receive data. You should use netstat to figure out what process is listening on port 8000 and kill it. Then, you can listen on port 8000.

You could in theory use libpcap to get your data but that's crazy. There is a ton of overhead, something has to listen on that port anyway (it's a TCP connection after all), and it's extremely complex to filter out what you want. Basically, you would be reimplementing the network stack. Don't.