I’m still trying to do gmsk over the LFRX/TX boards and had hoped that
my
fpga modification might help. I can get the tunnel up and ping and even
copy
about 400-600kb of a file over scp, but then all of a sudden, the
environment deteriorates and the packets stop going through- at first
they
go like crazy, then just a clump at a time with a bunch of no-answers
in-between, then they stop getting through altogether. What could be
going
on do you suppose? What can I do to make it more stable?
View this message in context:
http://www.nabble.com/gmsk-in-light-of-fpga-modifications-tf3032882.html#a8426749
Sent from the GnuRadio mailing list archive at Nabble.com.
Brett Trotter wrote:
I’m still trying to do gmsk over the LFRX/TX boards and had hoped that my
fpga modification might help. I can get the tunnel up and ping and even
copy about 400-600kb of a file over scp, but then all of a sudden, the
environment deteriorates and the packets stop going through- at first they
go like crazy, then just a clump at a time with a bunch of no-answers
in-between, then they stop getting through altogether. What could be going
on do you suppose? What can I do to make it more stable?
Replying to myself, it seems that if I do an ssh and cat a bunch of data
from /dev/urandom through strings, eventually, the tunnel cant keep up
and
data stops streaming. Funny enough though, if I hit a key, it still
sends
data. It seems as if the ssh session got out of sync. Another ssh
session
running simultaneously, but not actively communicating, remains happy
once
the other dies.
I realize ssh probably isn’t the best thing to test with, but it happens
to
be a quick and easy way to test file sending. The question is, is our
tunnel
acknowledging corrupted packets instead of asking for resends? The
question
I’m asking ultimately is, what would cause corruption of the ssh
session?
View this message in context:
http://www.nabble.com/gmsk-in-light-of-fpga-modifications-tf3032882.html#a8428684
Sent from the GnuRadio mailing list archive at Nabble.com.
On Thursday 18 January 2007 21:31, Brett Trotter wrote:
I realize ssh probably isn’t the best thing to test with, but it happens to
be a quick and easy way to test file sending. The question is, is our
tunnel acknowledging corrupted packets instead of asking for resends? The
question I’m asking ultimately is, what would cause corruption of the ssh
session?
I suggest you install something like netcat
(ftp://coast.cs.purdue.edu/pub/tools/unix/netutils/netcat/) and see if
raw
socket connections help things.
Also you might be running out of entropy…
On Thu, Jan 18, 2007 at 03:01:49AM -0800, Brett Trotter wrote:
in-between, then they stop getting through altogether. What could be going
I realize ssh probably isn’t the best thing to test with, but it happens to
be a quick and easy way to test file sending. The question is, is our tunnel
acknowledging corrupted packets instead of asking for resends? The question
I’m asking ultimately is, what would cause corruption of the ssh session?
What data rate are you using?
Can your machines keep up?
FWIW, I often test with ssh and tunnel.
Eric
Daniel O’Connor wrote:
(ftp://coast.cs.purdue.edu/pub/tools/unix/netutils/netcat/) and see if raw
socket connections help things.
Also you might be running out of entropy…
Saw the entropy problem when using /dev/random, but /dev/urandom seems
happier- in either case, at some point, ctrl+c’s quit working and the
session basically locks up (with scp, it eventually stalls out- the most
I transferred was a MiB)- but typing causes packets to traverse the
tunnel even though the typed text does not render, nor seem to reach the
other end. I ran a ping -A and lost ‘0%’:
117536 packets transmitted, 117011 received, 0% packet loss, time
1288562ms
rtt min/avg/max/mdev = 7.952/10.591/35.604/0.920 ms, pipe 3, ipg/ewma
10.963/10.484 ms
So bottom line is, the ssh dies off. I’m going to try out the tcpdump
suggestion from Greg T. and see what things look like.
It’s possible that the interface is seeing so many errors that the
checksums occasionally work out despite the errors- I’m going to also
try increasing the symbols/sample.
On Friday 19 January 2007 01:19, Brett L. Trotter wrote:
Also you might be running out of entropy…
Saw the entropy problem when using /dev/random, but /dev/urandom seems
happier- in either case, at some point, ctrl+c’s quit working and the
session basically locks up (with scp, it eventually stalls out- the most
I transferred was a MiB)- but typing causes packets to traverse the
tunnel even though the typed text does not render, nor seem to reach the
other end. I ran a ping -A and lost ‘0%’:
Hmm, at least in FreeBSD urandom will give you randomness even when the
entropy pool is empty, whereas random will not.
I believe that reading from urandom will consume entropy if it is
available -
this could cause a problem if SSH later needs randomness as it will
block
reading from urandom.
So bottom line is, the ssh dies off. I’m going to try out the tcpdump
suggestion from Greg T. and see what things look like.
Good idea 
It’s possible that the interface is seeing so many errors that the
checksums occasionally work out despite the errors- I’m going to also try
increasing the symbols/sample.
Hmm, but TCP will correct for these errors - it only uses 32 bit CRC but
it’s
not that likely to give a false positive.