|
Chris Richter(deleted)
09/04/2008 7:47 AM
post12805
|
Hi all,
I have the following problem:
I want to send a file from a windows pc (standard dos ftp client)
to a QNX Board, using xtemac IP core and devn-xtemac.so
If I send a file, it is almost completely received by the ftpd QNX.
In 50% of all FTP transfers the last TCP package is not received.
If the last TCP package in the FTP transfer has a special size
(e.g. 687 bytes), then the problem happens. It depend not
on the content of the package (I overwrote the content to
prove that). It depends only on the size of the last TCP package
of the FTP file transfer.
I'm using
- xtemac Xilinx IP core
- devn-xtemac.so
(calling /sbin/io-net -d xtemac ioport=0x80400000,irq=1,mac=00ee998283 -ptcpip)
- QNX 6.3.0 SP3
Does anyone has a suggestion what the problem could be?
Thank you and best regards,
Chris
|
|
|
|
|
|
Robert Craig
|
RE: FTP Problems with xtemac
|
|
Robert Craig
09/04/2008 10:29 AM
post12820
|
RE: FTP Problems with xtemac
This sound awfully familiar... I'll do some digging around but I seem
to remember that the last time that I saw something like this, it turned
out to be a problem with the driver occasionally losing a receive
interrupt. The packets get left in the hardware buffers and are
retrieved when the next packet comes in when the driver drops into a
polling loop. Depending upon the traffic patterns, this would result in
the last packet getting stuck in the hardware.
One thing that would be worthwhile trying is to ping the board
from the windows PC as soon as the FTP session gets stuck. If the pings
go through, does your FTP session all of a sudden complete?
Robert.
-----Original Message-----
From: Chris Richter [mailto:community-noreply@qnx.com]
Sent: Thursday, September 04, 2008 7:48 AM
To: drivers-networking
Subject: FTP Problems with xtemac
Hi all,
I have the following problem:
I want to send a file from a windows pc (standard dos ftp client)
to a QNX Board, using xtemac IP core and devn-xtemac.so
If I send a file, it is almost completely received by the ftpd QNX.
In 50% of all FTP transfers the last TCP package is not received.
If the last TCP package in the FTP transfer has a special size
(e.g. 687 bytes), then the problem happens. It depend not
on the content of the package (I overwrote the content to
prove that). It depends only on the size of the last TCP package
of the FTP file transfer.
I'm using
- xtemac Xilinx IP core
- devn-xtemac.so
(calling /sbin/io-net -d xtemac ioport=0x80400000,irq=1,mac=00ee998283
-ptcpip)
- QNX 6.3.0 SP3
Does anyone has a suggestion what the problem could be?
Thank you and best regards,
Chris
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post12805
|
|
|
|
|
|
Chris Richter(deleted)
|
Re: RE: FTP Problems with xtemac
|
|
Chris Richter(deleted)
09/04/2008 10:57 AM
post12821
|
Re: RE: FTP Problems with xtemac
> One thing that would be worthwhile trying is to ping the board
>from the windows PC as soon as the FTP session gets stuck. If the pings
>go through, does your FTP session all of a sudden complete?
No, if the FTP session gets stuck, and I try a ping, nothing happens
to the FTP transfer.
The ping itself works.
The only thing, which is missing, is the "226 Transfer Complete" message
from the QNX board.
But it seems, that the ftpd does not get the last package, although it
is sent by the ftp client (I sniffed the data traffic with ethereal).
The file in the shared memory has exactly the size = file_size - size_last_tcp_package.
But back to your interrupt assumption:
Is it possible that there is a register etc., which is
used by the driver to decide whats the interrupt reason (e.g.
by using a bit), and this check fails?
If the last package is not received from the ftpd, then there is
a retransmit of the FTP client. Sometimes, this retransmit helps,
sometimes not.
Thank you,
Christian Richter
|
|
|
|
|
|
Robert Craig
|
RE: RE: FTP Problems with xtemac
|
|
Robert Craig
09/04/2008 12:15 PM
post12837
|
RE: RE: FTP Problems with xtemac
Hi Christian:
We're in the process of getting you a copy of the driver source
for you to build and try out.
Robert.
-----Original Message-----
From: Chris Richter [mailto:community-noreply@qnx.com]
Sent: Thursday, September 04, 2008 10:58 AM
To: drivers-networking
Subject: Re: RE: FTP Problems with xtemac
> One thing that would be worthwhile trying is to ping the board
>from the windows PC as soon as the FTP session gets stuck. If the
pings
>go through, does your FTP session all of a sudden complete?
No, if the FTP session gets stuck, and I try a ping, nothing happens
to the FTP transfer.
The ping itself works.
The only thing, which is missing, is the "226 Transfer Complete" message
from the QNX board.
But it seems, that the ftpd does not get the last package, although it
is sent by the ftp client (I sniffed the data traffic with ethereal).
The file in the shared memory has exactly the size = file_size -
size_last_tcp_package.
But back to your interrupt assumption:
Is it possible that there is a register etc., which is
used by the driver to decide whats the interrupt reason (e.g.
by using a bit), and this check fails?
If the last package is not received from the ftpd, then there is
a retransmit of the FTP client. Sometimes, this retransmit helps,
sometimes not.
Thank you,
Christian Richter
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post12821
|
|
|
|
|
|
Chris Richter(deleted)
|
Re: RE: RE: FTP Problems with xtemac
|
|
Chris Richter(deleted)
09/10/2008 3:50 AM
post13133
|
Re: RE: RE: FTP Problems with xtemac
Hi,
thank you, with the source code this problem was solved.
All I had to do was to compile the source code using
the correct device id.
[The error was that in 50% of all testcases the ftp transfer fails, if the
last TCP packet size modulo 4 is equal to 0.]
But: I have found a new bug (which was already existing
in the previous version of the xtemac driver, I checked this):
- The network cable is unplugged, reboot of the board
- Calling "io-net xtemac ...", works, io-net process is running in the background
- ifconfig en0 193.168.0.127, fails, "ifconfig: socket: Address family not supported by protocol family", /dev/socket
not existing ...
So it is not possible to start the board without network connection,
plug in the cable during runtime, and get the network working during
runtime of the board.
- However, if I redo the ifconfig two times:
- ifconfig en0 193.168.0.192 => works
- ifconfig en0 193.168.0.127 => works
Remark:
Current version:
CvsId[] UNUSED = "$RCSfile: receive.c,v $ $Revision: 156645 $ $Date: 2007-10-24 16:48:07 +0200 (Wed, 24 Oct 2007) $";
Previous version:
CvsId[] UNUSED = "$RCSfile: receive.c,v $ $Revision: 150010 $ $Date: 2007-07-20 17:24:35 -0400 (Fri, 20 Jul 2007) $";
Which of the source code of the xtemac files are responsible/related to
the network configuration?
Best regards,
Christian Richter
|
|
|
|
|
|
Robert Craig
|
RE: RE: RE: FTP Problems with xtemac
|
|
Robert Craig
09/10/2008 7:49 AM
post13142
|
RE: RE: RE: FTP Problems with xtemac
Hi Christian:
The "Address family not supported" means that the IP stack hasn't been started, so what must be happening is that
the driver is "waiting" somewhere during initialization and this prevents io-net from initializing the IP stack.
Normally during bootup we add a "waitfor /dev/en0" "waitfor /dev/socket" in the startup script after starting io-net,
but if the driver doesn't initialize without a cable being plugged in, then this will obviously be a problem.
With the cable plugged in at the beginning, does everything initialize as expected?
Without the cable plugged in, will ifconfig eventually show an interface or does it always return with an error? What
does pidin report in this case?
Robert.
-----Original Message-----
From: Chris Richter [mailto:community-noreply@qnx.com]
Sent: Wed 9/10/2008 3:50 AM
To: drivers-networking
Subject: Re: RE: RE: FTP Problems with xtemac
Hi,
thank you, with the source code this problem was solved.
All I had to do was to compile the source code using
the correct device id.
[The error was that in 50% of all testcases the ftp transfer fails, if the
last TCP packet size modulo 4 is equal to 0.]
But: I have found a new bug (which was already existing
in the previous version of the xtemac driver, I checked this):
- The network cable is unplugged, reboot of the board
- Calling "io-net xtemac ...", works, io-net process is running in the background
- ifconfig en0 193.168.0.127, fails, "ifconfig: socket: Address family not supported by protocol family", /dev/socket
not existing ...
So it is not possible to start the board without network connection,
plug in the cable during runtime, and get the network working during
runtime of the board.
- However, if I redo the ifconfig two times:
- ifconfig en0 193.168.0.192 => works
- ifconfig en0 193.168.0.127 => works
Remark:
Current version:
CvsId[] UNUSED = "$RCSfile: receive.c,v $ $Revision: 156645 $ $Date: 2007-10-24 16:48:07 +0200 (Wed, 24 Oct 2007) $";
Previous version:
CvsId[] UNUSED = "$RCSfile: receive.c,v $ $Revision: 150010 $ $Date: 2007-07-20 17:24:35 -0400 (Fri, 20 Jul 2007) $";
Which of the source code of the xtemac files are responsible/related to
the network configuration?
Best regards,
Christian Richter
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post13133
|
|
|
|
|
|
Chris Richter(deleted)
|
Re: RE: RE: RE: FTP Problems with xtemac
|
|
Chris Richter(deleted)
09/10/2008 9:59 AM
post13149
|
Re: RE: RE: RE: FTP Problems with xtemac
Hi Robert,
> Normally during bootup we add a "waitfor /dev/en0" "waitfor /dev/socket" in
> the startup script after starting io-net, but if the driver doesn't initialize
> without a cable being plugged in, then this will obviously be a problem.
Yes, because the board reboots again and again.
> With the cable plugged in at the beginning, does everything initialize as
> expected?
Yes, in this case, everything works fine.
> Without the cable plugged in, will ifconfig eventually show an interface or
> does it always return with an error? What does pidin report in this case?
If I call ifconfig without configuration parameter, it fails, if the network cable is unplugged.
But then, if I call the ifconfig with configuration parameter, sometimes it works, sometimes not.
Pidin reports:
1155081 1 sbin/io-net 10r SIGWAITINFO
1155081 2 sbin/io-net 21r RECEIVE 5
1155081 3 sbin/io-net 10r RECEIVE 1
1155081 4 sbin/io-net 10r RECEIVE 1
1155081 5 sbin/io-net 20r RECEIVE 9
So far, I can not determine the "special" condition.
How can I continue?
Best regards,
Christian
|
|
|
|
|
|
Robert Craig
|
RE: RE: RE: FTP Problems with xtemac
|
|
Robert Craig
09/10/2008 3:32 PM
post13201
|
RE: RE: RE: FTP Problems with xtemac
Hi Christian:
I've created a PR to (PR60894) that you can use to get
information on how the debugging is going.
Robert.
-----Original Message-----
From: Chris Richter [mailto:community-noreply@qnx.com]
Sent: Wednesday, September 10, 2008 3:50 AM
To: drivers-networking
Subject: Re: RE: RE: FTP Problems with xtemac
Hi,
thank you, with the source code this problem was solved.
All I had to do was to compile the source code using
the correct device id.
[The error was that in 50% of all testcases the ftp transfer fails, if
the
last TCP packet size modulo 4 is equal to 0.]
But: I have found a new bug (which was already existing
in the previous version of the xtemac driver, I checked this):
- The network cable is unplugged, reboot of the board
- Calling "io-net xtemac ...", works, io-net process is running in the
background
- ifconfig en0 193.168.0.127, fails, "ifconfig: socket: Address family
not supported by protocol family", /dev/socket not existing ...
So it is not possible to start the board without network connection,
plug in the cable during runtime, and get the network working during
runtime of the board.
- However, if I redo the ifconfig two times:
- ifconfig en0 193.168.0.192 => works
- ifconfig en0 193.168.0.127 => works
Remark:
Current version:
CvsId[] UNUSED = "$RCSfile: receive.c,v $ $Revision: 156645 $ $Date:
2007-10-24 16:48:07 +0200 (Wed, 24 Oct 2007) $";
Previous version:
CvsId[] UNUSED = "$RCSfile: receive.c,v $ $Revision: 150010 $ $Date:
2007-07-20 17:24:35 -0400 (Fri, 20 Jul 2007) $";
Which of the source code of the xtemac files are responsible/related to
the network configuration?
Best regards,
Christian Richter
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post13133
|
|
|
|
|
|
