• 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: Dalton Hamilton <email@hidden>
  • Date: Tue, 28 Jun 2005 19:12:04 +0200

He will need to join the 224.0.0.1 multicast group if he expects to receive the icmp announcement sent from routers to this multicast address. He isn't merely trying to open a socket at the icmp layer, he needs to register with another layer three address -- i.e. the multicast address which will in turn get translated to another mac address and the NIC will be told to read in frames destined to that multicast mac address.


On Jun 28, 2005, at 6:37 PM, Jamie Wood wrote:

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:
40hotmail.com


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
References: 
 >Re: attached gateways (From: "Jamie Wood" <email@hidden>)

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