DHCP problem with some routers

[Ardoster]

Hi

I've detected that the DHCP functionality doesn't work with all routers. For example, the basic application that is created with all new MQX projects in Codewarrior, works correctly at my home. But the DHCP function is not working at my office.

Looking for in the forum, I've found that some people is having this same problem. But there's no helpful answers to fix this problem.

Any suggestion????

Regards,

Eduardo

[Martin_]

Which Freescale MQX version do you use ?

Can you post communication log for network protocol analyzer (Wireshark) between the DHCP server and MQX DHCP client ? Which RTCS function is failing and what is the return code ?

[Ardoster]

Thanks for your interest

Well. I'm using MQX 3.7, and the function i'm using is the same as the basic application:

error = ipcfg_bind_dhcp_wait(IPCFG_default_enet_device, 1, &ip_data);

In the attached file, you can see the communication log using Wireshark. I'm able to see the request from MQX to my router, but I'm not able to see the replies of the router to my board: I don't know how to see this replies. Anyway, in the backend of my router, I'm able to see it is being received the DHCP packets, and the router is sending replies.

Thanks for your help

Regards,

Eduardo

[Martin_]

In log there are only outbound DHCP messages from client to server.

It would be useful to see also DHCP server messages from server to client to debug this.

Anyway, we can see DHCPDECLINEs from MQX dhcp client. Quickly searching on internet:

<--

http://www.helpline4it.com/encyclopedia-210.html

DHCP Decline Message (DHCPDECLINE)

A message sent by a DHCP client to the DHCP server to decline the offer of an IP address on the network. This message is used when the client detects a potential conflict because the IP address is found to be already in use on the network. The DHCP decline message name is DHCPDECLINE.

http://www.freesoft.org/CIE/RFC/2131/25.htm

If the server receives a DHCPDECLINE message, the client has discovered through some other means that the suggested network address is already in use. The server MUST mark the network address as not available and SHOULD notify the local system administrator of a possible configuration problem.

-->

There are 3 cases when MQX dhcp client sends DHCPDECLINE

-the offered IP is already in use (checked by ARP)

-server id option is not valid (incoming DHCP packet not valid)

-message type option is not valid (incoming DHCP packet not valid)

I think you should discuss with your system administrator the rules the dhcp server is using to to offer IP to clients.

[Ardoster]

Thanks. I agree with you that the messages from the server to the client would be useful to debug this problem, but I haven't been able to scan these messages.

All I can tell you, is that the router is working ok. This is the log in the router refering to this DHCP problem:

Oct 19, 2012 8:18:56 AM com.teldat.tr69.osconfig.linux.dhcp.LinuxDHCPConfig external

INFO: New binding: ifc br1, ip 192.168.1.114, lease 86400, mac C0A801370102, hostname , vendorId _global_, clientId C0:A8:01:37:01:02, manufacturerOUI , serialNumber , productClass

Oct 19, 2012 8:19:01 AM com.teldat.tr69.osconfig.linux.dhcp.LinuxDHCPConfig external

INFO: New binding: ifc br1, ip 192.168.1.115, lease 86400, mac C0A801370102, hostname , vendorId _global_, clientId C0:A8:01:37:01:02, manufacturerOUI , serialNumber , productClass

Oct 19, 2012 8:19:09 AM com.teldat.tr69.osconfig.linux.dhcp.LinuxDHCPConfig external

INFO: New binding: ifc br1, ip 192.168.1.116, lease 86400, mac C0A801370102, hostname , vendorId _global_, clientId C0:A8:01:37:01:02, manufacturerOUI , serialNumber , productClass

Oct 19, 2012 8:19:25 AM com.teldat.tr69.osconfig.linux.dhcp.LinuxDHCPConfig external

INFO: New binding: ifc br1, ip 192.168.1.117, lease 86400, mac C0A801370102, hostname , vendorId _global_, clientId C0:A8:01:37:01:02, manufacturerOUI , serialNumber , productClass

All the IPs the router is assigning are available in our network.

Do you have any other suggestion?

Thanks for your help

Regards,

[Martin_]

error = ipcfg_bind_dhcp_wait(...);

if (error)

{

  printf("\nDHCP boot failed, error = %x.", error);

  return;

}

What is the error in your case ?

[Ardoster]

mmmm, the problem is that ipcfg_bind_dhcp_wait(...) returns always 0,

because when this function is not able to get an IP address via DHCP, it

assigns the default IP address. So, the returned value is 0 because this

default assignation is always OK.

What I can see is that, in ipcfg.c, function ipcfg_poll_dhcp_internal()

if (_lwsem_poll (&(ipcfg_data[device].dhcp_response_semaphore)))

{

if (ipcfg_data[device].actual_state == IPCFG_STATE_BUSY)

When the execution point enters the first condition, the second condition

is always different to IPCFG_STATE_BUSY (in fact, its value is UNBOUND), so

it is assigned an error = RTCSERR_IPCFG_BIND and it is proceed with the

default values.

Thanks you again for your help

On Fri, Oct 19, 2012 at 12:19 PM, Martin Latal <

[Martin_]

you should get a switch with port mirroring. this way you would be able to capture also dhcp server responses.

Port mirroring - Wikipedia, the free encyclopedia

let's try the other way round - in dhcpclnt.c there are 3 lines where DHCPCLNT_decline() function is called. Which one of the 3 possibilites executes ?

[Ardoster]

The first one:

packet_option = DHCP_find_option(opt, len, DHCPOPT_SERVERID);

if ( !packet_option || ntohc(packet_option + 1) != 4 ) {

/* Server id option is required in all DHCP responses */

DHCPCLNT_decline( dhcp_ptr, RTCSERR_DHCP_SERVER_OPTION_MISSING );

dhcp_ptr->NEW_DATA.ServerIp = *temp_addr;

*error = RTCSERR_DHCPCLNT_ERROR_DECLINED;

return 0;

} else {

packet_option += 2;

*current_ip = ntohl(packet_option);

} /* Endif */

In the other hand, I will try to know about the port mirroring posibilities.

Thanks you

On Fri, Oct 19, 2012 at 1:27 PM, Martin Latal <admin@community.freescale.com

[RayS]

Might be a physical problem.  Are you 100 or 10?  I had this exact problem using a microchip pic32 and a old phy 10 mb only.  Our layout had the +/- swapped.  The phy was able to deal with Auto MDIX, not +/- flipped.

It took forever to troubleshoot, it was never a problem with our MCF52233 with the built in 100mb phy.