[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Serious issue with networking



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