ftp only downloads filess smaller than 1447 bytes. Sometimes appears 'hung' on larger files.

[bouncer]

1) Start Haiku. 2) Connect to a BeOS machine via 'ftp'

(BTW - Thanks Hugo, for fixing the vm_page_fault problem).

3) Attempt to 'get' a file.

Particular details. a) First attempt was to fetch a file of approx. 5000 byes in size.

The ftp just sat there. I could see the cursor block give a pulse every second. But there was no acvitiy.

b) Something (I don't know what) caused ftp to break out of that with an

'interrupted system call' message. But 'ftp' did not die. I got the prompt back.

c) I kept trying to download various files. After some experimentation

I determined that ftp had the following behaviour.

• Files less than or equal to 1446 bytes in size would download successfully.
• Files greater than 1446 bytes but not too large ( less than 2000 ??? ) in size would not download. But would not 'hang' the ftp either.

o Ftp 'get' returned immediatly - with 0 bytes transferred. o A File of 0 bytes will have been created.

• Files of a large size (eg: 5000 bytes) would 'hang' the ftp operation. The 'get' operation never came back. A 'control-C' would however get the ftp cursor back again.

If not too large (eg: 1447 - 3000 ? ) the ftp would just return without having obtained the file

Hardware: This bug occured on real hardware. Using the e1000 network driver. The code compiled was at revision 21179.

Please see the attached file.

[bouncer]

ftp operation described in ticket.

[axeld]

I'm not sure if it's related, but when I download VLC from BeBits using wget, I also experience frequent hangs.

[hugosantos]

Axel, i thought i fixed that issue when you last reported it to me? Has it returned? And to bouncer, are you able to test with another driver/card besides e1000? I haven't had the chance to test it enough yet so i wouldn't expect it to be working correctly.

[bouncer]

Re: Testing with other drivers.This will be a problem.

My only other hardware options are the 3com and (maybe) the ipro100. Both of which are BSD compatibility drivers.

By the way. Neither the e1000 nor the 3com or ipro100 drivers are released with our standard haiku-image build. I needed to play with the Jam files to get any new drivers for testing.

