[Bug 1000046] New: BSD TCPIP asserts with "unregistered netisr handler" for ARP packets.

[bugzilla at ecoscentric dot com]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000046

           Summary: BSD TCPIP asserts with "unregistered netisr handler" for
                    ARP packets.
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: ARM
            Status: UNCONFIRMED
          Severity: normal
          Priority: normal
         Component: TCPIP
        AssignedTo: gary@mlbassoc.com
        ReportedBy: jay@systech.com
         QAContact: ecos-bugs@sources.redhat.com


Overview Description:
The BSD TCPIP stack routes ARP packets received on the ethernet interface prior 
to registering a handler with register_netisr().

In my configuration, there are 3 handlers registered: NETISR_IP,
NETISR_IPV6, and NETISR_ARP.  The first two are registered from the
cyg_hal_invoke_constructors(), before the network "ISR" thread runs.  The 
NETISR_ARP handler is not registered until much later.  It seems to get 
registered on the first SIOCSIFADDR ioctl(), which is typically made from the 
init_net() function, usually called from init_all_network_interfaces().  The 
call traceback is:

  init_net()->ioctl(SIOCSIFADDR)->ifioctl()->in_control()->
  in_ifioctl()->rtinit()->arp_rtrequest()->register_netisr().

If an ARP packet arrives on the interface before this time, it will cause
the assertion.  It seems like the NETISR_ARP handler should be registered
before the network "ISR" thread runs, so this cannot happen.  Perhaps from
some constructor.

Steps To Reproduce:

I discovered this problem (and made it reproducible) with an ethernet loopback 
test that our product uses.  When the test starts, it configures the network 
interface with init_net(), using a dummy IP address (192.168.1.1).  The 
SIOCSIFADDR ioctl() call results in the network stack sending out an ARP packet 
(for address 192.168.1.1), but because of the external loopback, the same 
packet is then received.  This happens before the handler has been registered 
for ARP.  I was able to work around this for the loopback test by first setting 
the IP address to INADDR_ANY (0.0.0.0), and then to 192.168.1.1.  It turns out 
that if the address set by the SIOCSIFADDR ioctl() is INADDR_ANY, it does not 
send the ARP request packet for it, and then completes the ARP initialization 
(registering the handler).  The second (and any subsequent) SIOCSIFADDR ioctls
() work fine.

This work around is fine for the special case of the loop back test, but it 
seems like there is a small possibility that an ARP packet could be seen and 
received by the ethernet interface during this time on any network.  Granted, 
this time window is usually very small.

Build Date & Platform
  AnonCVS 2003-06-19 on ARM7TDMI (Samsung S3C4510B)



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.