subject:"\[edk2\] TFTP issue, Ping 1st packet reply missing"

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-29 Thread Laszlo Ersek

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.

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:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Leekha Shaveta
>> Sent: Tuesday, September 29, 2015 3:32 PM
>> To: Laszlo Ersek
>> Cc: edk2-devel@lists.01.org; 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:ler...@redhat.com]
>> Sent: Monday, September 28, 2015 6:30 PM
>> To: Leekha Shaveta-B20052 <shav...@freescale.com>
>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan
>> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-
>> Pang Lin <g...@suse.com>
>> 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
>>> 0x:  4500 0031 d64a  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
>>> 0x00

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-29 Thread Sharma Bhupesh

> From: Laszlo Ersek [mailto:ler...@redhat.com]
> 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:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Leekha Shaveta
> >> Sent: Tuesday, September 29, 2015 3:32 PM
> >> To: Laszlo Ersek
> >> Cc: edk2-devel@lists.01.org; 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:ler...@redhat.com]
> >> Sent: Monday, September 28, 2015 6:30 PM
> >> To: Leekha Shaveta-B20052 <shav...@freescale.com>
> >> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan
> >> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary
> >> Ching- Pang Lin <g...@suse.com>
> >> 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
>

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-29 Thread Sharma Bhupesh

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?

Regards,
Bhupesh


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Leekha Shaveta
> Sent: Tuesday, September 29, 2015 3:32 PM
> To: Laszlo Ersek
> Cc: edk2-devel@lists.01.org; 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:ler...@redhat.com]
> Sent: Monday, September 28, 2015 6:30 PM
> To: Leekha Shaveta-B20052 <shav...@freescale.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan
> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-
> Pang Lin <g...@suse.com>
> 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
> > 0x:  4500 0031 d64a  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
> > 0x:  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
> idhcbjsdc.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
> > 0x:  4500 0036 d64b  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 p

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-28 Thread Paolo Bonzini



On 28/09/2015 12:24, Leekha Shaveta wrote:
> Hi Laszlo,
> 
> Please find the detailed "tcpdump" on my setup:

You still aren't following Laszlo's instructions: "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"

Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-28 Thread Leekha Shaveta

Hi,

I am not using DHCP

I am setting IP statically using command:

Shell> ifconfig -s eth0 static 192.168.3.154 255.255.252.0 192.168.3.1
InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C DF5118B0
Shell> ping 192.168.3.221
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF5129E0
Ping 192.168.3.221 16 data bytes.
16 bytes from 192.168.3.221 : icmp_seq=1 ttl=0 time<0ms

1 packets transmitted, 1 received, 0% packet loss, time 0ms

Rtt(round trip time) min=0ms max=0ms avg=0ms
Shell>


Thanks and Regards,
Shaveta


-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini
Sent: Monday, September 28, 2015 4:57 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>; Laszlo Ersek 
<ler...@redhat.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gary Ching-Pang Lin 
<g...@suse.com>; Fu, Siyuan <siyuan...@intel.com>; Chris Cuthbert 
<nd6...@hotmail.com>
Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing



On 28/09/2015 12:24, Leekha Shaveta wrote:
> Hi Laszlo,
> 
> Please find the detailed "tcpdump" on my setup:

You still aren't following Laszlo's instructions: "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"

Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-28 Thread Laszlo Ersek

on 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:ler...@redhat.com] 
> Sent: Friday, September 25, 2015 11:09 PM
> To: Leekha Shaveta-B20052 <shav...@freescale.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang 
> Lin <g...@suse.com>
> 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:ler...@redhat.com]
>> Sent: Friday, September 25, 2015 3:11 PM
>> To: Leekha Shaveta-B20052 <shav...@freescale.com>
>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
>> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary 
>> Ching-Pang Lin <g...@suse.com>
>> 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:ler...@redhat.com]
>>> Sent: Friday, September 25, 2015 1:04 AM
>>> To: Leekha Shaveta-B20052 <shav...@freescale.com>
>>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
>>> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary 
>>> Ching-Pang Lin <g...@suse.com>
>>> 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/2638c111076f9a49d4766ca5acbafa0eb7f66a18/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 
&

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-25 Thread Laszlo Ersek

