<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>LPCXpresso IDEのトピックLPC17, uIP DHCP problem</title>
    <link>https://community.nxp.com/t5/LPCXpresso-IDE/LPC17-uIP-DHCP-problem/m-p/590881#M29338</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by FlySnake on Fri Feb 03 10:19:53 MST 2012&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;Hi everyone!&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;I have a strange problem with DHCP on uIP and FreeRTOS. Based on example CORTEX_LPC1768_GCC_RedSuite&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;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:&lt;/SPAN&gt;&lt;BR /&gt;&lt;TABLE border="1"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD bgcolor="#cacaca"&gt; &lt;PRE&gt;if(uip_newdata() &amp;amp;&amp;amp; parse_msg() == DHCPACK)
{
&amp;nbsp;&amp;nbsp;&amp;nbsp; struct dhcp_msg *m = (struct dhcp_msg *) p_appdata;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; s.state = STATE_CONFIG_RECEIVED;
&amp;nbsp;&amp;nbsp;&amp;nbsp; break;
}&lt;/PRE&gt; &lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;SPAN&gt;where parse_msg() is:&lt;/SPAN&gt;&lt;BR /&gt;&lt;TABLE border="1"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD bgcolor="#cacaca"&gt; &lt;PRE&gt;static u8_t parse_msg(void)
{
struct dhcp_msg *m = (struct dhcp_msg *) uip_appdata;

if (m-&amp;gt;op == DHCP_REPLY &amp;amp;&amp;amp; memcmp(m-&amp;gt;xid, xid, sizeof(xid)) == 0 &amp;amp;&amp;amp; memcmp(
m-&amp;gt;chaddr, s.mac_addr, s.mac_len) == 0)
{
memcpy(s.ipaddr, m-&amp;gt;yiaddr, 4);
return parse_options(&amp;amp;m-&amp;gt;options[4], uip_datalen());
}
return 0;
}&lt;/PRE&gt; &lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;SPAN&gt;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-&amp;gt;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?&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 16 Jun 2016 02:48:58 GMT</pubDate>
    <dc:creator>lpcware</dc:creator>
    <dc:date>2016-06-16T02:48:58Z</dc:date>
    <item>
      <title>LPC17, uIP DHCP problem</title>
      <link>https://community.nxp.com/t5/LPCXpresso-IDE/LPC17-uIP-DHCP-problem/m-p/590881#M29338</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by FlySnake on Fri Feb 03 10:19:53 MST 2012&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;Hi everyone!&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;I have a strange problem with DHCP on uIP and FreeRTOS. Based on example CORTEX_LPC1768_GCC_RedSuite&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;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:&lt;/SPAN&gt;&lt;BR /&gt;&lt;TABLE border="1"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD bgcolor="#cacaca"&gt; &lt;PRE&gt;if(uip_newdata() &amp;amp;&amp;amp; parse_msg() == DHCPACK)
{
&amp;nbsp;&amp;nbsp;&amp;nbsp; struct dhcp_msg *m = (struct dhcp_msg *) p_appdata;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; s.state = STATE_CONFIG_RECEIVED;
&amp;nbsp;&amp;nbsp;&amp;nbsp; break;
}&lt;/PRE&gt; &lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;SPAN&gt;where parse_msg() is:&lt;/SPAN&gt;&lt;BR /&gt;&lt;TABLE border="1"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD bgcolor="#cacaca"&gt; &lt;PRE&gt;static u8_t parse_msg(void)
{
struct dhcp_msg *m = (struct dhcp_msg *) uip_appdata;

if (m-&amp;gt;op == DHCP_REPLY &amp;amp;&amp;amp; memcmp(m-&amp;gt;xid, xid, sizeof(xid)) == 0 &amp;amp;&amp;amp; memcmp(
m-&amp;gt;chaddr, s.mac_addr, s.mac_len) == 0)
{
memcpy(s.ipaddr, m-&amp;gt;yiaddr, 4);
return parse_options(&amp;amp;m-&amp;gt;options[4], uip_datalen());
}
return 0;
}&lt;/PRE&gt; &lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;SPAN&gt;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-&amp;gt;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?&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 16 Jun 2016 02:48:58 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPCXpresso-IDE/LPC17-uIP-DHCP-problem/m-p/590881#M29338</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-16T02:48:58Z</dc:date>
    </item>
    <item>
      <title>Re: LPC17, uIP DHCP problem</title>
      <link>https://community.nxp.com/t5/LPCXpresso-IDE/LPC17-uIP-DHCP-problem/m-p/590882#M29339</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by djukazg on Sat Feb 04 05:04:21 MST 2012&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;I had similar problem. Just try to reset uip_flags variable after you receive messages from server.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;after "Offer" message:&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;TABLE border="1"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD bgcolor="#cacaca"&gt; &lt;PRE&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; if(uip_newdata() &amp;amp;&amp;amp; parse_msg() == DHCPOFFER) {
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; uip_flags &amp;amp;= ~UIP_NEWDATA;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; dhcp_s.state = STATE_OFFER_RECEIVED;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; break;
&amp;nbsp;&amp;nbsp;&amp;nbsp; }
&amp;nbsp;&amp;nbsp;&amp;nbsp; uip_flags &amp;amp;= ~UIP_NEWDATA;&lt;/PRE&gt; &lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;and after "ACK" message:&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;TABLE border="1"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD bgcolor="#cacaca"&gt; &lt;PRE&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; if(uip_newdata() &amp;amp;&amp;amp; parse_msg() == DHCPACK) {
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; uip_flags &amp;amp;= ~UIP_NEWDATA;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; dhcp_s.state = STATE_CONFIG_RECEIVED;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; break;
&amp;nbsp;&amp;nbsp;&amp;nbsp; }
&amp;nbsp;&amp;nbsp;&amp;nbsp; uip_flags &amp;amp;= ~UIP_NEWDATA;&lt;/PRE&gt; &lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Regards, &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Djuka&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 16 Jun 2016 02:48:59 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPCXpresso-IDE/LPC17-uIP-DHCP-problem/m-p/590882#M29339</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-16T02:48:59Z</dc:date>
    </item>
    <item>
      <title>Re: LPC17, uIP DHCP problem</title>
      <link>https://community.nxp.com/t5/LPCXpresso-IDE/LPC17-uIP-DHCP-problem/m-p/590883#M29340</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by FlySnake on Sat Feb 04 14:01:38 MST 2012&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;Wow! Thank you, Djuka. It works OK now!&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 16 Jun 2016 02:49:00 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPCXpresso-IDE/LPC17-uIP-DHCP-problem/m-p/590883#M29340</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-16T02:49:00Z</dc:date>
    </item>
  </channel>
</rss>

