On Wed, 8 Mar 2006, Hans Rosenfeld wrote:

> Moin,
>
> On Sun, Mar 05, 2006 at 10:29:40PM -0800, Roger Ivie wrote:
>> Things were going well until I tried to FTP something FROM the VAX.
>> An attempt to fetch a file from the VAX using FTP stalls after 2K to
>> 64K have been transferred. This occurs whether the VAX is acting as the
>> FTP server or the client.
>>
>> I normally use the machine over the net via telnet and have not noticed
>> network trouble that affecting telnet.
>>
>> I am able to fetch files from the VAX using KERMIT over telnet.
>> Transfers using KERMIT over telnet are quick, so it does not appear to
>> be a general network issue.
>>
>> The VAX is connected via thinwire to a 10 megabit hub which connects via
>> twisted pair to my router, which connects to my PC (also running NetBSD
>> 3.0) via 100 megabit twisted pair. However, the problem is also seen by
>> a Macintosh (running MacOS X; it's one of those troublesome beige G3s
>> that have never been able to reliably boot NetBSD) attached to the 10
>> megabit hub, so it does not appear to be a network problem involving the
>> 10/100 transition at the router.
>
 	It probably will not make any difference as its at a completely
 	different layer, but does the behaviour change if you alter the
 	mtu of the interface (eg: ifconfig <if> mtu 1200)

> I did some research into that issue since my 4k90 showed the same
> strange behaviour after going from 2.1 to 3.0:
>
> Pinging other machines with a packet size of 4067 or less works, 4068 or
> more does not.
>
> Sniffing the packets generated by ping -s 4068 shows that the packet (that
> is, the 3rd fragment) contains random data beginning at byte offset 3280
> (at one time it contained /etc/man.conf, this was after I looked at the
> ping manpage).
>
> This problem seems to be related to the SGEC hardware, on machines with
> Lance ethernet or DELQA (it was actually a virtual DELQA simulated by
> simh since my QBus VAXen were not available) everything worked as expected.
>
> The problem does not exist in the 2.1 installation kernel.
>
> Any ideas where to look?

 	Diff the source for that driver between 2.1 and 3.0?

 	If there are too many changes, do a binary search on changes
 	to the kernel tree:
 	Install a 2.1 system, cvs update the source to halfway
 	between the 2.0 and 3.0 releases, build a kernel and test.
 	Repeat halfway between that version and 2.0 or 3.0 (depending
 	on whether it worked). After about 4 passes you should have
 	narrowed down the window of change

 	If you have the time to do this it could be of real help.


--
 	    David/absolute       -- www.NetBSD.org: No hype required --