> From: Laszlo Ersek [mailto:[email protected]] > Sent: Tuesday, September 29, 2015 5:52 PM > On 09/29/15 12:57, Sharma Bhupesh wrote: > > Thanks Laszlo for the very thorough description of the probable root- > cause. It helped a lot. > > > > One thing though, which makes me wonder if this is similar to a "Brand > > X USB3.0 mass storage drive doesn't work on my Brand Y USB host > > machine" case, as on this particular machine (also checked on a set of > co-located machines), the tftp server was able to work both with u-boot > Bootloader and Linux kernel for tftp based file transfer. > > > > So, while I understand this might be a tftp server version issue, do > > we need to fully check the explicit difference between the tftp > command/packet transfer sequence when done by uefi and say Linux? > > I think that the packet capture we've investigated until now is > sufficient to pinpoint the culprit. > > The difference in requirements between edk2 and other TFTP clients (eg. > Linux, u-boot etc) is that edk2 implements the EFI_MTFTP4_PROTOCOL > (defined in the UEFI spec). The GetInfo() member function of that > protocol places pretty high requirements on the server -- please consult > the UEFI spec. In particular the server needs to be an "MTFTPv4 server", > capable of sending "OACK", and -- as we can see it from the edk2 > implementation, and also the debugging thus far - that *requires* TFTP > option support in the server. > > If another TFTP client only needs RRQ without options, DATA, etc, like > (probably) many other TFTP clients do, then I guess less capable TFTP > servers can work as well. > > One possible improvement I can imagine for the UEFI spec (or, at least, > for the edk2 implementation) is to spell out exactly what RFCs the TFTP > server must support to be compliant. > > ... Actually, look at > "MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.h": > > Mtftp4 Implementation, it supports the following RFCs: > RFC1350 - THE TFTP PROTOCOL (REVISION 2) > RFC2090 - TFTP Multicast Option > RFC2347 - TFTP Option Extension > RFC2348 - TFTP Blocksize Option > RFC2349 - TFTP Timeout Interval and Transfer Size Options > > The comment says "supports". Maybe it should say "requires" instead, or > distinguish supports / requires on an RFC-by-RFC basis.
I agree that a "requires" here would make more sense. Regards, Bhupesh > But, I think the above is a quite good list to verify TFTP servers > against. > > Thanks > Laszlo > > > > > Regards, > > Bhupesh > > > > > >> -----Original Message----- > >> From: edk2-devel [mailto:[email protected]] On Behalf > >> Of Leekha Shaveta > >> Sent: Tuesday, September 29, 2015 3:32 PM > >> To: Laszlo Ersek > >> Cc: [email protected]; Gary Ching-Pang Lin; Fu, Siyuan; Chris > >> Cuthbert > >> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing > >> > >> Hi Laszlo, > >> > >> Many Thanks for your help !! > >> It actually worked well with latest tftp server (atftpd), so it > >> turned out to be a server issue (as you said rightly :) ) > >> > >> Some replies are inlined > >> > >> Thanks and Regards, > >> Shaveta > >> > >> > >> -----Original Message----- > >> From: Laszlo Ersek [mailto:[email protected]] > >> Sent: Monday, September 28, 2015 6:30 PM > >> To: Leekha Shaveta-B20052 <[email protected]> > >> Cc: [email protected] <[email protected]>; Fu, Siyuan > >> <[email protected]>; Chris Cuthbert <[email protected]>; Gary > >> Ching- Pang Lin <[email protected]> > >> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing > >> > >> On 09/28/15 12:24, Leekha Shaveta wrote: > >>> Hi Laszlo, > >>> > >>> Please find the detailed "tcpdump" on my setup: > >>> > >>> test@boardfram-OptiPlex-790:/tftpboot$ sudo tcpdump -v -v -n -l -X > >>> -e -i eth0 > >>> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture > >>> size > >>> 65535 bytes > >>> 21:39:42.028524 68:05:ca:04:d5:6a > 18:03:73:15:7b:12, ethertype > >>> IPv4 > >> (0x0800), length 63: (tos 0x0, ttl 64, id 54858, offset 0, flags > >> [none], proto UDP (17), length 49) > >>> 192.168.3.154.1051 > 192.168.3.221.69: [udp sum ok] 21 RRQ > "test" > >> octet tsize 0 > >>> 0x0000: 4500 0031 d64a 0000 4011 1baa c0a8 039a > >> E..1.J..@....... > >>> 0x0010: c0a8 03dd 041b 0045 001d d2e6 0001 7465 > >> .......E......te > >>> 0x0020: 7374 006f 6374 6574 0074 7369 7a65 0030 > >> st.octet.tsize.0 > >>> 0x0030: 00 . > >>> 21:39:42.030313 18:03:73:15:7b:12 > 68:05:ca:04:d5:6a, ethertype > >>> IPv4 > >> (0x0800), length 65: (tos 0x0, ttl 64, id 7770, offset 0, flags [DF], > >> proto UDP (17), length 51) > >>> 192.168.3.221.40480 > 192.168.3.154.1051: [udp sum ok] UDP, > >>> length > >> 23 > >>> 0x0000: 4500 0033 1e5a 4000 4011 9398 c0a8 03dd > >> E..3.Z@.@....... > >>> 0x0010: c0a8 039a 9e20 041b 001f 169a 0003 0001 > >> ................ > >>> 0x0020: 6969 6969 6964 6863 626a 7364 6320 7364 > >> iiiiidhcbjsdc.sd > >>> 0x0030: 6320 0a c.. > >>> 21:39:42.058922 68:05:ca:04:d5:6a > 18:03:73:15:7b:12, ethertype > >>> IPv4 > >> (0x0800), length 68: (tos 0x0, ttl 64, id 54859, offset 0, flags > >> [none], proto UDP (17), length 54) > >>> 192.168.3.154.1051 > 192.168.3.221.40480: [udp sum ok] UDP, > >>> length > >> 26 > >>> 0x0000: 4500 0036 d64b 0000 4011 1ba4 c0a8 039a > >> E..6.K..@....... > >>> 0x0010: c0a8 03dd 041b 9e20 0022 ed64 0005 0004 > >> .........".d.... > >>> 0x0020: 5573 6572 2061 626f 7274 6564 2064 6f77 > >> User.aborted.dow > >>> 0x0030: 6e6c 6f61 6400 nload. > >>> ^C > >>> 3 packets captured > >>> 3 packets received by filter > >>> 0 packets dropped by kernel > >>> > >>> > >>> Command I had run for tftp was: > >>> > >>> Shell> tftp 192.168.3.221 test t4 > >>> unicast promiscuous. > >>> PacketType 4 > >>> protocol 8 > >>> Src MAC Address: 18 3 73 15 7B 12 > >>> Dest MAC Address: 68 5 CA 4 D5 6A > >>> Failed to get the size of the file 'test' on 'eth0' - Protocol Error > >>> Shell> > >>> > >>> > >>> > >>> I have now compiled the code with latest ShellPkg and ran it. > >>> > >>> Does this log give any pointer, why Token state is getting "ABORTED" > >>> in > >> tftp? > >> > >> The reason I recommended the -X (more precisely, -l -X) options is > >> because the packets often contain ASCII strings that the source code > >> can be grepped for. (Clearly the source code that is responsible for > >> sending out that packet.) > >> > >> In this case, the 3rd packet (which is sent by edk2) contains "User > >> aborted download": > >> > >> $ git grep 'User aborted download' > >> > >> The one hit (restricting the results to IPv4) is in > >> "MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Rrq.c", function > >> Mtftp4RrqSaveBlock(). The documentation on that function is > >> > >> Deliver the received data block to the user, which can be saved in > the > >> user provide buffer or through the CheckPacket callback. > >> > >> The textual error message is passed by Mtftp4RrqSaveBlock() to > >> Mtftp4SendError(), and this branch depends on the > >> Token->CheckPacket() callback *failing*. Thus, we can say that the > >> Token->CheckPacket() function call rejects the 2nd packet. > >> > >> In addition, the Mtftp4RrqSaveBlock() function documents its own > >> EFI_ABORTED retval like this: > >> > >> The user tells to abort by return an error through CheckPacket > >> > >> [Shaveta] > >> I got to this point by putting some debug logs and it was getting > >> aborted from here only: > >> if (Token->CheckPacket != NULL) { > >> DEBUG((EFI_D_INFO, " Check packet from HERE: %r\n", Token- > >Status)); > >> Status = Token->CheckPacket (&Instance->Mtftp4, Token, (UINT16) > >> Len, Packet); > >> > >> if (EFI_ERROR (Status)) { > >> Mtftp4SendError ( > >> Instance, > >> EFI_MTFTP4_ERRORCODE_ILLEGAL_OPERATION, > >> (UINT8 *) "User aborted download" > >> ); > >> > >> return EFI_ABORTED; > >> } > >> } > >> > >> ... As far as I can see in this directory, EfiMtftp4GetInfo() > >> populates the CheckPacket function pointer with the address of > >> Mtftp4GetInfoCheckPacket(). So let's see what > >> Mtftp4GetInfoCheckPacket() > >> does: > >> > >> Apparently, this function *always* returns EFI_ABORTED (which in turn > >> always triggers the above branch in Mtftp4RrqSaveBlock()). However, > >> remember that it's only EfiMtftp4GetInfo() that sets up the > >> CheckPacket callback pointer like this. > >> > >> In addition, before returning EFI_ABORTED indiscriminately, > >> Mtftp4GetInfoCheckPacket() stores a status code in > >> ((MTFTP4_GETINFO_STATE *)Token->Context)->Status. > >> > >> Therefore, we can determine the following: when you use > >> Mtftp4RrqSaveBlock() as part of a "normal" download, the CheckPacket > >> callback ptr is NULL, and this doesn't happen. However, when you use > >> the same function as part of querying *metadata* of the remote file, > ie. > >> initiated from EfiMtftp4GetInfo(), then the callback function is > >> always set to Mtftp4GetInfoCheckPacket(), which will (a) abort the > >> transfer invariably after the first packet -- which is valid, we only > >> care about the metadata in the first packet --, and (b) it will store > >> a status code too in the context, "for later", ie. for the actual > >> download that is supposed to take place after the metadata have been > >> parsed on the edk2 side. > >> > >> And, in your case, this "actual" download doesn't seem to be > happening. > >> Why? > >> > >> [Shaveta] Read something similar: > >> Errors that are not really Errors. > >> TFTP is a file transfer protocol that does not have special > >> provisions for telling the client in advance the size of a file the > >> client is planning to retrieve. The client sometimes needs this > >> information for control or memory allocation purposes, then you will > >> see this kind of log > >> sequence: > >> > >> In such particular case: > >> > >> The client requests the say "abc" file. > >> The client quickly aborts the transfer, but it received the "abc" > >> file size from the first packet transmitted by the purposely stopped > transfer. > >> The client verifies the "abc" file size is within the expected values > >> and if everything is OK it requests a new transfer. > >> This time the transfer is completed. > >> > >> > >> > >> But I too was wondering that why Opcode that I am getting is "3" > >> which is incorrect, and why the actual download is not taking place. > >> So I got stuck :( > >> > >> Thanks for such a detailed explanation :) :) > >> > >> > >> > >> > >> > >> Well, in your UEFI shell log, I see "Protocol Error" -- in > >> Mtftp4GetInfoCheckPacket(), I see exactly one branch that does > >> > >> State->Status = EFI_PROTOCOL_ERROR; > >> > >> and that branch corresponds to > >> > >> NTOHS (Packet->OpCode) != EFI_MTFTP4_OPCODE_ERROR && > >> NTOHS (Packet->OpCode) != EFI_MTFTP4_OPCODE_OACK > >> > >> In other words, the TFTP server supposedly sends back an opcode, in > >> the 2nd packet, that is neither ERROR (5) nor OACK (6). > >> > >> For further analysis, we have to consult various RFCs: > >> > >> https://tools.ietf.org/html/rfc1350 -- "basic" TFTP > >> https://tools.ietf.org/html/rfc1782 -- TFTP Option Extension > >> https://tools.ietf.org/html/rfc2349 -- Transfer Size option > >> > >> Here's again the RRQ: > >> > >>> 192.168.3.154.1051 > 192.168.3.221.69: [udp sum ok] 21 RRQ > "test" > >> octet tsize 0 > >>> 0x0000: 4500 0031 d64a 0000 4011 1baa c0a8 039a > >> E..1.J..@....... > >>> 0x0010: c0a8 03dd 041b 0045 001d d2e6 0001 7465 > >>> .......E......te > >> ^ ^ ^ > >> | | | > >> IPv4 header ends here UDP hdr ends here | > >> OpCode = RRQ > >> > >>> 0x0020: 7374 006f 6374 6574 0074 7369 7a65 0030 > >>> st.octet.tsize.0 > >> ^ ^ ^ > >> | | | > >> filename ("test") ends here | | > >> | | > >> mode ("octet") ends here | > >> | > >> first TFTP option ("tsize") ends here > >> > >>> 0x0030: 00 . > >> ^ > >> | > >> first TFTP option value ("0") ends here > >> > >> So, in the first packet, edk2 composes a TFTP RRQ. The basic > >> structure is governed by RFC 1350. Then, it appends one option > >> (tsize=0). The general formatting for options is described in RFC > >> 1782; practically "append a sequence of NUL-terminated ASCII > >> strings". The actual option that edk2 appends is tsize\00\0, which is > described in RFC 2349. > >> > >> From RFC 2349, the meaning of tsize=0 is: > >> > >> In Read Request packets, a size of "0" is specified in the request > >> and the size of the file, in octets, is returned in the OACK. If > the > >> file is too large for the client to handle, it may abort the > transfer > >> with an Error packet (error code 3). [...] > >> > >> Meaning tsize=0 can be used to query the file size in advance. > >> > >> Now let's see how a TFTP server is allowed to answer to an RRQ that > >> has options (consult RFC 1782, section "Negotiation Protocol"): > >> > >> When the client appends options to the end of a Read Request > packet, > >> three possible responses may be returned by the server: > >> > >> OACK - acknowledge of Read Request and the options; > >> > >> DATA - acknowledge of Read Request, but not the options; > >> > >> ERROR - the request has been denied. > >> > >> Looking at the second packet: > >> > >>> 21:39:42.030313 18:03:73:15:7b:12 > 68:05:ca:04:d5:6a, ethertype > >>> IPv4 > >> (0x0800), length 65: (tos 0x0, ttl 64, id 7770, offset 0, flags [DF], > >> proto UDP (17), length 51) > >>> 192.168.3.221.40480 > 192.168.3.154.1051: [udp sum ok] UDP, > >>> length > >> 23 > >>> 0x0000: 4500 0033 1e5a 4000 4011 9398 c0a8 03dd > >> E..3.Z@.@....... > >>> 0x0010: c0a8 039a 9e20 041b 001f 169a 0003 0001 > >> ................ > >> ^ > >> | > >> OpCode = 3 (DATA) > >> > >>> 0x0020: 6969 6969 6964 6863 626a 7364 6320 7364 > >> iiiiidhcbjsdc.sd > >>> 0x0030: 6320 0a c.. > >> > >> > >> This means that the TFTP server acknowledges RRQ, but not the > >> options; specifically, tsize=0. > >> > >> Meaning the server starts the actual data transfer, instead of just > >> responding with the size of the file that the client (edk2) is > >> interested in, at the moment. > >> > >> This is why the EFI_PROTOCOL_ERROR branch is taken in > >> Mtftp4GetInfoCheckPacket(): because the TFTP server is incapable of > >> responding with *just* the remote file size, without the actual file > >> contents. This makes it very impractical to implement the > >> EFI_MTFTP4_PROTOCOL.GetInfo() member function. > >> > >> Solution: enable option parsing (according to at least RFC 1782 and > >> RFC > >> 2349) in your TFTP server, or use a more modern TFTP server. > >> > >> More details: I happen to have a debian box running on my desk. The > >> executable name from one of your earlier emails (from the xinetd > >> config > >> file) is "/usr/sbin/in.tftpd". I ran the following command: > >> > >> $ apt-file search /usr/sbin/in.tftpd > >> > >> (I had the impression that you were using Debian or Ubuntu.) > >> > >> Three packages were returned by apt-file, as providing that binary: > >> "atftpd", "tftpd", and "tftpd-hpa". > >> > >> Now look at their package descriptions: > >> > >> https://packages.debian.org/atftpd > >> > >> Multi-threaded TFTP server implementing all options (option > >> extension and multicast) as specified in RFC1350, RFC2090, > RFC2347, > >> RFC2348 and RFC2349. Atftpd also supports multicast protocol known > >> as mtftp, defined in the PXE specification. [...] > >> > >> https://packages.debian.org/tftpd > >> > >> Tftpd is a server which supports the Internet Trivial File > Transfer > >> Protocol (RFC 783). The TFTP server operates at the port indicated > >> in the `tftp' service description; see services(5). The server is > >> normally started by inetd(8). Tftpd is not suitable for use with > the > >> PXE bootloader; for that, use atftpd or tftpd-hpa. > >> > >> https://packages.debian.org/tftpd-hpa > >> > >> Trivial File Transfer Protocol (TFTP) is a file transfer protocol, > >> mainly to serve boot images over the network to other machines > >> (PXE). [...] > >> > >> You simply have the wrong package installed! Please install "atftpd" > >> instead of "tftpd", and retry. > >> > >> ... Once again, it seems proven that (a) most PXE / TFTP issues > >> experienced with edk2 exist on the server (or network) side, and (b) > >> you can fix many issues simply by reading documentation. > >> > >> Of course you can also ask others to read docs for you, and hope they > >> are interested... :) > >> > >> Laszlo > >> > >>> > >>> Thanks and Regards, > >>> Shaveta > >>> > >>> > >>> -----Original Message----- > >>> From: Laszlo Ersek [mailto:[email protected]] > >>> Sent: Friday, September 25, 2015 11:09 PM > >>> To: Leekha Shaveta-B20052 <[email protected]> > >>> Cc: [email protected] <[email protected]>; Fu, Siyuan > >>> <[email protected]>; Chris Cuthbert <[email protected]>; Gary > >>> Ching-Pang Lin <[email protected]> > >>> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing > >>> > >>> On 09/25/15 12:46, Leekha Shaveta wrote: > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Laszlo Ersek [mailto:[email protected]] > >>>> Sent: Friday, September 25, 2015 3:11 PM > >>>> To: Leekha Shaveta-B20052 <[email protected]> > >>>> Cc: [email protected] <[email protected]>; Fu, Siyuan > >>>> <[email protected]>; Chris Cuthbert <[email protected]>; Gary > >>>> Ching-Pang Lin <[email protected]> > >>>> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing > >>>> > >>>> On 09/25/15 09:21, Leekha Shaveta wrote: > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Laszlo Ersek [mailto:[email protected]] > >>>>> Sent: Friday, September 25, 2015 1:04 AM > >>>>> To: Leekha Shaveta-B20052 <[email protected]> > >>>>> Cc: [email protected] <[email protected]>; Fu, Siyuan > >>>>> <[email protected]>; Chris Cuthbert <[email protected]>; Gary > >>>>> Ching-Pang Lin <[email protected]> > >>>>> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing > >>>>> > >>>>> On 09/24/15 13:08, Laszlo Ersek wrote: > >>>>> > >>>>>> BTW when I wrote that I had just tested PXE boot, I didn't use > >>>>>> the UEFI shell utility; it was a network boot option instead. > >>>>> > >>>>> Now I tested the shell command too, in my usual virtual network > >> environment; it works fine for me. > >>>>> > >>>>> Thanks > >>>>> Laszlo > >>>>> > >>>>> I Too faced compilation issues, so I picked up > >>>>> "Guid/NicIp4ConfigNvData.h" file from tianocore site " > >> http://sourceforge.net/p/tianocore/edk2/ci/2638c111076f9a49d4766ca5ac > >> bafa 0eb7f66a18/tree/MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h" > >>>>> Copied it in Guid folder and my code compiled. > >>>>> > >>>>> Is this the correct file to compile the code with? > >>>> > >>>> No. Please pull the new commits; Jaben checked in the patch that > >>>> fixes > >> the build (on Windows at least, and I have a pending patch that fixes > >> it with gcc too). > >>>> > >>>> Thanks > >>>> Laszlo > >>>> > >>>> > >>>> Thanks Laszlo! > >>>> > >>>> I am not working on windows, so will wait for the patch that you > >>>> are > >> going to send to fix this. > >>> > >>> It is SVN r18553 now. > >>> > >>>> > >>>> I had captured TCPDUMP during TFTP on server: > >>>> test@boardfram-OptiPlex-790:/tftpboot$ sudo tcpdump -i eth0 > >>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol > >>>> decode > >>> > >>> Unfortunately, the parameters you passed to tcpdump are not ideal -- > >>> I > >> had proposed parameters up-thread that are more suitable for > >> debugging; please use those. > >>> > >>>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 > >>>> bytes > >>>> 22:04:50.929700 ARP, Request who-has 192.168.3.221 tell > >>>> 192.168.3.154, length 46 > >>>> 22:04:50.929720 ARP, Reply 192.168.3.221 is-at 18:03:73:15:7b:12 > >>>> (oui Unknown), length 28 > >>>> 22:04:50.988247 IP 192.168.3.154.ingreslock > 192.168.3.221.tftp: > >>>> 21 RRQ "test" octet tsize 0 > >>>> 22:04:50.990025 IP 192.168.3.221.50033 > 192.168.3.154.ingreslock: > >>>> UDP, length 23 > >>>> 22:04:51.013103 IP 192.168.3.154.ingreslock > 192.168.3.221.50033: > >>>> UDP, length 26 > >>>> > >>>> Any idea what is this "ingreslock" in these dump?? > >>> > >>> Sure. You didn't pass "-n" to tcpdump (despite my recommendation > >>> :)), > >> hence tcpdump tries to resolve both IP addresses to domain names, and > >> port numbers to service names (from /etc/services, and any other > >> sources configured in /etc/nsswitch.conf for service name resolution). > >>> "ingreslock" has no particular meaning here; it is port 1524, but > >>> for > >> endpoints that you do not bind explicitly, the system "randomly" > >> chooses a port number from a suitable range. > >>> > >>> In the TFTP client case, the target port (where the TFTP server > >>> lives) > >> is of course well known, but the source port is not bound by the > >> client explicitly (there's no reason to), hence the system assigns a > "random" > >>> source port number. In this case, it happened to be 1524, which is > >> "ingreslock", according to /etc/services. > >>> > >>> Service name resolution is frequently just a distraction with > >>> tcpdump, hence my proposal to use "-n". (Please consider the tcpdump > >>> parameters I had suggested before.) > >>> > >>> If, for any reason, you insist on specifying a source port number, > >> instead of the system-assigned one, the TFTP command's -l option can > >> accommodate that (see its help). > >>> > >>> ... Also, your dump is missing the DHCP packets that should be > >>> captured > >> while the ifconfig program (launched from the UEFI shell) brings up > >> the interface on which you later use TFTP. > >>> > >>> Laszlo > >>> > >>> > >>>> > >>>> Regards, > >>>> Shaveta > >>>> > >>>> > >>>>> > >>>>> Regards, > >>>>> Shaveta > >>>>> > >>>>>> > >>>>>> ... I tried to build the TFTP shell command into OVMF now, just > >>>>>> to test it, but it failed to compile, and the patch that > >>>>>> supposedly fixes it is not readable on the list. :( > >>>>>> > >>>>>> Thanks > >>>>>> Laszlo > >>>>>> > >>>>>>> > >>>>>>> Thanks and regards, > >>>>>>> Shaveta > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Laszlo Ersek [mailto:[email protected]] > >>>>>>> Sent: Thursday, September 24, 2015 2:05 PM > >>>>>>> To: Leekha Shaveta-B20052 <[email protected]> > >>>>>>> Cc: [email protected] <[email protected]>; Fu, Siyuan > >>>>>>> <[email protected]>; Chris Cuthbert <[email protected]>; Gary > >>>>>>> Ching-Pang Lin <[email protected]> > >>>>>>> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing > >>>>>>> > >>>>>>> On 09/24/15 08:04, Leekha Shaveta wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Tftp is also giving issues. > >>>>>>>> > >>>>>>>> During tftp, as one of its step it calls " GetFileSize" > >>>>>>>> Which go through Mtftp4 protocol and calls " Mtftp4->GetInfo" > >>>>>>>> > >>>>>>>> And this fails. > >>>>>>>> > >>>>>>>> Any idea what is the issue with tftp command? Has anyone tested > >>>>>>>> it > >> successfully? > >>>>>>> > >>>>>>> I frequently retest TFTP, and I just did it right now as well, > >>>>>>> on > >> top of current master. It works fine. My test environment is a > >> virtual network, where OVMF runs in a virtual machine, and DHCP and > >> TFTP are configured by libvirt and served by dnsmasq. The edk2 PXE > >> client downloads shim, then shim downloads grub (with the PXE Base > >> Code protocol), then grub downloads the kernel and the initial > >> ramdisk, for a networked linux installation. > >>>>>>> > >>>>>>> I have encountered and/or investigated quite a few TFTP issues, > >>>>>>> and most of the time they have occurred due to problematic DHCP > >>>>>>> or TFTP config, or problems in UEFI applications, or lower level > >>>>>>> network driver implementations. (In several other cases though, > >>>>>>> people contributed edk2 fixes ultimately.) > >>>>>>> > >>>>>>> Anyhow, the first thing to in such cases is to capture a > >>>>>>> detailed > >> packet log with tcpdump or wireshark, and analyze the packets against > >> the DHCP / TFTP server config, the DHCP / PXE specs, and the edk2 > code. > >> Usually (again, in my experience, although I don't claim to be an > >> expert), the DHCP / TFTP server config, or -- possibly -- the network > >> is the culprit. > >>>>>>> > >>>>>>> Please capture some packets, and analyze them. Analyzing DHCP > >> packets against the specs and the server config takes forever, but > >> I've found it to be the only way. Good luck. > >>>>>>> > >>>>>>> Thanks > >>>>>>> Laszlo > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks and Regards, > >>>>>>>> Shaveta > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: edk2-devel [mailto:[email protected]] On > >>>>>>>> Behalf Of Leekha Shaveta > >>>>>>>> Sent: Thursday, September 24, 2015 11:15 AM > >>>>>>>> To: [email protected] > >>>>>>>> Subject: [edk2] Ping 1st packet reply missing > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> My ping is working with Intel's E1000 driver code. > >>>>>>>> > >>>>>>>> But everytime 1st packet is not getting received successfully, > >>>>>>>> is > >> there some known issue here, or something to be set/missing? > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Shaveta > >>>>>>>> > >>>>>>>> Ping Snippet: > >>>>>>>> =========== > >>>>>>>> Shell> ping 192.168.3.1ping 192.168.3.1 -n 16 > >>>>>>>> InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD > >> DF56EA60 Ping 192.168.3.1 16 data bytes. > >>>>>>>> GigAdapter->cur_rx_ind: 0 > >>>>>>>> GigAdapter->cur_rx_ind: 1 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=2 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 2 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=3 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 3 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=4 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 4 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=5 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 5 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=6 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 6 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=7 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 7 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=8 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 0 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=9 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 1 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=10 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 2 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=11 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 3 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=12 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 4 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=13 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 5 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=14 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 6 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=15 ttl=0 time=1ms > >>>>>>>> GigAdapter->cur_rx_ind: 7 > >>>>>>>> 16 bytes from 192.168.3.1 : icmp_seq=16 ttl=0 time=1ms > >>>>>>>> > >>>>>>>> 16 packets transmitted, 15 received, 6% packet loss, time 15ms > >>>>>>>> > >>>>>>>> Rtt(round trip time) min=1ms max=1ms avg=1ms > >>>>>>>> > >>>>>>>> Sent 1 packet: > >>>>>>>> Shell> ping 192.168.3.1 -n 1 > >>>>>>>> InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD > >> DF56EA60 Ping 192.168.3.1 16 data bytes. > >>>>>>>> GigAdapter->cur_rx_ind: 4 > >>>>>>>> > >>>>>>>> 1 packets transmitted, 0 received, 100% packet loss, time 0ms > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Leekha Shaveta-B20052 > >>>>>>>>> Sent: Saturday, September 12, 2015 11:34 PM > >>>>>>>>> To: 'Benjamin Herrenschmidt' > >>>>>>>>> <[email protected]<mailto:[email protected]>>; > >>>>>>>>> 'Andrew Fish' <[email protected]<mailto:[email protected]>>; > >>>>>>>>> '[email protected]' > >>>>>>>>> <[email protected]<mailto:[email protected]>>; > >>>>>>>>> 'Tian, Feng' <[email protected]<mailto:[email protected]>> > >>>>>>>>> Subject: Re: PCI and non-1:1 mapping of MMIO space (Doubt o > >>>>>>>>> PCI Root bridge IOMap and IoAllocateBuffer) > >>>>>>>>> > >>>>>>>>> Hi > >>>>>>>>> > >>>>>>>>> I was implementing PCI RootBridgeIo protocol and have some > >>>>>>>>> doubts > >> in "IoMap" and "AllocateBuffer" functions of this protocol. > >>>>>>>>> > >>>>>>>>> In our platform, PCI space is starting form address > >> 0x50_0000_0000 (40 bit addressable) And its mapping on PCI bus is > like: > >>>>>>>>> 50_0000_0000 => 0000_0000 (32 bit) > >>>>>>>>> > >>>>>>>>> From where the "AllocateBuffer" function should allocate > >>>>>>>>> memory > >> when asked by any PCI device? > >>>>>>>>> What is the meaning of "Allocates pages that are suitable for > >>>>>>>>> an EfiPciOperationBusMasterCommonBuffer or > >>>>>>>>> EfiPciOperationBusMasterCommonBuffer64 mapping" > >>>>>>>>> > >>>>>>>>> How to manage mapping in "RootBridgeIoMap" function? > >>>>>>>>> > >>>>>>>>> Thanks and Regards, > >>>>>>>>> Shaveta > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: edk2-devel [mailto:[email protected]] On > >>>>>>>>> Behalf Of Tian, Feng > >>>>>>>>> Sent: Wednesday, August 26, 2015 7:24 AM > >>>>>>>>> To: Benjamin Herrenschmidt > >>>>>>>>> <[email protected]<mailto:[email protected]>>; > >>>>>>>>> Andrew Fish <[email protected]<mailto:[email protected]>> > >>>>>>>>> Cc: [email protected]<mailto:[email protected]> > >>>>>>>>> <[email protected]<mailto:[email protected]>>; Tian, > >>>>>>>>> Feng <[email protected]<mailto:[email protected]>> > >>>>>>>>> Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space > >>>>>>>>> > >>>>>>>>> Hi, Ben & Andrew > >>>>>>>>> > >>>>>>>>> The GetBarAttributes() returns a set of ACPI 2.0 resource > >> descriptors that describe the current configuration of the BARs of > >> the PCI controller. > >>>>>>>>> > >>>>>>>>> What I understood is the returned value of GetBarAttributes() > >>>>>>>>> is > >> a CPU address rather than a PCI address. From the view of PciIo, > >> nobody needs to know/use Bar's PCI address. > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> Feng > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: edk2-devel [mailto:[email protected]] On > >>>>>>>>> Behalf Of Benjamin Herrenschmidt > >>>>>>>>> Sent: Wednesday, August 26, 2015 07:54 > >>>>>>>>> To: Andrew Fish > >>>>>>>>> Cc: [email protected]<mailto:[email protected]> > >>>>>>>>> Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space > >>>>>>>>> > >>>>>>>>> (Argh, I keep sending these from my IBM address which isn't > >>>>>>>>> the > >> one on the list. Sorry Andrew for the duplicates). > >>>>>>>>> > >>>>>>>>> On Tue, 2015-08-25 at 14:48 -0700, Andrew Fish wrote: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> So if we stick to the definition of GetBarAttributes() only > >>>>>>>>>>> returning a BAR value, then it's impossible to implement a > >>>>>>>>>>> PCI GOP driver by following the spec. > >>>>>>>>>>> > >>>>>>>>>> I came to that conclusion too. > >>>>>>>>> > >>>>>>>>> :( > >>>>>>>>> > >>>>>>>>>>> Now, there's one thing that might work, which would be to > >>>>>>>>>>> exploit the "AddressTranslationOffset" field of the ACPI > >>>>>>>>>>> resource descriptor. > >>>>>>>>>>> > >>>>>>>>>> How do you represent a system like this in ACPI? It might be > >>>>>>>>>> a good idea to solve it in a similar way. > >>>>>>>>> > >>>>>>>>> Unfortunately, I am not familiar with the details of ACPI, I > >>>>>>>>> only > >> have a high level understanding of it. Our platforms have been Open > >> Firmware based for as far as I've been involved with them and lately, > >> we use C -generated flat device-tree along with a custom runtime > >> firmwarealled a OPAL). > >>>>>>>>> > >>>>>>>>> At this point I'm not (yet) considering a move to ACPI. I'm > >>>>>>>>> doing > >> a proof of concept ppc64 UEFI port to get a feel of the water > >> temperature more than anything else (though I'll be happy to > >> contribute things back once I get the appropriate legalese sorted > internally to IBM). > >>>>>>>>> > >>>>>>>>>> The PCI IO was designed to not required the 1:1 mapping. The > >>>>>>>>>> direct access to the Framebuffer came along later, as was > >>>>>>>>>> mostly a fallback for the OS on a safe mode boot kind of > thing. > >>>>>>>>>> I think we missed passing the frame buffer out on a system > >>>>>>>>>> that > >> was not 1:1. > >>>>>>>>> > >>>>>>>>> Ok. Well, it will be needed even on non-1:1 systems, we will > >>>>>>>>> have > >> similar requirements of the OS needing an early boot framebuffer > etc... > >>>>>>>>> and I suspect the desire to directly access BARs (at least > >>>>>>>>> prefetchable > >>>>>>>>> ones) from the CPU isn't going away in other areas either. > >>>>>>>>> > >>>>>>>>> So maybe we should try to address this. I'm trying to figure > >>>>>>>>> out > >> how to join the appropriate working groups etc... so I can > >> participate in the spec side discussion as well (which I'll need to > >> do for other reasons anyway if we are ever going to officially > >> defining the ppc64 ABI in the spec). > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> Ben. > >>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> Andrew Fish > >>>>>>>>>> > >>>>>>>>>>> Cheers, > >>>>>>>>>>> Ben. > >>>>>>>>> _______________________________________________ > >>>>>>>>> edk2-devel mailing list > >>>>>>>>> [email protected]<mailto:[email protected]> > >>>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >>>>>>>>> _______________________________________________ > >>>>>>>>> edk2-devel mailing list > >>>>>>>>> [email protected]<mailto:[email protected]> > >>>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >>>>>>>> _______________________________________________ > >>>>>>>> edk2-devel mailing list > >>>>>>>> [email protected] > >>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >>>>>>>> _______________________________________________ > >>>>>>>> edk2-devel mailing list > >>>>>>>> [email protected] > >>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >> _______________________________________________ > >> edk2-devel mailing list > >> [email protected] > >> https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