ANOTHER BUG: The ipro100 driver will not compile for me. It gives this compile time error. /boot/home/haiku/src/add-ons/kernel/drivers/network/ipro100/dev/fxp/glue.c:3: macro `HAIKU_FBSD_DRIVER_GLUE' used with only 2 args . And the single line of 'code' in that module makes no sense anyway.

Will keep you posted if anthing new develops.

[hugosantos]

It is known ipro100 doesn't build right now. It is missing some required code to handle its interrupts. I'm missing some time right now, but i'll try to test e1000 a bit more this week.

[bouncer]

Test results: The 3com driver causes a vm_page_fault.

Do you want me to submit a separate bug report for the 3com driver ? Or is this also something you know about.

[hugosantos]

The 3com driver is also missing the interrupt handling code. It wasn't tested even yet. The only drivers i've tested minimally were e1000 and pcnet. The drivers are not included in the image for a reason: they aren't been tested enough yet and are still very experimental.

[hugosantos]

haven't, not aren't.

[axeld]

Replying to hugosantos:

Axel, i thought i fixed that issue when you last reported it to me? Has it returned?

At least BeBits still renders fine as far as I can tell, so it's probably not the same thing. I've tested with Marcus' ipro1000 on real hardware, btw. Can you reproduce it at all?

[hugosantos]

Replying to axeld:

Replying to hugosantos:

Axel, i thought i fixed that issue when you last reported it to me? Has it returned?

At least BeBits still renders fine as far as I can tell, so it's probably not the same thing. I've tested with Marcus' ipro1000 on real hardware, btw. Can you reproduce it at all?

I can reproduce this issue, i'll close it next. I don't see any hangs in wget, so please open up a ticket detailing that. It could still be some issue with congestion control.

[hugosantos]

Replying to bouncer:

1) Start Haiku. 2) Connect to a BeOS machine via 'ftp'

(BTW - Thanks Hugo, for fixing the vm_page_fault problem).

3) Attempt to 'get' a file.

Particular details. a) First attempt was to fetch a file of approx. 5000 byes in size.

The ftp just sat there. I could see the cursor block give a pulse every second. But there was no acvitiy.

b) Something (I don't know what) caused ftp to break out of that with an

'interrupted system call' message. But 'ftp' did not die. I got the prompt back.

c) I kept trying to download various files. After some experimentation

I determined that ftp had the following behaviour.

• Files less than or equal to 1446 bytes in size would download successfully.
• Files greater than 1446 bytes but not too large ( less than 2000 ??? ) in size would not download. But would not 'hang' the ftp either.

o Ftp 'get' returned immediatly - with 0 bytes transferred. o A File of 0 bytes will have been created.

• Files of a large size (eg: 5000 bytes) would 'hang' the ftp operation. The 'get' operation never came back. A 'control-C' would however get the ftp cursor back again.

If not too large (eg: 1447 - 3000 ? ) the ftp would just return without having obtained the file

Hardware: This bug occured on real hardware. Using the e1000 network driver. The code compiled was at revision 21179.

Please see the attached file.

hrev21195 should fix this issue. I've also been able to further test e1000 with success (did a couple large downloads). If you still get any issues regarding this specific issue, please re-open. If other problems arise, keep opening those bugs. And thanks for the help with testing.

[bouncer]

hrev21195 did fix the immediate problem. I can now ftp files bigger than 1446 bytes. However - there is a new limit at exactly 61300 bytes.

My downloads are being truncated to that size whenever I attempt to ftp a file which is larger than 61300 bytes.

Reproducing the bug: 1) Connect to a BeOS machine. Select a likely directory to download from. 2) Manually download files with the 'get <filename>' operation.

Results: a) The large file is always truncated. To exactly 61300 bytes. b) When the file is not too much bigger (eg: 93556 bytes). Ftp reports

"226 Transfer complete

61300 bytes received in ...."

c) When a much larger file is used (eg: 183674 bytes). Ftp sometimes reports an error.

"426 Data connection: General OS error.

61300 bytes received in ...."

[hugosantos]

Replying to bouncer:

hrev21195 did fix the immediate problem. I can now ftp files bigger than 1446 bytes. However - there is a new limit at exactly 61300 bytes.

This is not reproducible here with e1000. What about http downloads, do you get the same behavior? Are you able to build a custom system and provide me with the output of syslog? I would need you to edit src/add-ons/kernel/network/protocols/tcp/TCPEndpoint.cpp, line 53, and replace:

//#define TRACE_TCP

with

#define TRACE_TCP

Then build, run your system. Make a ftp download which doesn't work and provide me with /var/log/syslog.

Thanks

[bouncer]

Hugo - Sorry it took me so long. But here is the syslog that you asked for. I am attaching two text files and a screenshot. The big text file is the syslog of 'everything' leading up to the bad ftp transfer. The shorter text file, if I trimmed it down correctly, is the syslog for when I issued the ftp get' up until just after it finished its transfer. But it had only transfered some 61300 bytes. The third attachment. The screen image. Is of what the ftp transfer looked like.

Additional observations:

• Enabling the FTP_TRACE made the ftp process behave differently.
• About half the time now - it transfers the full file. It does its 'partial' file trick only rarely.
• A different behaviour has now manifested. The ftp file transfers are now really slow. Only About 2 - 4 Kilobytes per second. On some of my ftp transfer attempts it just slows down and stops. 0 kb per second. This can happen at any file size.
• Don't know if this has any meaning. But I observed the syslog file with a 'tail -f' while downloading. There was a definate rythym to the operation of the ftp. A bunch of lines would go by ending more or less with 'Received(): All inflight data ack'd'. Then the logs would pause for about 1 or two seconds while 3 or four lines of "ReadData(65535 bytes, flags 0x0)" would be printed out.

[hugosantos]

Replying to bouncer:

Hugo - Sorry it took me so long. But here is the syslog that you asked for.

No problem. Could you try hrev21248? This should fix a issue i saw in your TCP dump. There will still be a pending issue with haiku not reporting early enough dropped packets, but this should only affect the performance and not interfere with the download. I'll fix this one soon. Meanwhile, hrev21248 should fix the issue you are seeing. I'll wait for your reply to close this bug.

[marcusoverhagen]

Just FYI:

Perhaps this problem is related to PPPOE MTU size, which is normally 1492. Or a generic PMTU-D (Path MTU Discovery) failure. I don't know if our TCP properly implements PMTU ICMP.

[axeld]

The original problems describes a local connection. But anyway, we don't implement PMTU at all yet; our ICMP stuff is still pretty basic.

[bouncer]

I would recommend closing this ticket. The mis-behaviours I had orignally listed no longer show up.