On 09/25/15 12:46, Leekha Shaveta wrote:
> 
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Friday, September 25, 2015 3:11 PM
> To: Leekha Shaveta-B20052 <shav...@freescale.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang 
> Lin <g...@suse.com>
> 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:ler...@redhat.com]
>> Sent: Friday, September 25, 2015 1:04 AM
>> To: Leekha Shaveta-B20052 <shav...@freescale.com>
>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
>> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary 
>> Ching-Pang Lin <g...@suse.com>
>> 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/2638c111076f9a49d4766ca5acbafa0eb7f66a18/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. :(
>>>
>&g

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-25 Thread Leekha Shaveta



-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, September 25, 2015 1:04 AM
To: Leekha Shaveta-B20052 <shav...@freescale.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
<siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang Lin 
<g...@suse.com>
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/2638c111076f9a49d4766ca5acbafa0eb7f66a18/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?

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:ler...@redhat.com]
>> Sent: Thursday, September 24, 2015 2:05 PM
>> To: Leekha Shaveta-B20052 <shav...@freescale.com>
>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
>> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary 
>> Ching-Pang Lin <g...@suse.com>
>> 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:edk2-devel-boun...@lists.01.org] On Behalf 
>>> Of Leekha Shaveta
>>> Sent: Thursday, September 24, 2015 11:15 AM
>>> To: edk2-devel@lists.01.org
>>> 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
>>>

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-25 Thread Leekha Shaveta



-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, September 25, 2015 3:11 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
<siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang Lin 
<g...@suse.com>
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:ler...@redhat.com]
> Sent: Friday, September 25, 2015 1:04 AM
> To: Leekha Shaveta-B20052 <shav...@freescale.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary 
> Ching-Pang Lin <g...@suse.com>
> 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/2638c111076f9a49d4766ca5acbafa0eb7f66a18/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.

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
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??

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:ler...@redhat.com]
>>> Sent: Thursday, September 24, 2015 2:05 PM
>>> To: Leekha Shaveta-B20052 <shav...@freescale.com>
>>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
>>> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary 
>>> Ching-Pang Lin <g...@suse.com>
>>> 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 im

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-25 Thread Laszlo Ersek

On 09/25/15 09:21, Leekha Shaveta wrote:
> 
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Friday, September 25, 2015 1:04 AM
> To: Leekha Shaveta-B20052 <shav...@freescale.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang 
> Lin <g...@suse.com>
> 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/2638c111076f9a49d4766ca5acbafa0eb7f66a18/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

> 
> 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:ler...@redhat.com]
>>> Sent: Thursday, September 24, 2015 2:05 PM
>>> To: Leekha Shaveta-B20052 <shav...@freescale.com>
>>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
>>> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary 
>>> Ching-Pang Lin <g...@suse.com>
>>> 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:edk2-devel-boun...@lists.01.org] On Behalf 
>>>> Of Leekha Shaveta
>>>> Sent: Thursday, September 24, 2015 11:15 AM
>>>> To: edk2-devel@lists.01.org
>>>> Subject: [edk2] Ping 1st packet reply missing
>>>>
>>>>

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-24 Thread Leekha Shaveta

Hi,

I more point to add.

With the same server configuration, UBOOT bootloader is able to do tftp 
successfully whereas UEFI fails.

Regards,
Shaveta

-Original Message-
From: Leekha Shaveta-B20052 
Sent: Thursday, September 24, 2015 2:52 PM
To: 'Laszlo Ersek' <ler...@redhat.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
<siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang Lin 
<g...@suse.com>
Subject: RE: [edk2] TFTP issue, Ping 1st packet reply missing

Hi Laszlo,

 What kind of " problematic DHCP or TFTP config "? What should be the right 
config for TFTP to work?

I have tftp file on TFTP server  "/etc/xinetd.d/tftp"  as follows :

service tftp
{
protocol= udp
port= 69
socket_type = dgram
wait= yes
user= root
server  = /usr/sbin/in.tftpd
server_args =  -c -s /tftpboot
disable = no
}

Tftp done:
Shell> tftp 192.168.3.230 test t2

TCPDUMP:
===
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
20:21:17.508537 ARP, Request who-has 192.168.3.230 tell 192.168.3.153, length 46
20:21:17.508548 ARP, Reply 192.168.3.230 is-at 68:05:ca:04:cd:99 (oui Unknown), 
length 28
20:21:17.562908 IP 192.168.3.153.2012 > 192.168.3.230.tftp:  21 RRQ "test" 
octet tsize 0
20:21:17.564335 IP 192.168.3.230.40029 > 192.168.3.153.2012: UDP, length 21

Does it give any hint??

Thanks and regards,
Shaveta

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Thursday, September 24, 2015 2:05 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
<siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang Lin 
<g...@suse.com>
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:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Leekha Shaveta
> Sent: Thursday, September 24, 2015 11:15 AM
> To: edk2-devel@lists.01.org
> 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 t

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-24 Thread Laszlo Ersek

On 09/24/15 11:23, Leekha Shaveta wrote:
> Hi Laszlo,
> 
>  What kind of " problematic DHCP or TFTP config "? What should be the right 
> config for TFTP to work?

I don't know. I can't give you an authoritative answer on that, first
because I'm not a trained sysadmin, and second because there are many
DHCP / TFTP servers, and many possible (and valid) configurations.

