Hi Willy,

Just get it tested, nothing to do with check-send-proxy, still the
same no response.
I have some change as below to make it work again.

=================
diff --git a/src/connection.c b/src/connection.c
index f0ca2bb16..c8ebe9da4 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -1017,17 +1017,12 @@ int conn_send_socks4_proxy_request(struct
connection *conn)
         if (conn->send_proxy_ofs != 0) {
             goto out_wait;
         }
-    }
-
-    /* OK we've the whole request sent */
-    conn->flags &= ~CO_FL_SOCKS4_SEND;
-    __conn_sock_stop_send(conn);
+
+        /* OK we've the whole request sent */
+        conn->flags &= ~CO_FL_SOCKS4_SEND;

-    /* The connection is ready now, simply return and let the connection
-     * handler notify upper layers if needed.
-     */
-    if (conn->flags & CO_FL_WAIT_L4_CONN)
-        conn->flags &= ~CO_FL_WAIT_L4_CONN;
+        __conn_sock_want_recv(conn);
+    }

     if (conn->flags & CO_FL_SEND_PROXY) {
         /*
@@ -1157,6 +1152,16 @@ int conn_recv_socks4_proxy_response(struct
connection *conn)
     } while (0);

     conn->flags &= ~CO_FL_SOCKS4_RECV;
+
+    if (conn->flags & CO_FL_WAIT_L4_CONN) {
+        if (!(conn->flags & CO_FL_HANDSHAKE & ~CO_FL_SOCKS4)) {
+            /* No more handshake needed, the connection is ready now,
+             * simply return and let the connection handler notify
+             * upper layers if needed.
+             */
+            conn->flags &= ~CO_FL_WAIT_L4_CONN;
+            }
+        }
     return 1;

  recv_abort:
=================

Regards,
Alexander Liu


On Sun, Jun 2, 2019 at 4:37 PM Alec Liu <alec....@gmail.com> wrote:
>
> Hi Willy,
>
> The test case which I used was on purpose, to combine proxy protocol
> with socks4.
> Due to I am not doing any special checking, it should be fine without
> check-send-proxy.
>
> Actually the check part should be fine with my testing configuration,
> at least it shows as up in the HAProxy.
> I will do some more testing with check-send-proxy added too, let you
> know in short.
>
> btw: for SOCKS server you can just use the "ssh -D 1080 ...".
>
> Regards,
> Alexander Liu
>
> On Sun, Jun 2, 2019 at 4:29 PM Willy Tarreau <w...@1wt.eu> wrote:
> >
> > Hi Alec,
> >
> > On Sat, Jun 01, 2019 at 05:39:30AM +0800, Alec Liu wrote:
> > > Hi Willy,
> > >
> > > Thank you for merging it !
> > >
> > > I have the merged code pull, and rerun some basic test, ends up failed.
> > > here is the testing configuration:
> > > * server Apache2_Via_SocksProxy_HTTP_SP 192.168.101.227:49980
> > > send-proxy verify none socks4 127.0.0.1:1080 check-via-socks4 check
> > > inter 30000 fastinter 1000
> > >
> > > Looks like it is something related to the send and recv you have 
> > > mentioned.
> > > Should we just leave it in this way for now, and wait for the issue to
> > > be fixed?
> >
> > So I checked but I can't get it to fail here. In the trace below,
> > my SOCKS server (netcat+script) is on 127.0.0.1:9000 :
> >
> > 10:22:57.486347 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 8
> > 10:22:57.486401 connect(8, {sa_family=AF_INET, sin_port=htons(9000), 
> > sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in 
> > progress)
> > 10:22:57.486462 sendto(8, "\4\1\0P>\324r<HAProxy\0", 16, 
> > MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE, NULL, 0) = 16
> > 10:22:57.486481 recvfrom(8, 0x7ffd5106b7f8, 8, MSG_PEEK, NULL, NULL) = -1 
> > EAGAIN (Resource temporarily unavailable)
> > 10:22:57.486493 epoll_ctl(3, EPOLL_CTL_ADD, 8, {EPOLLIN|EPOLLRDHUP, {u32=8, 
> > u64=8}}) = 0
> > 10:22:57.692857 recvfrom(8, "\0Z\0\0\0\0\0\0", 8, MSG_PEEK, NULL, NULL) = 8
> > 10:22:57.692948 recvfrom(8, "\0Z\0\0\0\0\0\0", 8, 0, NULL, NULL) = 8
> > 10:22:57.693028 sendto(8, "OPTIONS / HTTP/1.0\r\n\r\n", 22, 
> > MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 22
> > 10:22:57.693142 recvfrom(8, 0x1df9bd0, 16384, 0, NULL, NULL) = -1 EAGAIN 
> > (Resource temporarily unavailable)
> > 10:22:57.693197 epoll_ctl(3, EPOLL_CTL_MOD, 8, {EPOLLIN|EPOLLRDHUP, {u32=8, 
> > u64=8}}) = 0
> > 10:22:57.693549 recvfrom(8, "HTTP/1.1 200 OK\r\n", 16384, 0, NULL, NULL) = 
> > 17
> > 10:22:57.693631 recvfrom(8, 0x1df9be1, 16367, 0, NULL, NULL) = -1 EAGAIN 
> > (Resource temporarily unavailable)
> > 10:22:57.693755 epoll_ctl(3, EPOLL_CTL_DEL, 8, 0x7fdcbd2c97e0) = 0
> > 10:22:57.693921 close(8)                = 0
> > [WARNING] 152/102257 (29489) : Server 20080/srv is UP, reason: Layer7 check 
> > passed, code: 200, info: "OK", check duration: 207ms. 1 active and 0 backup 
> > servers online. 0 sessions requeued, 0 total in queue.
> > <29>Jun  2 10:22:57 haproxy[29489]: Server 20080/srv is UP, reason: Layer7 
> > check passed, code: 200, info: "OK", check duration: 207ms. 1 active and 0 
> > backup servers online. 0 sessions requeued, 0 total in queue.
> >
> > It consumes the handshake, responds with the code you're expecting then
> > receives the reqeust and sends the response.
> >
> > Oh I'm seeing that you're combining send-proxy with it so I guess you're
> > using the proxy protocol on top of the SOCKS connection, but don't have
> > check-send-proxy, thus there is no way the server will be able to respond.
> > Are you sure this isn't the cause of your problem ?
> >
> > Willy

Reply via email to