Bandu | 1 Jun 2010 13:49
Picon

Multicast packet will drop in ip.c

Hi,
 
I would like to check lwip 1.3.2 implementation about multicast/broadcast implementation.

even though, IP_SOF_BROADCAST_RECV & IP_SOF_BROADCAST defined, ip layer will drop all multicast and broadcast packet except DHCP protocol. Is this a bug or intended implementation?

// In ip.c

  if (check_ip_src)
  {  if ((ip_addr_isbroadcast(&(iphdr->src), inp)) ||
         (ip_addr_ismulticast(&(iphdr->src)))) {
      /* packet source is not valid */
      LWIP_DEBUGF(IP_DEBUG | LWIP_DBG_TRACE | 1, ("ip_input: packet source is not valid.\n"));
      /* free (drop) packet pbufs */
      pbuf_free(p);
      IP_STATS_INC(ip.drop);
      snmp_inc_ipinaddrerrors();
      snmp_inc_ipindiscards();
      return ERR_OK;
    }
  }

Regards,

--
Bandu
m.bandu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
David Empson | 2 Jun 2010 00:06
Picon
Favicon

Re: Multicast packet will drop in ip.c

The code you quoted dropping all packets which have a broadcast or multicast SOURCE address, which is illegal except in special conditions such as DHCP. Refer to RFC1122, which is mentioned in ip.c just above the bit you quoted.
 
LWIP can receive packets where the DESTINATION address is broadcast or multicast.
 
----- Original Message -----
From: Bandu
Sent: Tuesday, June 01, 2010 11:49 PM
Subject: [lwip-users] Multicast packet will drop in ip.c

Hi,
 
I would like to check lwip 1.3.2 implementation about multicast/broadcast implementation.

even though, IP_SOF_BROADCAST_RECV & IP_SOF_BROADCAST defined, ip layer will drop all multicast and broadcast packet except DHCP protocol. Is this a bug or intended implementation?

// In ip.c

  if (check_ip_src)
  {  if ((ip_addr_isbroadcast(&(iphdr->src), inp)) ||
         (ip_addr_ismulticast(&(iphdr->src)))) {
      /* packet source is not valid */
      LWIP_DEBUGF(IP_DEBUG | LWIP_DBG_TRACE | 1, ("ip_input: packet source is not valid.\n"));
      /* free (drop) packet pbufs */
      pbuf_free(p);
      IP_STATS_INC(ip.drop);
      snmp_inc_ipinaddrerrors();
      snmp_inc_ipindiscards();
      return ERR_OK;
    }
  }

Regards,

--
Bandu
m.bandu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

_______________________________________________
lwip-users mailing list
lwip-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Bandu | 2 Jun 2010 10:54
Picon

Re: Multicast packet will drop in ip.c

thanks David.
Is that also apply for UPnP, i mean get blocked, which multicast and, i also think, got source IP address so that client can unicast back to the source?
Regards,
 
Bandu
On Tue, Jun 1, 2010 at 11:06 PM, David Empson <david-5Em7NJ1W7vGlP80pJB477g@public.gmane.org> wrote:
The code you quoted dropping all packets which have a broadcast or multicast SOURCE address, which is illegal except in special conditions such as DHCP. Refer to RFC1122, which is mentioned in ip.c just above the bit you quoted.
 
LWIP can receive packets where the DESTINATION address is broadcast or multicast.
 
----- Original Message -----
From: Bandu
Sent: Tuesday, June 01, 2010 11:49 PM
Subject: [lwip-users] Multicast packet will drop in ip.c

Hi,
 
I would like to check lwip 1.3.2 implementation about multicast/broadcast implementation.

even though, IP_SOF_BROADCAST_RECV & IP_SOF_BROADCAST defined, ip layer will drop all multicast and broadcast packet except DHCP protocol. Is this a bug or intended implementation?

// In ip.c

  if (check_ip_src)
  {  if ((ip_addr_isbroadcast(&(iphdr->src), inp)) ||
         (ip_addr_ismulticast(&(iphdr->src)))) {
      /* packet source is not valid */
      LWIP_DEBUGF(IP_DEBUG | LWIP_DBG_TRACE | 1, ("ip_input: packet source is not valid.\n"));
      /* free (drop) packet pbufs */
      pbuf_free(p);
      IP_STATS_INC(ip.drop);
      snmp_inc_ipinaddrerrors();
      snmp_inc_ipindiscards();
      return ERR_OK;
    }
  }

Regards,

--
Bandu
m.bandu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

_______________________________________________
lwip-users mailing list
lwip-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
lwip-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
http://lists.nongnu.org/mailman/listinfo/lwip-users



--
Bandu
m.bandu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Brian Marshall | 2 Jun 2010 11:02
Picon
Favicon

Re: Multicast packet will drop in ip.c

I presume you mean SSDP when being used as part of Upnp? If so the SSDP 
messages are sent to the UPNP multicast address, but from the local 
address. You just need to join the multicast group and you can receive 
SSDP. See igmp_joingroup

-Brian.

Bandu wrote:
> thanks David.
> Is that also apply for UPnP, i mean get blocked, which multicast and, 
> i also think, got source IP address so that client can unicast back to 
> the source?
> Regards,
>  
> Bandu
Bandu | 2 Jun 2010 12:31
Picon

Re: Multicast packet will drop in ip.c

Yes. and thank for the help.

