Mon 07 Sep 2009 07:42:10 AM UTC, original submission:
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
|