I am curious: apart from a training prospective at code digging, what was the goal? In other words, where did you expect the IP address to come from, if not from a system network socket?
Have a nice week-end, --- *B. R.* On Sat, Feb 4, 2017 at 12:02 AM, Paul Nickerson <pnicker...@cashstar.com> wrote: > > Reading that file, the next likely looking line is: > > c->addr_text.len = ngx_sock_ntop(c->sockaddr, c->socklen, > > c->addr_text.data, > > ls->addr_text_max_len, 0); > > Thank you for the boost. From what you said, it looks like the variable is > constructed from c->sockaddr > > src/event/ngx_event_accept.c > line 167 > c->sockaddr = ngx_palloc(c->pool, socklen); > > I chased that down, and it looks like ngx_palloc only allocates some > memory; it doesn't fill it. Moving on. > > line 173 > ngx_memcpy(c->sockaddr, &sa, socklen); > > It looks like ngx_memcpy is a wrapper around the standard C library > function memcpy. For memcpy(A, B, C), it copies to destination A from > source B, and it does amount C. So now I want to know where &sa comes from. > > line 70 > s = accept(lc->fd, &sa.sockaddr, &socklen); > > Here, &sa.sockaddr is being sent into something. I think &sa.sockaddr > becomes c->sockaddr, so I chase this. > > Bash > man 2 accept > > accept is a Linux system call: "accept a connection on a socket" > int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen); > > "The argument addr is a pointer to a sockaddr structure. This > structure is filled in with the address of the peer socket, as known > to the communications layer. The exact format of the address > returned addr is determined by the socket's address family (see > socket(2) and the respective protocol man pages). When addr is NULL, > nothing is filled in; in this case, addrlen is not used, and should > also be NULL." > > And so, the answer to my question appears to be: $remote_addr is > constructed from "struct sockaddr *addr" of the "accept" Linux system call. > It is the address of the peer socket. > > I am going to read through socket(2) and the respective protocol man > pages, but at this point we're outside of NGINX, and so the scope of this > mailing list. > Thank you again for your help. > > ~ Paul Nickerson > > *CONFIDENTIALITY NOTICE* > > The attached information is PRIVILEGED AND CONFIDENTIAL and is intended > only for the use of the addressee named above. If the reader of this > message is not the intended recipient or the employee or agent responsible > for delivering the message to the intended recipient, please be aware that > any dissemination, distribution or duplication of this communication is > strictly prohibited. If you receive this communication in error, please > notify us immediately by telephone, delete the message and destroy any > printed copy of the message. Thank you. > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx