public inbox for linux-8086@vger.kernel.org
 help / color / mirror / Atom feed
* Question on ELKS networking maturity
@ 2017-02-20 11:49 Marc-François LUCCA-DANIAU
  2017-02-20 12:57 ` Jody Bruchon
  2017-02-20 15:16 ` Alan Cox
  0 siblings, 2 replies; 4+ messages in thread
From: Marc-François LUCCA-DANIAU @ 2017-02-20 11:49 UTC (permalink / raw)
  To: ELKS

Hello all,

While implementing the Ethernet capability in ELKS in collaboration
with Georg, I am getting uncomfortable as we find more and more bugs
in the existing networking stack.

The latest finding is an incorrect management of the sequence numbers
in the TCP layer when accepting incoming connections.

I made the assumption at the beginning that ELKS was reasonably mature
on networking, but obviously I was wrong, and have to revise my
development plan.

So my question to the experienced ones that know the history: what was
the status of the networking features around 2015 ? Were the cmdlets
like httpd, tinyirc, telnet, etc, working with SLIP ? Or was it an
inactive (and so not exercised) part of the project ?

Thanks in advance to provide some background information here,

MFLD

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question on ELKS networking maturity
  2017-02-20 11:49 Question on ELKS networking maturity Marc-François LUCCA-DANIAU
@ 2017-02-20 12:57 ` Jody Bruchon
  2017-02-20 13:41   ` Georg Potthast 2
  2017-02-20 15:16 ` Alan Cox
  1 sibling, 1 reply; 4+ messages in thread
From: Jody Bruchon @ 2017-02-20 12:57 UTC (permalink / raw)
  To: ELKS

On 2017-02-20 6:49 AM, Marc-François LUCCA-DANIAU wrote:
> I made the assumption at the beginning that ELKS was reasonably mature
> on networking, but obviously I was wrong, and have to revise my
> development plan.
ELKS networking was never remotely mature. It was written to use SLIP 
and as far as I can tell it was only ever minimally functional. Given 
the show-stopping bugs fixed in the past three years, it makes sense 
that networking would be put to the side. When something as simple as 
logging in after logging out freezes the entire system, that's a much 
bigger priority than networking support. There has also been a general 
lack of working network hardware available for would-be network devs to 
test on. I once got a NE2K-compliant 8-bit ISA card but then the 8086 PC 
it was going to go into blew up.

At one time I'm sure the network programs were working, but it would be 
safe to assume they are working at "proof-of-concept" quality only.

Assume everything on the network side was test code cobbled together and 
abandoned; that's basically how it has worked out.

-Jody

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question on ELKS networking maturity
  2017-02-20 12:57 ` Jody Bruchon
@ 2017-02-20 13:41   ` Georg Potthast 2
  0 siblings, 0 replies; 4+ messages in thread
From: Georg Potthast 2 @ 2017-02-20 13:41 UTC (permalink / raw)
  To: ELKS, Jody Bruchon

I have already done some work on getting ktcp to work with Marc-François' NE2K driver and am pretty sure to get it functional, however, it requires some time. Uncovering bugs I consider not unusual in this process.

Since I am interested to continue with this I suggest not to put this to the side. It would be a big step forward for ELKS to get ethernet working. You could add drivers for different network cards in the future.

Georg

> Jody Bruchon <jody@jodybruchon.com> hat am 20. Februar 2017 um 13:57 geschrieben:
> 
> 
> On 2017-02-20 6:49 AM, Marc-François LUCCA-DANIAU wrote:
> > I made the assumption at the beginning that ELKS was reasonably mature
> > on networking, but obviously I was wrong, and have to revise my
> > development plan.
> ELKS networking was never remotely mature. It was written to use SLIP 
> and as far as I can tell it was only ever minimally functional. Given 
> the show-stopping bugs fixed in the past three years, it makes sense 
> that networking would be put to the side. When something as simple as 
> logging in after logging out freezes the entire system, that's a much 
> bigger priority than networking support. There has also been a general 
> lack of working network hardware available for would-be network devs to 
> test on. I once got a NE2K-compliant 8-bit ISA card but then the 8086 PC 
> it was going to go into blew up.
> 
> At one time I'm sure the network programs were working, but it would be 
> safe to assume they are working at "proof-of-concept" quality only.
> 
> Assume everything on the network side was test code cobbled together and 
> abandoned; that's basically how it has worked out.
> 
> -Jody
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question on ELKS networking maturity
  2017-02-20 11:49 Question on ELKS networking maturity Marc-François LUCCA-DANIAU
  2017-02-20 12:57 ` Jody Bruchon
@ 2017-02-20 15:16 ` Alan Cox
  1 sibling, 0 replies; 4+ messages in thread
From: Alan Cox @ 2017-02-20 15:16 UTC (permalink / raw)
  To: Marc-François LUCCA-DANIAU; +Cc: ELKS

It got to the

"gee it now and then makes a working connection"

state.

It would be far more effective to replace it with uIP or LWIP I think
than try and debug it. That's not to say you shouldn't try and make it
work if you ae going to enjoy the challenge.

Alan

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-02-20 15:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-20 11:49 Question on ELKS networking maturity Marc-François LUCCA-DANIAU
2017-02-20 12:57 ` Jody Bruchon
2017-02-20 13:41   ` Georg Potthast 2
2017-02-20 15:16 ` Alan Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox