aoh/radamsa

tcp_client on Mac OS X not sending data

cweb opened this issue · 4 comments

cweb commented

I have radamsa running on Ubuntu 14.04 and Mac 10.11.4, trying to send data to a remote IP address.

echo "AAA" | radamsa -o 10.1.1.2:80 -n 1

In tcpdump I can see my Mac completes a SYN, SYN/ACK, ACK, but stops there, not sending a PSH with the payload. On Ubuntu the payload is sent as expected.

aoh commented

That command would write the output to 10.1.1.2 file. TCP output is used when the parameter is of the form IP:port. Did you forget the port from the bug or while running it?

If that wasn't the problem, send the output of strace radamsa -o 10.1.1.2:80 -n 1 and check if on your Ubuntu machine e.g. nc -l 31337 gets the output of echo foo | radamsa -o 127.0.0.1:31337.

cweb commented

Bah, I created the issue incorrectly, I was of course using the 10.1.1.2:80 syntax, and was getting valid TCP connections as I stated. Difference was on Mac the payload was never sent after the TCP handshake. Things work fine and as expected on Ubuntu.

I had previously done the verification test you suggested with netcat. I did it on both Ubuntu and Mac. The problem is with Mac, not Ubuntu. Mac makes the connection but doesn't send any data.

aoh commented

Ok. So I assumed, but wanted to rule out obvious issues at first. Dang, I can't test on Mac, so it may be a bit difficult to figure out what's going on.

Can you post the output of $ owl-lisp-0.1.12/bin/vm owl-lisp/fasl/init.fasl -e '(let ((cli (open-connection (vector 10 1 1 2) 80))) (print "fd is " cli) (print "output: " (print-to cli "GET / HTTP/1.1\r\n\r\n")) (print "closing: " (close-port cli)))' after building radamsa on Mac? Is there no transmission also in this case?

Does radamsa$ echo foo | owl-lisp/bin/vm owl-lisp/fasl/init.fasl --run rad/main.scm -o 10.1.1.2:80 report an error anywhere?

Can you send the output of dtruss radamsa -o 10.1.1.2:80?

Does git clone https://github.com/aoh/owl-lisp.git && cd owl-lisp && make test succed on your Mac?

My first guess would be, that owl/radamsa thinks the channel is not ready for transmission due to some unexpected Mac-specific return value from IO primitives.

aoh commented

Wasn't able to reproduce. Closing for now. Open if there is more data or it keeps happening.