strange issue with ftp downloads

Hi,
one of my projects, cURL (btw. also used by Novell) shows some strange 
behaviour with latest NetWare: when I try to download a file via ftp then 
one byte 0x00 is appended. Interesting is that this issue does only happen 
with NW 6.5 SP6 (probably also with SP5 and below); but it doesnt happen 
with NW 6.0 SP5 + libc 9.00.05 (NetWare LIBC LIBCSP6a FTF Kit):
==============================================================
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  
Current
                                 Dload  Upload   Total   Spent    Left  
Speed
100   512  100   512    0     0     96      0  0:00:05  0:00:05 --:--:--    
0


6.5 SP6 + libc 9.00.04 (NetWare LIBC / CLIB NWLIB6i FTF Kit):
==============================================================
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  
Current
                                 Dload  Upload   Total   Spent    Left  
Speed
100   512  100   513    0     0     91      0  0:00:05  0:00:05 --:--:--  
142
curl: (18) transfer closed with -1 bytes remaining to read

my (yet unconfirmed) guess is that something within the TCP/IP stack 
changed, probably an errno return code (cURL uses BSD sockets); and this 
leads then to the behavior that the download callback of cURL thinks 
there's another byte for download which is not.

Here's the commandline tool for testing + a NCF which downloads the 
test.bin from a ftp server:
http://www.gknw.net/test/netware/testcurl.zip

The test.bin contains 2x 0-255 = 512 bytes.

please everybody who has few minutes try to confirm this issue since it 
seems to happen only depending on some TCP/IP version / service pack.

thanks, Gün.

Update:
I could nail down the issue to a protected space problem;
the curl commandline tool was linked with the option to always 
automatically load into ring3 - once I removed that and loaded in ring0 the 
download works!

Gün.

Guenter <devforums@novell.com> wrote in
news:6B9fi.905$Rg7.487@prv-forum2.provo.novell.com: 

> Hi,
> one of my projects, cURL (btw. also used by Novell) shows some strange 
> behaviour with latest NetWare: when I try to download a file via ftp
> then one byte 0x00 is appended. Interesting is that this issue does only
> happen with NW 6.5 SP6 (probably also with SP5 and below); but it doesnt
> happen with NW 6.0 SP5 + libc 9.00.05 (NetWare LIBC LIBCSP6a FTF Kit):
> ==============================================================
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time  
> Current
>                                  Dload  Upload   Total   Spent    Left  
> Speed
> 100   512  100   512    0     0     96      0  0:00:05  0:00:05 --:--:--
>    0
> 
> 
> 6.5 SP6 + libc 9.00.04 (NetWare LIBC / CLIB NWLIB6i FTF Kit):
> ==============================================================
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time  
> Current
>                                  Dload  Upload   Total   Spent    Left  
> Speed
> 100   512  100   513    0     0     91      0  0:00:05  0:00:05 --:--:--
>  142
> curl: (18) transfer closed with -1 bytes remaining to read
> 
> my (yet unconfirmed) guess is that something within the TCP/IP stack 
> changed, probably an errno return code (cURL uses BSD sockets); and this
> leads then to the behavior that the download callback of cURL thinks 
> there's another byte for download which is not.
> 
> Here's the commandline tool for testing + a NCF which downloads the 
> test.bin from a ftp server:
> http://www.gknw.net/test/netware/testcurl.zip
> 
> The test.bin contains 2x 0-255 = 512 bytes.
> 
> please everybody who has few minutes try to confirm this issue since it 
> seems to happen only depending on some TCP/IP version / service pack.
> 
> thanks, Gün.
> 
> 

Guenter wrote:
> Update:
> I could nail down the issue to a protected space problem;
> the curl commandline tool was linked with the option to always
> automatically load into ring3 - once I removed that and loaded in ring0 
> the
> download works!

By the way, I ported curl to CLIB (thanks to Guenter's work in porting it to 
LibC it was almost trivial), so we can start comparing these two, including 
their behavior in ring 3.

Dmitry

Hi Dmitry,

"Dmitry Mityugov" <dmitry.mityugov@gmail.com> wrote in
news:IP3hi.986$8i6.742@prv-forum2.provo.novell.com: 

> Guenter wrote:
>> Update:
>> I could nail down the issue to a protected space problem;
>> the curl commandline tool was linked with the option to always
>> automatically load into ring3 - once I removed that and loaded in
ring0
>> the
>> download works!
> 
> By the way, I ported curl to CLIB (thanks to Guenter's work in porting
> it to LibC it was almost trivial), so we can start comparing these two,
> including their behavior in ring 3.

that's mega-cool! If you have some patches let me know, and will see that we 
get those into the sources.

greets, Günter.

Hi,
"Dmitry Mityugov" <dmitry.mityugov@gmail.com> wrote in
news:IP3hi.986$8i6.742@prv-forum2.provo.novell.com: 

> Guenter wrote:
>> Update:
>> I could nail down the issue to a protected space problem;
>> the curl commandline tool was linked with the option to always
>> automatically load into ring3 - once I removed that and loaded in
ring0
>> the
>> download works!
> 
> By the way, I ported curl to CLIB (thanks to Guenter's work in porting
> it to LibC it was almost trivial), so we can start comparing these two,
> including their behavior in ring 3.
after Dmitry sent me his patches I did build a clib-based version, and this 
behaves exactly the same as the libc version: ring3 fails, and ring0 works!
So it seems to turn out that its a ring3 OS problem.....

Günter.