[ofw] assert on ipoib_port.c @ 3629

[Tzachi Dar]

While rebooting a machine with our latest code I have received the
assert above:
 
  CL_ASSERT( p_cid[1] == 21 );

Child-SP          RetAddr           Call Site
fffffadf`8ef1a6e0 fffffadf`8f131e33 ipoib!__send_mgr_filter_dhcp+0x914
[q:\projinf2\trunk\ulp\ipoib\kernel\ipoib_port.c @ 3567]
fffffadf`8ef1a7a0 fffffadf`8f12fbff ipoib!__send_mgr_filter_udp+0xba3
[q:\projinf2\trunk\ulp\ipoib\kernel\ipoib_port.c @ 3470]
fffffadf`8ef1a810 fffffadf`8f12de06 ipoib!__send_mgr_filter_ip+0x96f
[q:\projinf2\trunk\ulp\ipoib\kernel\ipoib_port.c @ 3257]
fffffadf`8ef1a890 fffffadf`8f135daa ipoib!__send_mgr_filter+0x106
[q:\projinf2\trunk\ulp\ipoib\kernel\ipoib_port.c @ 2848]
fffffadf`8ef1a8e0 fffffadf`8f1371cd ipoib!__build_send_desc+0x5ba
[q:\projinf2\trunk\ulp\ipoib\kernel\ipoib_port.c @ 3956]
fffffadf`8ef1aa40 fffffadf`8f10d8e4 ipoib!ipoib_port_send+0xd9d
[q:\projinf2\trunk\ulp\ipoib\kernel\ipoib_port.c @ 4172]
fffffadf`8ef1ad50 fffffadf`8fd75b97 ipoib!ipoib_send_packets+0x244
[q:\projinf2\trunk\ulp\ipoib\kernel\ipoib_driver.c @ 1897]

 
I first must say that I have no idea why we never saw this assert.
 
The machine is configured with a static IP.
The machine is windows 2003 sp2.
 
I have looked at the packet that was sent and it seems "strange"
according to what happens in the spec:
 
1) (as expected) the packet is a broadcast message.
 
2) As for the IP addresses, the ip has a source in it. This is not what
expected.
 
3) the packet is a DHCPDISCOVER
 
4) the cid of the packet is 6 bytes long, which looks very strange (see
bitmap bellow). Actually this is the reason for the assert.
According to ethereal on the remote side this is the Mac addresses of
the computer, but I don't really see any connection between this numbers
and the Mac.
 
5) after that there comes a request for Parameter Request List with
option 0x36 (which is 6). This is a request for "Server Identifier".
Please see http://www.faqs.org/rfcs/rfc1533.html for more information.
 
6) The exact same packet is sent once with the IB network and once with
the Ethernet IP src (also on the ib network)
 
More info, if we ignore the assert, nothing happens on the remote side. 
 
Does anyone has an idea why all of a sudden windows is sending this
packet? (How does he know we have a release on Thursday? :-) )
 
On the receive side, we through this packet, and it doesn't go to
windows.
 
Ignoring the assert works well (we through the packet).
 
Does any one has an idea what should be done here?
 
I'm thinking that in the case of CID len != 0x21 we can send the packet
as is, and receive it as is.
Does this makes sense?
 
Thanks
Tzachi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20081111/f06d7a65/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: assert.JPG
Type: image/jpeg
Size: 137139 bytes
Desc: assert.JPG
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20081111/f06d7a65/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: assert.JPG
Type: image/jpeg
Size: 137139 bytes
Desc: assert.JPG
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20081111/f06d7a65/attachment-0001.jpe>