1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • Re: using mbuffer: what am i doing wrong?

    From Michael =?utf-8?B?S2rDtnJsaW5n?=@21:1/5 to All on Tue Apr 9 16:10:01 2024
    On 9 Apr 2024 15:13 +0200, from debianlist@potentially-spam.de-bruyn.de (DdB): >> port=8000 # just an example
    filename=test.bin # created before

    # Start the receiver first, like:
    mbuffer -I $port -o $filename

    # Then start the sender like:
    mbuffer -i $filename -O ${receiverIP}:$port

    On my LAN (all virtual, at the moment), this fails, because the sender
    cannot connect to the receiver, so times out.

    Looking at the mbuffer man page, it certainly looks like it should
    work. Another tool that will let you do the same thing is nc (netcat);
    nc -l on the listener side, plain nc on the connecting side.


    What left me puzzled is this:
    Just starting the receiver, and then checking, if it is listening at the $port, i found:
    sudo netstat | grep $port
    to return nothing

    netstat defaults to resolving IPs and ports to names. At a minimum,
    add -n if you are grepping its output for a specific port number. (You
    may also want to use grep -w.)

    I also suggest to double-check to make sure that you don't have a
    firewall blocking the traffic.

    --
    Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arno Lehmann@21:1/5 to All on Tue Apr 9 15:50:01 2024
    Hello,


    I have not used mbuffer for a long time, so won't comment on that.

    But your netstat call looks unsuitable to diagnose.

    I'd propose to use

    ss -f inet -lpn

    ss instead of netstat... I try to catch up with changing times :-)

    -f inet because in this case, you're (probably) just interested in IPv4
    network sockets. Could be IPv6, of course, then use inet6

    -l list listening sockets, not active connections
    -p show the process using the socket. Will usually require root
    -n show numbers, not translated names

    l and n are probably most important for you (and are also available for netstat) as you would otherwise first miss a listening socket, and then
    have grep miss the output if you use a port number that is assigned (see /etc/services)

    Good luck!

    Arno


    --
    Arno Lehmann

    IT-Service Lehmann
    Sandstr. 6, 49080 Osnabrück

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc SCHAEFER@21:1/5 to DdB on Thu Apr 11 15:50:01 2024
    Hello,

    On Tue, Apr 09, 2024 at 03:13:01PM +0200, DdB wrote:
    from my research, the abbreviated takeaway is:

    I never used mbuffer, I use buffer combined with netcat-traditional:

    # receiver (TCP server on port 8000)
    nc -l -p 8000 | buffer -S 1048576 -s 32768 -o /dev/null

    # sender (TCP client on ephemeral port)
    nc localhost 8000 < /dev/zero

    I just installed mbuffer:

    mbuffer -I 8000 -o /dev/null

    mbuffer -i /dev/zero -O 127.0.0.1:8000

    and it also works.

    sudo netstat | grep $port
    to return nothing

    yes, but those work:

    netstat -a | grep :8000

    netstat --listen | grep :8000

    Maybe it's just that by default netstat only shows sockets in the
    ESTABLISHED state and not in the LISTEN state.

    What am i doing wrong?

    If there is a timeout, I would suggest to investigate firewalls
    on the server side.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)