LPC17, uIP DHCP problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC17, uIP DHCP problem

363 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by FlySnake on Fri Feb 03 10:19:53 MST 2012
Hi everyone!
I have a strange problem with DHCP on uIP and FreeRTOS. Based on example CORTEX_LPC1768_GCC_RedSuite
In uip's example dhcpc.h we have protothread with 2 cycles. First one sends DHCPDISCOVER and waiting for DHCPOFFER. Until now that's OK. The second one sends DHCPREQUEST and waiting for DHCPACK. Here is the problem. According to RF2131 every reply from dhcp server must contain message op code == 2 ((1 = BOOTREQUEST, 2 = BOOTREPLY). In the cycle we check the reply:
if(uip_newdata() && parse_msg() == DHCPACK)
{
    struct dhcp_msg *m = (struct dhcp_msg *) p_appdata;
     s.state = STATE_CONFIG_RECEIVED;
    break;
}

where parse_msg() is:
static u8_t parse_msg(void)
{
struct dhcp_msg *m = (struct dhcp_msg *) uip_appdata;

if (m->op == DHCP_REPLY && memcmp(m->xid, xid, sizeof(xid)) == 0 && memcmp(
m->chaddr, s.mac_addr, s.mac_len) == 0)
{
memcpy(s.ipaddr, m->yiaddr, 4);
return parse_options(&m->options[4], uip_datalen());
}
return 0;
}

The first check is message op code, which must be equal 2 (as this is reply). But actually this op code is equal 1, which means request. I've tried to listen traffic from my dhcpd on the PC with Wireshark, and it's OK, DHCPACK contains right message op code 2. But why uIP think that it is 1? And why the first cycle (DHCPDISCOVER->DHCPOFFER) works OK? There is a dirty hack: turning of the message type checking in second cycle and it works nice after that, but I don't think this is good idea. Any suggestion?
0 Kudos
2 Replies

252 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by FlySnake on Sat Feb 04 14:01:38 MST 2012
Wow! Thank you, Djuka. It works OK now!
0 Kudos

252 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by djukazg on Sat Feb 04 05:04:21 MST 2012
I had similar problem. Just try to reset uip_flags variable after you receive messages from server.

after "Offer" message:

    if(uip_newdata() && parse_msg() == DHCPOFFER) {
        uip_flags &= ~UIP_NEWDATA;
      dhcp_s.state = STATE_OFFER_RECEIVED;
      break;
    }
    uip_flags &= ~UIP_NEWDATA;


and after "ACK" message:

    if(uip_newdata() && parse_msg() == DHCPACK) {
        uip_flags &= ~UIP_NEWDATA;
      dhcp_s.state = STATE_CONFIG_RECEIVED;
      break;
    }
    uip_flags &= ~UIP_NEWDATA;



Regards,

Djuka
0 Kudos