In my own test environment, I consulted the libvirt documentation about
network config: <http://libvirt.org/formatnetwork.html>. Once the right
settings are made in the virtual network definition (an XML file),
libvirt generates a matching config file for dnsmasq. I've never really
consulted this generated file, because I don't care as long as it works
-- it's libvirt's job to generate it.

I *have* however debugged DHCP config issue(s) on physical networks too;
for example in last November, when trying to PXE-boot an Aarch64 virtual
machine running on one physical host from a DHCP / TFTP server running
on another physical host on the same subnet. It didn't work initially,
and after a bunch of packet analysis, we had to update the DHCP config
on the server. (I forget the details, apologies. It was something
completely non-intuitive in the DHCP config.)

> I have tftp file on TFTP server  "/etc/xinetd.d/tftp"  as follows :
> 
> service tftp
> {
> protocol= udp
> port= 69
> socket_type = dgram
> wait= yes
> user= root
> server  = /usr/sbin/in.tftpd
> server_args =  -c -s /tftpboot
> disable = no
> }
> 
> Tftp done:
> Shell> tftp 192.168.3.230 test t2
> 
> TCPDUMP:
> ===
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 20:21:17.508537 ARP, Request who-has 192.168.3.230 tell 192.168.3.153, length 
> 46
> 20:21:17.508548 ARP, Reply 192.168.3.230 is-at 68:05:ca:04:cd:99 (oui 
> Unknown), length 28
> 20:21:17.562908 IP 192.168.3.153.2012 > 192.168.3.230.tftp:  21 RRQ "test" 
> octet tsize 0
> 20:21:17.564335 IP 192.168.3.230.40029 > 192.168.3.153.2012: UDP, length 21
> 
> Does it give any hint??

I have no clue about the server side. And, if we want to investigate
this, please capture and paste full details with tcpdump, for example with:

tcpdump -v -v -n -l -X -e

And please include the DHCP handshake too (discover / offer / request /
ack) -- if you use DHCP -- because DHCP can carry PXE-related options.

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.

... 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:ler...@redhat.com] 
> Sent: Thursday, September 24, 2015 2:05 PM
> To: Leekha Shaveta-B20052 <shav...@freescale.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang 
> Lin <g...@suse.com>
> 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 networ

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-24 Thread Leekha Shaveta

Hi Laszlo,

 What kind of " problematic DHCP or TFTP config "? What should be the right 
config for TFTP to work?

I have tftp file on TFTP server  "/etc/xinetd.d/tftp"  as follows :

service tftp
{
protocol= udp
port= 69
socket_type = dgram
wait= yes
user= root
server  = /usr/sbin/in.tftpd
server_args =  -c -s /tftpboot
disable = no
}

Tftp done:
Shell> tftp 192.168.3.230 test t2

TCPDUMP:
===
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
20:21:17.508537 ARP, Request who-has 192.168.3.230 tell 192.168.3.153, length 46
20:21:17.508548 ARP, Reply 192.168.3.230 is-at 68:05:ca:04:cd:99 (oui Unknown), 
length 28
20:21:17.562908 IP 192.168.3.153.2012 > 192.168.3.230.tftp:  21 RRQ "test" 
octet tsize 0
20:21:17.564335 IP 192.168.3.230.40029 > 192.168.3.153.2012: UDP, length 21

Does it give any hint??

Thanks and regards,
Shaveta

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, September 24, 2015 2:05 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
<siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang Lin 
<g...@suse.com>
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:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Leekha Shaveta
> Sent: Thursday, September 24, 2015 11:15 AM
> To: edk2-devel@lists.01.org
> 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 : ic

[edk2] TFTP issue, Ping 1st packet reply missing

2015-09-24 Thread Leekha Shaveta

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?

Thanks and Regards,
Shaveta

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leekha 
Shaveta
Sent: Thursday, September 24, 2015 11:15 AM
To: edk2-devel@lists.01.org
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' 
> >; 'Andrew 
> Fish' >; 
> 'edk2-devel@lists.01.org' 
> >; 'Tian, 
> Feng' >
> 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__ (40 bit 
> addressable) And its mapping on PCI bus is like:
> 50__ => _ (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:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tian, Feng
> Sent: Wednesday, August 26, 2015 7:24 AM
> To: Benjamin Herrenschmidt 
> >; Andrew 
> Fish >
> Cc: edk2-devel@lists.01.org 
> >; Tian, Feng 
> >
> 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:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Benjamin Herrenschmidt
> Sent: Wednesday, August 26, 2015 07:54
> To: Andrew Fish
> Cc: edk2-devel@lists.01.org
> 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.

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

Re: [edk2] TFTP issue, Ping 1st packet reply missing

[edk2] TFTP issue, Ping 1st packet reply missing

14 matches

Site Navigation

Mail list logo

Footer information