[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Serious issue with networking
Miro,
I also have problems with the enec6 driver, and switched to Odd's
version.
It'd be nice for Odd to allow us to include the source in FreeMiNT :-)
Alan.
On Wed, 2010-08-18 at 00:26 +0200, Miro Kropacek wrote:
> 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
> >>
> >>
> >
>
>
>