Help please. Setting a host name innichestack

That's a very good question. One that I can't seem to find the answer for... Anyone else ever do this??

- Ura

I've not done it yet, The pertinent code is found in "autoip.c". The function is at the bottom "dhc_hostname()". Here are the comments for the function:

/* FUNCTION: dhc_hostname()
 *
 * Called from the DHCP client to get a valid hostname for this machine. This
 * is a default routine which returns a dummy name. The porting engineer is
 * expected to define GETHOSTNAME_ALREADY and replace this with a system
 * routine.
 *
 * Note - if MUST always return a string.
 *
 * PARAM1: none
 *
 * RETURNS: pointer to ascii hostname string
 */

So, define the MACRO "GETHOSTNAME_ALREADY" to the system library build then add a function dhc_hostname() to your code somewhere similar to what you do for get_mac_addr() and get_ip_addr().

Jake

Jake

This won't work. Setting a hostname will not communicate the hostname to the outside world, it's just a local setting for the IP stack. You have several ways of doing what you want:

- set up the DHCP server so that it always assign the same fixed IP address to your board's MAC address, and set that IP address in your DNS server.

- set up a dynamic zone in your DNS server, have your board connect to it and fix its address (that maybe the closest to what you want to do). You would need to write a dynamic DNS client on your board, have a look at this page (http://en.wikipedia.org/wiki/dynamic_dns) for more information.

- have your board regularly broadcast a simple UDP packet saying "I'm here!" and have a software on the other side pick up the packet and get the IP address

Thanks for all the replies to this.

I think the option that best suits my needs is the UDP broadcast. Because the board will ultimately be plugged into a network over which I have no control I don't want to require the end user to have to fiddle with their DHCP settings to get the board to work. The UDP message sounds like the best way to remove any effort from the end user.

Thanks for the help, I'll report back with my progress (soon I hope!)

Here's another option to add to the list. Interniche does appear to support "Option 81: FQDN" (fully qualified domain name) on the discovery packet.

The support is "slightly" broken, however. For quite some time now, I've been wondering why my Altera board IP addresses appear as "che" on my networks...at home and at work. I found the reason yesterday. Here's the snippet of code that "sets" this in DHCP servers/DNS systems that support it (taken from dhcpclnt.c):

/* DC_DOMAINNAME - domain name to be used for this DHCP Client.
 * Used for option 81 in the DHCP Request.
 * Proper value for this macro must be defined in dhcpclnt.h or ipport.h
 * If it is not defined, then the following value will be used.
 */# ifndef DC_DOMAINNAME# define DC_DOMAINNAME  "iniche"# endif

Later on in the same file, the string "iniche" is pulled in as the text for option code 81 in the discovery packet. The only trouble is that somewhere along the way 3 characters always get stripped off the front of this string...which explains "why che?"

Any easy workaround would be to place 3 dummy characters in front of the FQDN that you actually want....like so: "xxxiniche"

Best Regards,

- slacker

Thank you all for your suggestions.

In the end I have decided on a UDP message solution.

My client at startup can now be prompted by the user to send out a small UDP broadcast packet on a known port. Any server of mine on the network will then report back its identity and the IP address is revealed :-)

The server code has been modified so that the server listens for the broadcast message in the same loop as it is waiting for a connection, which seems to work quite nicely.

Thanks again for the help.

I am trying to accomplish the same thing. I can't seem to get it to recieve any UDP messages. Would you mind explaining what settings you needed or how you did it.

Thanks

Here are the extracts of code which I think should contain all the information you need.

Basically the client (i.e. the remote end) sends out a UDP broadcast message containing the string "client broadcast". The client then sends back its IP address, ensuring it is byte swapped appropriately.

The while (1) loop in this code is the very same while (1) loop found in the simple socket server example, where it is listening for the incoming connection on the fd_listen socket.

 
struct sockaddr_in bcast_addr;
 
/*
* Create a socket to listen for the UDP 'Hello' message from the client.
* We'll need to reply to this message with our IP address before the client
* can connect.
*/
if ((fd_bcast = socket(AF_INET, SOCK_DGRAM, 0)) < 0)
{
alt_NetworkErrorHandler(EXPANDED_DIAGNOSIS_CODE," Bcast socket creation failed");
}
 
/*
* bind to the socket
*/ 
bcast_addr.sin_family = AF_INET;
bcast_addr.sin_port = htons(15000);
bcast_addr.sin_addr.s_addr = INADDR_ANY;
 
if ((bind(fd_bcast,(struct sockaddr *)&bcast_addr,sizeof(bcast_addr))) < 0)
{
alt_NetworkErrorHandler(EXPANDED_DIAGNOSIS_CODE," Bcast bind failed");
}
 
/*
* Now enter the main processing loop
*/
while(1)
{
FD_ZERO(&readfds);
FD_SET(fd_listen, &readfds);
FD_SET(fd_bcast, &readfds);
max_socket = fd_bcast+1;
if (conn.fd != -1)
{
FD_SET(conn.fd, &readfds);
if (max_socket <= conn.fd)
{
max_socket = conn.fd+1;
}
}
 
select(max_socket, &readfds, NULL, NULL, NULL);
 
if (FD_ISSET(fd_bcast, &readfds))
{
int bytes, addr_len=sizeof(addr);
char buffer;
bytes = recvfrom(fd_bcast, buffer, sizeof(buffer), 0, (struct sockaddr*)&addr, &addr_len);
ntohs(addr.sin_port), bytes);
if (strcmp(buffer, "client broadcast") == 0)
{
sendto(fd_bcast, buffer, bytes, 0, (struct sockaddr*)&addr, sizeof(addr));
}
}
...
}

I hope this helps!

Matthew

Matthew

Thanks for your reply. My code was very similar but I had screwed up with the port numbers. I had was sending it to a different port than what I was listening on. d-ooh! Hence the name Dumass. Most commonly pronounced Dumb-***.

I'm grateful to you all out there, who are willing to lend a helping hand.