From mint-bounce@lists.fishpool.fi Tue Aug 17 18:12:58 2010 Date: Tue, 17 Aug 2010 18:08:23 -0400 (EDT) From: Keith Scroggins To: Miro Kropacek cc: MiNT Mailing List Subject: Re: [MiNT] Serious issue with networking In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: kws@radix.net Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Hello Miro, I am also having some networking issues with ethernec, but using a different driver currently (from assemsoft page). I can not seem to establish an incoming ssh or scp connection beyond initial handshake and supplying password, and I know sshd was previously working with the older kernel. Telnet is fine though. but I have had some wierdness with vi and editing files (thru telnet) as well, that did not exist previously. Not looked into this either, but I end up needing to kill vi from another session.... Seems if I type commands too quickly, vi just freezes. Once I kill it, I drop back to bash fine. Again, not looked into it much, was happening to me when I was editing RPM specs. Fresh setup with kernel from Friday (I think), and almost no auto programs (NVDI and ExtendDOS only right now). Beyond that, have not done much troubleshooting as I thought maybe my sshd_config was hosed and am only mentioning this because of your post. Keith On Tue, 17 Aug 2010, Miro Kropacek wrote: > Hi, > > I just discovered very bad bug introduced in 1.17 kernel -- my > ethernec driver stopped to work reliably. I use some kind of TFTP > protocol for fast exchange between Falcon/CT60 and my laptop, > basically I stripped FreeMiNT set to prg + 10 lines cnf + inet4.xdd + > enec6.xif (from ct60 package) + my server app as INIT=. In 1.16, > everything works fine, I send command for start uploading, I upload a > file. In 1.17, in 75% of cases happens following: > - received 1 byte (message) > - received 4 bytes (length) > - received 4351 bytes of 122973 (data) > - received 4380 bytes > - received 5840 bytes > - infinite wait on next recv() > > Received chunk sizes vary. On client side, I do send (1 byte), send (4 > bytes), send (122973 bytes). My code is debugged and proven to work > for many months, so there shouldn't be a problem. > > I'm not sure what I can do, I can provide both Linux and FreeMiNT > binaries/sources of my client/server app if needed. It seems like some > buffering / timing problem since 1.16 is really bullet-proof, I can > even run app in supervisor while sending packets from Linux and then > go back to my server app and everything is correctly received... > Wasn't there *any* changes which could at least remotely cause this? I > can test various builds but surely I don't want to spend time testing > *each* commit :) Something like git-bisect would really help here. > > -- > MiKRO / Mystic Bytes > http://mikro.atari.org > >