[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-user
Subject:    SOLVED (was: Re: using mbuffer: what am i doing wrong?)
From:       DdB <debianlist () potentially-spam ! de-bruyn ! de>
Date:       2024-04-11 14:14:33
Message-ID: 6fdd7ea3-66c2-ff39-13f4-029bd9e75de2 () potentially-spam ! de-bruyn ! de
[Download RAW message or body]

Am 11.04.2024 um 15:49 schrieb Marc SCHAEFER:
> 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.
> 
> 

Thank you for your (and everyone else)'s hints.
It is working now. The lessons learned:
- in fact netstat is somewhat outdated, ss is the replacement (package
iproute2 instead of net-tools)
- yes, and my attempt at checking just failed, as you kindly pointed
out, due to missing out on listening ports. LOL
- when using mbuffer from a pipe, it is important to say "-i - " in the
arguments (missed that at first)
- the resulting transfer is way faster than say ... ssh.


[prev in list] [next in list] [prev in thread] [next in thread]