lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #27390] Source IP check in ip_input() causes it to dro


From: Mandeep Sandhu
Subject: [lwip-devel] [bug #27390] Source IP check in ip_input() causes it to drop valid DHCP packets
Date: Mon, 07 Sep 2009 07:42:11 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.13) Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13

URL:
  <http://savannah.nongnu.org/bugs/?27390>

                 Summary: Source IP check in ip_input() causes it to drop
valid DHCP packets
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: mandeepsandhu
            Submitted on: Mon 07 Sep 2009 07:42:10 AM GMT
                Category: IPv4
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.3.0

    _______________________________________________________

Details:

I'm running my ECOS application with lwIP 1.3.1. The app is a small DHCP
server (with limited functionality).

DHCP discover packets coming from clients have src addr as 0.0.0.0 and dst IP
as 255.255.255.255.

On reception of DHCP discover packets I see that the ip_input function drops
it:

...
...
lwip_recvfrom(0, 0x02001c64, 548, 0x0, ..)
lwip_recvfrom: top while sock->lastdata=0x00000000
ip_input: iphdr->dest 0xffffffff netif->ip_addr 0x101010b (0xffffff,
0x1010b, 0xff000000)
ip_input: packet accepted on interface et
ip_input: packet source is not valid.
...
...

On looking at the code, I see that we are intentionally dropping
packets with src IP as either broadcast or 0.0.0.0 (referred to as 'old
skool' bcast in code).

The variable "check_ip_src" also does not help as the only place where it is
reset is when we do a check on the UDP destination port (to see if it's a DHCP
client port or not). This does not work however, since we have found a 'netif'
by then. When searching for a 'netif' with a broadcast address, we will always
return with the _first_ netif struct and hence never do exception processing
for DHCP packets (where we reset the "check_ip_src" flag).

Moreover, the comment the place where we do src IP check says:

/* broadcast or multicast packet source address? Compliant with RFC 1122:
3.2.1.3 */

But a 0.0.0.0 address IS compliant with the RFC!
>From RFC 1122, section 3.2.1.3:

(a)  { 0, 0 }

                 This host on this network.  MUST NOT be sent, except as
                 a source address as part of an initialization procedure
                 by which the host learns its own IP address.

I guess they are talking about DHCP here. I think it should be ok to allow
0.0.0.0 as src IP.

Regards,
-mandeep





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?27390>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]