hello Sir,
On Mon, Feb 8, 2010 at 5:25 PM, Joe Eykholt <[email protected]> wrote: > vinvishwa wrote: > >> Thank you sir for replying >> It made many things clear and also the problem with my configuration. >> >> but the issue with my configuration still remains unsolved. >> >> and you said its currently broken >> so is there any workaround to get my point to point setup working? >> > > > > >> * (*my setup in Sun Virtual Box >> *initiator*: 2.6.33-rc4 on Fedora Core 12 with fcoeadm tool >> *target*: 2.6.23 on Suse Linux Enterprise Server >> >> initiator-target connected over lossless connection in Sun >> Virtual Box(intel e1000 :bridged *pause frames enabled*) >> *)* >> > > Actually, I may have mis-spoken earlier. I just tried it and a similar > setup just worked for me. I'm running the same release on the initiator, > and the target is 2.6.23-1. I'm running on real servers, though, > not under a virtual machine. It really shouldn't matter, however, > as long as the virtual NIC works correctly. I'm running Fedora 8 > on my target, and Fedora 10 on the initiator. > > I tried it with the initiator having the larger WWPN and also with > the target having the larger WWPN, in case there was a bug > related to that. > > It will take a few retries for FLOGI to go through because > it waits to see if FIP will work first. > If it doesn't work for you, then I don't know what it is. > You could send me binary tcpdump capture and I might be able > to point out the problem. Use > > tcpdump -p -i ethX -w /tmp/file -s 0 > > before you do 'fcoeadm -c ethX' on the initiator side. i am attaching the tcp dump file also the wireshark tcpdump please have a look and help me solve the issue. You could also try putting the interface on both sides into > promiscuous mode, in case its a MAC filter problem. > > The reason I gave the -p parameter on tcpdump is so that > it *doesn't* go promiscuous, since it might hide the problem. > > Good luck, > Joe > > thank you. >> >> >> >> >> On Mon, Feb 8, 2010 at 11:39 PM, Joe Eykholt <[email protected] <mailto: >> [email protected]>> wrote: >> >> vinvishwa wrote: >> >> hi, >> i am trying to figure out the fcoe login process in a point to >> point >> architecture >> >> In my setup the *target sends out FLOGIs* (this is right as per the >> quickstart guide at open-fcoe) >> >> when the initiator is started it sends an *FIP solicitation* >> and then starts sending FLOGIs but is *not able to login* >> >> Can someone please elaborate the *point to point fcoe login* >> process >> >> >> It is currently broken. The old target expects a non-standard >> interface >> in which the other end accepts the FLOGI with the fabric flag off >> indicating >> point to point, and with the assigned FC_IDs in the FLOGI accept. >> I'm not sure why that's been broken in the initiator, but >> point-to-point >> mode hasn't been enough of a priority. >> >> The correct, standard FC way of doing it is for both sides to send a >> LS_ACC for FLOGI from fffffe to 0 and then for the one with the >> higher WWPN >> to decide the FC_IDs and do a PLOGI. >> >> There's a FIP proposal (at least one) to do VN to VN port without a >> fabric, >> and I hope we'll implement that at some point. >> >> The current initiator sends out both a FIP solicitation and non-FIP >> FLOGIs >> until it receives either a FIP frame, at which point it enters FIP >> mode, >> or an LS_ACC for the FLOGI, at which point it continues in non-FIP >> mode. >> >> >> Also i tried to figure out the fcoe initiator code but couldn't >> get the >> starting point >> Plz help me with the entry point of the code >> >> >> The module_init fcoe_init() is one entry point. Another is the code >> that handles >> the creation of an new initiator thru /sys write: fcoe_create(). >> >> Joe >> >> >> >> >> -- >> -vinvishwa >> >> > > -vinvishwa
_______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
