On Mon, Feb 02, 2009 at 12:06:05PM -0600, Mike Christie wrote: > > Konrad Rzeszutek wrote: > > On Mon, Feb 02, 2009 at 11:39:18AM +0100, Hans de Goede wrote: > >> Hi, > >> > >> When using 2-way chap and booting from an intel network card with intel > >> firmware initiator, their is no way to specify the username in the > >> firmware > >> initiator for the reverse chap, nor does it care what username the target > >> provides. > >> > >> However under sysfs (ibft) there is a reverse username attribute > >> (containing > >> garbage) and as this garbage is not provided by the target open-iscsi does > >> not > >> want to talk to the target. > > > > That is b/c the ibft module parses the iBFT structure and this is the > > offset where > > the reverse username attribute is at. You can insert a bunch of printks in > > the > > module and see data. > > > > Better yet, try this attached tool. I wrote it up some time with a > > different purpose > > in mind and just now converted it over to read from /dev/mem. Try it and > > see if the > > data comes out looking valid. > > > > (Last time I used it on an Intel NICs, they would insert 0xFF everywhere in > > the > > IBFT). > > > >> So how do we work around this? > > > > Try to use the IBM HS-20 (ibm-hs20-iscsi.lab.redhat.com, I think) > > > > Hey, so this is a problem with only intel nics? If so let's talk to the
A year ago that was the problem - you got something like this: konrad@/data/git/ibft$ hexdump intel_nic.bin 0000000 4269 5446 029c 0000 0001 4e49 4554 004c 0000010 0000 0000 0000 0000 0000 0000 0000 0000 * 0000030 ffff ffff ffff ffff ffff ffff ffff ffff * 0000290 ffff ffff ffff ffff ffff ffff 000029c Where the iBFT NIC and target structure are filled with 0xFF. Compared to the IBM HS-20: konrad@/data/git/ibft$ hexdump hs20.bin 0000000 4269 5446 017d 0000 a101 4249 004d 0000 0000010 4269 2046 2e31 0030 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 0000030 0101 0012 0000 0000 0048 0098 0100 0000 0000040 0000 0000 0000 0000 0102 004a 0300 0000 0000050 0000 0000 0000 0000 0000 0000 0000 0000 * 0000080 0000 0000 0000 0000 0000 0000 0000 0020 0000090 0136 0000 0000 0000 0103 0066 0700 0000 00000a0 0000 0000 0000 0000 ffff a8c0 294d 0016 00000b0 0000 0000 0000 0000 0000 ffff a8c0 fe4f 00000c0 0000 0000 0000 0000 0000 0000 0000 0000 * 00000f0 0000 1100 9d25 018b 0509 0000 0000 0000 0000100 0104 0036 0300 0000 0000 0000 0000 0000 0000110 ffff a8c0 744f 0cbc 0000 0000 0000 0000 0000120 0000 0025 0157 0000 0000 0000 0000 0000 0000130 0000 0000 0000 7169 2e6e 3032 3730 302d 0000140 2e37 6f63 3a6d 6f6b 726e 6461 692e 696e 0000150 6974 7461 726f 6900 6e71 322e 3030 2e37 0000160 6f63 2e6d 6e69 6574 2d6c 6273 3478 3a34 0000170 7473 726f 6761 2d65 3031 6267 0000 000017d (I can attach the binary blobs if that would make it easier.) > intel guys to see if they are going to fix it, or is already fixed by > just updating the firmware. I think due dillegence first - see if that little piece of C code I attached extracts a valid looking iBFT instead of garbage filled iBFT. If it is valid, it could be that the ibft module is doing something wrong. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
