• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: attached gateways
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: attached gateways


  • Subject: Re: attached gateways
  • From: "Jamie Wood" <email@hidden>
  • Date: Tue, 28 Jun 2005 09:37:58 -0700

It's been said on this list before, but I *highly* recommend that you get a copy of W. Richard Stevens' Unix Network Programming Volume 1. The code samples that it contains are usually enough to get you started with any aspect of BSD network programming.

There is an ICMP daemon example in that book (starting on page 685). In a perusal of the code, it does not look like you need to join a multicast group. However, you do need to be running as root to open a raw socket (I notice that you are not doing any error checking after your socket() call). Also, the code is using recvfrom() instead of read() to read packets from the socket (although I don't know if that really makes much of a difference).

Here is what the socket call looks like:

fd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);

Here is what the code to read from it looks like:

struct sockaddr_in from;
socklen_t len;
char buf[8192];
int result;

result = recvfrom(fd, buf, 8192, 0, (struct sockaddr *)&from, &len);

Hope this helps,
Jamie

From: Dalton Hamilton <email@hidden>
To: Chase <email@hidden>
CC: email@hidden
Subject: Re: attached gateways
Date: Tue, 28 Jun 2005 18:25:51 +0200

No worries. Yes, you'd be the server blocking on recvfrom() system call.....



On Jun 28, 2005, at 6:18 PM, Chase wrote:

At the risk of sounding like an idiot... will I be playing the role of the server or the client if I'm just listening for router advertisements?

Server, right (?)... because I'm listening for something?

- Chase



On Jun 28, 2005, at 11:09 AM, Dalton Hamilton wrote:


I haven't been following this message thread but I figured that this had to be either a broadcast frame or a multicast frame.

Here is a snippet from the rfc and it clearly points out that the router advertisements are sent to a either a multi-cast or a broadcast (multicast preferred) and is what is probably being used. Unless you join the multicast group for that address you'll never receive any icmp packets. The :

The ICMP router discovery messages are called "Router Advertisements"
   and "Router Solicitations".  Each router periodically multicasts a
   Router Advertisement from each of its multicast interfaces,
   announcing the IP address(es) of that interface.  Hosts  discover the
   addresses of their neighboring routers simply by listening for
   advertisements.  When a host attached to a multicast link  starts up,
   it may multicast a Router Solicitation to ask for immediate
   advertisements, rather than waiting for the next periodic ones to
   arrive; if (and only if) no advertisements are forthcoming, the  host
   may retransmit the solicitation a small number of times, but then
   must desist from sending any more solicitations.  Any routers that
   subsequently start up, or that were not discovered because of  packet
   loss or temporary link partitioning, are eventually discovered by
   reception of their periodic (unsolicited) advertisements.  (Links
   that suffer high packet loss rates or frequent partitioning are
   accommodated by increasing the rate of advertisements, rather than
   increasing the number of solicitations that hosts are permitted to
   send.)

AdvertisementAddress
   The IP destination address to be used for multicast
   Router Advertisements sent from the interface.  The
   only permissible values are the all-systems multicast
   address, 224.0.0.1, or the limited-broadcast address,
   255.255.255.255.  (The all-systems address is preferred
   wherever possible, i.e., on any link where all
   listening hosts support IP multicast.)

   Default: 224.0.0.1 if the router supports IP multicast
   on the interface, else 255.255.255.255

I also tracked down some sample code for the multicast server and multicast client. This below code was copied from http:// www.tack.ch/multicast/ :

This is a sample multicast server without error handling
Comments on code
----------- cut here ------------------
// Multicast Server
// written for LINUX
// Version 0.0.2
//
// Change: IP_MULTICAST_LOOP : Enable / Disable loopback for outgoing messages
//
// Compile : gcc -o server server.c
//
// This code has NOT been tested
//


#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

#define MAXBUFSIZE 65536 // Max UDP Packet size is 64 Kbyte

int main()
{
   int sock, status, socklen;
   char buffer[MAXBUFSIZE];
   struct sockaddr_in saddr;
   struct ip_mreq imreq;

   // set content of struct saddr and imreq to zero
   memset(&saddr, 0, sizeof(struct sockaddr_in));
   memset(&imreq, 0, sizeof(struct ip_mreq));

   // open a UDP socket
   sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
   if ( sock < 0 )
     perror("Error creating socket"), exit(0);

saddr.sin_family = PF_INET;
saddr.sin_port = htons(4096); // listen on port 4096
saddr.sin_addr.s_addr = htonl(INADDR_ANY); // bind socket to any interface
status = bind(sock, (struct sockaddr *)&saddr, sizeof(struct sockaddr_in));


   if ( status < 0 )
     perror("Error binding socket to interface"), exit(0);

   imreq.imr_multiaddr.s_addr = inet_addr("226.0.0.1");
   imreq.imr_interface.s_addr = INADDR_ANY; // use DEFAULT interface

   // JOIN multicast group on default interface
   status = setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP,
              (const void *)&imreq, sizeof(struct ip_mreq));

   socklen = sizeof(struct sockaddr_in);

   // receive packet from socket
   status = recvfrom(sock, buffer, MAXBUFSIZE, 0,
                     (struct sockaddr *)&saddr, &socklen);

   // shutdown socket
   shutdown(sock, 2);
   // close socket
   close(sock);

   return 0;
}


