LPC17, uIP DHCP problem

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
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;

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?