On 10/13/2015 09:46 PM, SomeSuSEUser wrote:
> Quite right! So I’ve revisited this with new results…
> On the subject of ports, I’m quite fuzzy. I do have SAMBA enabled for
> all my systems. (I’ve thanked the gods repeatedly for SWERDNA’s
> tutorials)
swerdna’s tutorials have been similarly complimented many times over the
years.
> To that end, in YaST I know I’ve got an exception specified for a port
> 8080 so I’ve switched my testing to use that known “open port”.
As long as another service is not using it, that’s fine. You can check,
before running netcat in listen mode, that the current system is NOT
listening with that socket using the ‘ss’ or ‘netcat’ commands; copy/paste
the following line:
ss -planeto | grep :8080 | grep 'LISTEN '
If you see something there, you may have another service already using
that socket, in which case netcat will not load listening on that socket
because it is already in use. You may have known this, but it’s a common
thing to overlook.
It’s one of 2 open ports for TCP that is specified in YaST.
Also, all terminal sessions run as “su”.
Runningas ‘root’ for any of these tests is not needed, and as a result is
not recommended. Still, it should never hurt the test, but if you typo
something the ramifications can be system-wide instead of user-specific.
-(It seems backward to me. Knowing netcat is installed everywhere…
that if 192.168.1.2 is my slow machine and I want to test download speed
on there, then I run this command on that machine: netcat -l 8080 >
/dev/null… but if this machine is “listening” how is it the
server? Am I taking the term “server” too literally?)-
With TCP there is no “server” or “client” other than during the handshake,
because in 99.99999% of situations the client connects to the server
first, but after that three-way handshake (three tiny packets) has
completed, the transfer o data can happen bidirectionally. As a result,
testing a “server” or a “client” only really refers, in this case, to who
makes the connection. We could technically change the netcat commands to
be a little more traditional, but I feel confident it would only confuse
things to those who are not interested in niggling details. With that
said, I appreciate your attention to detail; if these tests work out
properly ,we could try things differently to prove that the issue you have
is more about data flow direction than which box setup the bidirectional
connection.
In any case I did this:
Code:
192.168.1.2 # netcat -l 8080 > /dev/null
Next, on the “client”, in this case 192.168.1.8 I ran the following
command:
Code:
time dd if=/dev/zero bs=1048576 count=100 | netcat 192.168.1.2 8080
Lo and behold I got an immediate response:
100+0 records in
100+0 records out
104857600 bytes (117M B) copied, 0.896488 s, 117MB/s
real 0m0.902s
user 0m0.014s
sys 0m0.507s
Perfect, and as predicted, around one second. Yes, you’re pushing gigabit
speeds (1000 Mbit).
So… by the math…104857600 bytes divided by 0.896488s, yeilding
116964867.349 or as the routine provided, effectively 117Mb/s.
So that seems to confirm that I’m not going to be able to get 200Mbps
down from the ISP.
No, you’re confusing bits and bytes. The numbers you calculated were
effectively 117 MB/s (capital ‘b’) not Mb/s (lower-case ‘b’) and the
upper-case B means Bytes. One byte per second is eight bits per second,
so 120 MB/s is around 1000 Mb/s or 1 Gb/s. Most network things are
calculated in bits/second due to tradition, and that’s what is really
handled on the wire. Back in the modem days, the fastest 56k modems were
only going (give or take) 7K/second, but the modem had to put every bit
individually on the wire. Because this slowness was so widespread and
common among professionals as well as non-professionals, common language
still counts network things in bit/second. Confusing the two is very
common, but it will make your testing have a bad result. In truth, the
speed you just had between systems would never be possible with your ISP,
and unless your ISP really does give you 200 MB/s (vs. 200 Mb/s) the
fastest you could get from them is (200/8) 25MB/s.
Conversely, I tried this test the other direction…
Code:
192.168.1.8 # netcat -l 8080 > /dev/null
Next, on the “client”, in this case 192.168.1.2 I ran the following
command:
Code:
time dd if=/dev/zero bs=1048576 count=100 | netcat 192.168.1.8 8080
dd: error writing ‘standard output’: Broken pipe
1+0 records in
0+0 records out
65536 bytes (66 kB) copied, 127.293 s, 0.5 kB/s
real 2m7.295s
user 0m0.000s
sys 0m0.005s
Something else is wrong. This is the time we saw earlier, and you can see
that ‘dd’ only managed to send 66 KB, which is nowhere near 100 MB, so
your listener was never reached on whatever the server was this time.
Check your firewall to be sure it’s not listening. You can do so easily
using the 'iptables or iptables-save command on the server side:
/usr/sbin/iptables -nvL | grep 8080
/usr/sbin/iptables-save | grep 8080
You can also use netcat to do a port test from the client to the server to
tell you whether or not the connection is open. It should return
instantly with ‘succeeded’ or ‘open’ with respect to the socket tested:
CODE
netcat -zv 192.168.1.8 8080
> Interesting, from one to the other works, albeit slowly.
> From this one the other direction the same set of commands fail with a
> "broken pipe"...
> Tried it again in case of a typo, I typed the entire string in manually,
> but no change....
> Still got the broken pipe issue. I repeated the same set of tests 3
> times from each side and got similar results each time from each
> direction.
The speed is fine; the chances of an ISP offering 200 MB/s is low, and
your ability to fully utilize that from one computer, where gigabit is as
fast as most non-enterprise things go, is even lower.
> FROM 192.168.1.8 time dd if=/dev/zero bs=1048576 count=100 | netcat
> 192.168.1.2 8080 the test works fine, but about half as fast as I need
> it to be.
> FROM 192.138.1.2 time dd if=/dev/zero bs=1048576 count=100 | netcat
> 192.168.1.8 8080 fails with a "broken pipe" error.
> I did ensure that I enabled the listen command on the opposite machine.
Yes, just your firewall may be in the way still. Fix with yast: Security
and Users: Firewall: Allowed Interfaces: Advanced: TCP: 8080:
Okay/Next/Finish/etc.
> Ultimately not QUITE sure how to interpret this fully, especially the
> "broken pipe" comment.
> Is this proving the issue mentioned by deano ferrari perhaps?
> Thanks!!
No, we're not there yet, as you probably now realize having made it this
far, but we'll get there.
--
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
