[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Serious issue with networking
Keith,
this story has quite funny ending -- thanks to your note about
AssemSoft's driver I couldn't resist and I tried that one -- not only
it works unbelievable better (I've got drops between 20 - 120 KB/s,
now steady 120 !!!) but it also works on 1.17. And what's really
irony, when I was trying long enough, old driver (from ct60 package)
stopped to work even on 1.16 :D So I'm quite glad you pointed me to
Odd's one.
All at all, probably a false alarm and shitty original EtherNEC
driver. Gosh, I really need to reinstall my EtherNAT, never got
similar problems.
On Wed, Aug 18, 2010 at 12:08 AM, Keith Scroggins <kws@radix.net> wrote:
> 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
>>
>>
>
--
MiKRO / Mystic Bytes
http://mikro.atari.org