----------- cut here ------------------
This is a sample multicast client without error handling
----------- cut here ------------------
// Multicast Client
// written for LINUX
// Version 0.0.2
//
// Change: IP_MULTICAST_LOOP : Enable / Disable loopback for outgoing messages
//
// Compile : gcc -o client client.c
//
// This code has NOT been tested
//


#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

#define MAXBUFSIZE 65536 // Max UDP Packet size is 64 Kbyte

int main()
{
   int sock, status, socklen;
   char buffer[MAXBUFSIZE];
   struct sockaddr_in saddr;
   struct in_addr iaddr;
   unsigned char ttl = 3;
   unsigned char one = 1;

   // set content of struct saddr and imreq to zero
   memset(&saddr, 0, sizeof(struct sockaddr_in));
   memset(&iaddr, 0, sizeof(struct in_addr));

   // open a UDP socket
   sock = socket(PF_INET, SOCK_DGRAM, 0);
   if ( sock < 0 )
     perror("Error creating socket"), exit(0);

saddr.sin_family = PF_INET;
saddr.sin_port = htons(0); // Use the first free port
saddr.sin_addr.s_addr = htonl(INADDR_ANY); // bind socket to any interface
status = bind(sock, (struct sockaddr *)&saddr, sizeof(struct sockaddr_in));


   if ( status < 0 )
     perror("Error binding socket to interface"), exit(0);

   iaddr.s_addr = INADDR_ANY; // use DEFAULT interface

   // Set the outgoing interface to DEFAULT
   setsockopt(sock, IPPROTO_IP, IP_MULTICAST_IF, &iaddr,
              sizeof(struct in_addr));

   // Set multicast packet TTL to 3; default TTL is 1
   setsockopt(sock, IPPROTO_IP, IP_MULTICAST_TTL, &ttl,
              sizeof(unsigned char));

   // send multicast traffic to myself too
   status = setsockopt(sock, IPPROTO_IP, IP_MULTICAST_LOOP,
                       &one, sizeof(unsigned char));

   // set destination multicast address
   saddr.sin_family = PF_INET;
   saddr.sin_addr.s_addr = inet_addr("226.0.0.1");
   saddr.sin_port = htons(4096);

   // put some data in buffer
   strcpy(buffer, "Hello world\n");

   socklen = sizeof(struct sockaddr_in);
   // receive packet from socket
   status = sendto(sock, buffer, strlen(buffer), 0,
                     (struct sockaddr *)&saddr, socklen);

   // shutdown socket
   shutdown(sock, 2);
   // close socket
   close(sock);

   return 0;
}




Good luck. Dalton Hamilton










On Jun 28, 2005, at 5:50 PM, Chase wrote:


Scratch that last question. I've read a lot since yesterday on ICMP and that question really didn't make any sense, now that I understand a little more about it.

But, this little code snippet I found in an online tutorial isn't catching any ICMP packets:

int main() {
    char buffer[8192];
    int fd = socket (PF_INET, SOCK_RAW, IPPROTO_ICMP);
    printf("\nHere we go...\n");
    while (read (fd, buffer, 8192) > 0) {
        printf("Caught ICMP Packet\n");
    }
    return 0;
}


It compiles and runs fine, but never catches anything. It just sits on the read() line, waiting indefinitely.


I tried unplugging/replugging routers to force them to send ICMP router advertisements, but still nothing shows up.

Any ideas?

Thanks.

- Chase

PS: Anyone know of a higher volume list where I could ask these questions? I'm practically the only poster for almost two straight days.



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden


This email sent to email@hidden





_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden


This email sent to email@hidden


_______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: attached gateways
      • From: Dalton Hamilton <email@hidden>
    • Re: attached gateways
      • From: Chase <email@hidden>
References: 
 >Re: attached gateways (From: Dalton Hamilton <email@hidden>)

  • Prev by Date: Re: attached gateways
  • Next by Date: Re: attached gateways
  • Previous by thread: Re: attached gateways
  • Next by thread: Re: attached gateways
  • Index(es):
    • Date
    • Thread