home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.unix.wizards:3598 comp.unix.programmer:4280
- Path: sparky!uunet!mcsun!sun4nl!tuegate.tue.nl!svin02!wzv!wietse
- From: wietse@wzv.win.tue.nl (Wietse Venema)
- Newsgroups: comp.unix.wizards,comp.unix.programmer
- Subject: Re: Recvfrom() in an inetd server
- Message-ID: <3723@wzv.win.tue.nl>
- Date: 13 Aug 92 18:22:17 GMT
- References: <1992Jul19.221910.5437@massey.ac.nz>
- Followup-To: comp.unix.wizards
- Organization: Eindhoven University of Technology, The Netherlands
- Lines: 31
-
- A.Raman@massey.ac.nz (Anand) writes:
-
- [getting the remote host name from an UDP connection in a child
- process of the inetd]
-
- >Regarding the second option of using recvfrom() on fd 0, I had the
- >following doubt: If inetd already receives the packet for us, and
- >is known to supply the data field on stdin, then the packet is already
- >lost. In that case, how can recvfrom() return the packet to me?
-
- inetd does not receive the packet. It just waits until a packet is
- available, then invokes the daemon listed in the inetd.conf file.
-
- With the following code, inetd can non-destructively examine the
- UDP packet, and find out the source IP address.
-
- /* In case of UDP, peek at the message without reading it. */
-
- if (recvfrom(0, buf, sizeof(buf), MSG_PEEK, &sa, &length) < 0) {
- syslog(LOG_ERR, "recvfrom: %m");
- ...
- }
-
- /* If all went well, sa.sin_addr is the source IP address. */
-
- This trick is used in my tcp wrappers to find out what systems are
- connecting to the telnet, finger, tftp and other services, and to do
- access control as well. On some Convex systems the MSG_PEEK facility
- does not seem to work, however.
-
- Wietse
-