On Wed, Jun 2, 2010 at 10:02 AM, Brian Marshall <brianmarshall-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org> wrote:
I presume you mean SSDP when being used as part of Upnp? If so the SSDP messages are sent to the UPNP multicast address, but from the local address. You just need to join the multicast group and you can receive SSDP. See igmp_joingroup

-Brian.


Bandu wrote:
thanks David.
Is that also apply for UPnP, i mean get blocked, which multicast and, i also think, got source IP address so that client can unicast back to the source?
Regards,
 Bandu


_______________________________________________
lwip-users mailing list
lwip-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
http://lists.nongnu.org/mailman/listinfo/lwip-users



--
Bandu
m.bandu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Kentaro Yamamoto | 3 Jun 2010 03:13
Picon

tcp_write() keeps returning ERR_MEM indefinitely once the buffer is filled

Hi all,

I am trying to transfer a large amount of data from a microcontroller
via TCP/IP.  What I do is to keep executing tcp_write() until it
returns ERR_MEM.  The problem is that once tcp_write() returns
ERR_MEM, it keeps returning ERR_MEM no matter how long I wait..  Am I
missing something?  I am using lwip 1.3.1.

Thanks!

Kentaro

--

-- 
Kentaro Yamamoto
777@...
Noshaba Tariq | 3 Jun 2010 09:26
Picon

(no subject)

 HELLO
what is this term denotes in socket.h file "LWIP_COMPAT_SOCKETS  and  LWIP_POSIX_SOCKETS_IO_NAMES"

in function >>lwip_recv(int s, void *mem, int len, unsigned int flags);
what shoud b the value of flag..what does this mean?


when to use read(),write() and close()  functions?
when to use recv(a,b,c,d)  function?


thanx

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Kieran Mansley | 3 Jun 2010 10:39

Re: tcp_write() keeps returning ERR_MEM indefinitely once the buffer is filled

On Wed, 2010-06-02 at 21:13 -0400, Kentaro Yamamoto wrote:
> Hi all,
> 
> I am trying to transfer a large amount of data from a microcontroller
> via TCP/IP.  What I do is to keep executing tcp_write() until it
> returns ERR_MEM.  The problem is that once tcp_write() returns
> ERR_MEM, it keeps returning ERR_MEM no matter how long I wait..  Am I
> missing something?  I am using lwip 1.3.1.

Do you also have a call to tcp_output()?  tcp_write() will only queue
the packets, tcp_output() will get them going onto the wire.

Kieran
Kentaro Yamamoto | 3 Jun 2010 18:15
Picon

Re: tcp_write() keeps returning ERR_MEM indefinitely once the buffer is filled

Hi Kieran,

Thanks for the suggestion.  It actually turned out that executing
tcp_write continuously in a blocking manner in my tcp_recv callback
function was the cause.  Now I enqueue segments in a non-blocking
manner outside tcp_recv using a tcp_sent callback function.  This
works fine.

Thanks,

Kentaro

On Thu, Jun 3, 2010 at 4:39 AM, Kieran Mansley <kieran@...> wrote:
> On Wed, 2010-06-02 at 21:13 -0400, Kentaro Yamamoto wrote:
>> Hi all,
>>
>> I am trying to transfer a large amount of data from a microcontroller
>> via TCP/IP.  What I do is to keep executing tcp_write() until it
>> returns ERR_MEM.  The problem is that once tcp_write() returns
>> ERR_MEM, it keeps returning ERR_MEM no matter how long I wait..  Am I
>> missing something?  I am using lwip 1.3.1.
>
> Do you also have a call to tcp_output()?  tcp_write() will only queue
> the packets, tcp_output() will get them going onto the wire.
>
> Kieran
>
>
> _______________________________________________
> lwip-users mailing list
> lwip-users@...
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>

--

-- 
Kentaro Yamamoto
kentaro@...
Picon
Picon

Re: slow SSI tag rendering

I saw that one, too, and fixed it 2 or 3 weeks ago. Although I don't remember if I checked it in to CVS already (I just came back from holidays so forgive me for forgetting that). The bug was that the httpd stopped sending after parsing SSI data and only sent again after a timeout. By fixing that and always sending until the window is full, TX speed went back to normal (like for other pages without SSI).

Please have a look at CVS HEAD.

Simon


Chris Gili wrote:

I am attempting to use the raw httpd with SSI support, but with lwip 1.3.2.  Using it on an ARM7TDMI with no OS.

 

I have a web page with 45 tags in it, and it renders very slowly, as in two-three tags per second.  Looking at wireshark, I don’t see any retransmits.  With lwip tcp debug messages, I do get a lot of “tcp_enqueue: queue too long 17 (16)” messages.  I tried increasing  TCP_SND_QUEUELEN as mentioned in some older lwip-users archives, but then I start running out of memory (“tcp_enqueue: could not allocate memory for zero-copy pbuf”).  So I question whether tweaking config parameters will solve my issues.

 

Are 45 tags simply too many for one page?  My ssi handler function is just a switch statement, and seems very quick even with printf’s at the start and the end:  both outputs appear virtually simultaneously, so I don’t think the lost time is there.  I could toggle a LED and put a scope on it, if someone wants actual timing info.

 

I’m reluctant to upgrade the entire lwip stack.  Additionally, I don’t know that this is even the reason for the slow rendering of the SSI page; other non-SSI pages render very quickly (no noticeable wait time).  Any suggestions if I’m heading down the correct path or not?  Any particular outputs that would help diagnose this issue?  Is this just not going to work without upgrading lwip, too?

 

Thanks,
Chris

 

_______________________________________________ lwip-users mailing list lwip-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org http://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users

Gmane