TCP/IP Stage 2 bounty

Am starting a new thread for this because the other TCP/IP bounty beta thread is largely about the AcornSSL module.

Stage 2 is updating the stack for modern BSD TCP/IP (v4 and maybe v6) with an eye to wifi etc.

The bounty is doing pretty well financially, but if it met its targets (let’s say, hypothetically, tomorrow), is anyway available/willing to do the work?

There’s a fair bit to do for it, but I have considered doing this one. I’ve been ‘warming up’ with other RISC OS tasks first to get back into things properly as I’ve been away from the fold for a little while. Assuming that the other developers haven’t lost the will to live looking at my current submissions, anyway!

Did anybody take this up? I’ve got a couple of months I need to fill with work before The Next Thing, and was thinking of tackling this bounty.

The Bounties page is still listing it as “Open” rather than “Underway”, so it looks like it’s still available.

If you have the time, then I’d say go for it. Last I heard it was still not taken, and it’s a pretty important bit of work to get sorted.

If anyone is seriously thinking about this, I’d ask them to get in touch with me at RISC OS Dev address (andrew riscosdev com) as we have a large amount of money set aside for this project, as well as various timescale and customer elements that mean we want to support this work extensively. There are a few people hovering around showing interest, but no real progress thus far, so we’d like some serious proposals and to co-ordinate who does what.

The official process to claim the bounty is to contact RISC OS Open directly, although they don’t seem to have a dedicated email address to register interest in bounties. Perhaps code@riscosopen.org might be the most appropriate.

I think what Andrew is proposing is that it is a pot of money that both ROOL and RISCOS Developments have and it makes sense to ensure it is maximised and achieves the objectives both parties want rather than working in isolation that has stimed a number of developments in the past.

With ROOL and ROD working in the same direction then we will all benefit.

I think Andrew was wearing his RComp when he posted. His pot of money is for a different deliverable, with focus on providing wi-fi for RComp’s ARMBook laptop product, with other hardware products at a later date, by perhaps other developers.

ROOL, meanwhile has a purely agnostic approach to delivering wi-fi across hardware platforms.

I’m not saying Andrew cannot highlight his bounty to prospective bounty claimants, but they are not a like-for-like the same.

Alan,

Steps 2 & 3 of the ROOL bounty are required steps to get a universal Wi-Fi stack and the only non hardware agnostic part about them is the driver for the chip and my understanding from talking to Andrew, irrespective of it being his RComp or ROD cap, and ROOL is that they both want to work together as the majority of the work is getting to the end of the third bounty.

It is then a step to get each Wi-fi chip enabled, which I grant you still requires an amount of work but we all gain a modern stack.

Just like the SSL work which is hardware agnostic other, than speed constraints, updates should be easier.

No one wants the dead end of the last RISCOS wars so let’s not stoke the flames where there are none to my knowledge.

Wow, Alan, you’re way off base, I’m afraid. Firstly, I was wearing my RISC OS Dev hat. We have a customer need for various aspects of TCP/IP. Customer is not R-Comp. Customer will be shipping tens or hundresds of thousand RISC OS systems. Customer has already made the money available to us, provided timescales are met.

Secondly, your post kinda paints ROOL as me as different camps and has a sense of “good guy/bad guy” mentality. For Wifi, MY stated plan was always to have wifi that would support all camps (ARMbook, Pi3, wandboard etc). If we’re going to split hairs, all the docs I’ve seen from ROOL were Pi-oriented. My goal would be to work together, so that there is good support for wifi all round. I see zero benefit in hardware-specific solutions, because it doesn’t help RISC OS one jot.

Conversely, a cynic might comment that the new Wifi Hat from Elesar actually discourages ROOL’s Pi-based wifi given the people within ROOL who might have tackled that network bounty. Whilst I applaud Elesar’s creativity and elegant solution, and from a business perspective, I am sure it was a smart move, I wish Rob’s skill/time had been focussed on delivering that agnostic wifi you mention. Instead, we have yet another “not real wifi” solution for Pi users that de-focuses from the real need. If RISC OS is to succeed, it needs wifi because the reality is that modern devices expect wifi networking. To not have that as standard is a major stumbling block for RISC OS from both a commerical and an “evangelism” perspective.

So, to be crystal clear. ROD has a pot of money available, and ROD was the one who originally asked ROOL to spec up the bounty. ROD requires a more robust, secure and intelligent TCP/IP stack, leading to IPv6 and Wifi. As a full-time company, with commercial realities, we are, however, unwilling to simply hand over a five-figure sum to sit in the ROOL bank account whilst someone thinks about doing the work. We have time tables that need to be met, and would rather incentivize a developer with regular payment and bonus for timely completion. Additionally, we would need more communication than is usual for the bounty system, because commercial projects depend on the work.

Finally, there are a number of people interested in the work, but not necessarily committing. We do not want to see several people attempting the work in parallel, or the bounty being “claimed” and that discouraging someone more able to work on the project. With our private funding, a team-based approach is much more practical.

Finally, with an R-Comp hat on, yes, I want to see wifi for ARMbook. BUT, I want to see it in a way that is viable for Pi and ARMX6 too (the other platforms with wifi chips).

Do bear in mind that ROD are funding work to promote RISC OS on Pi with the goal of using free Pi distributions to spread RISC OS out around the world. This is a combined media push with videos, software, physical media, handouts etc. All for free. It is therefore in our interest to see wifi on Pi as well, because without it, it is one step harder to “evangelise” with.

So, to summarise. ROD has customer and money for IPv6 (and possibly wifi). Customer is using i.MX6 hardware. ROD wants to support Pi for outreach capabilities. R-Comp and ROD want to see wifi on ARMbook/Pinebook as part of on-going relationship with Far East. The common denominator? ROD want to see network progress on RISC OS for all devices! :)

If we’re going to split hairs, all the docs I’ve seen from ROOL were Pi-oriented.

I suspect that may be because later incarnations of the Pi have WiFi (and Bluetooth?) onboard as a standard thing.

However, the way I see it, there are two entirely different angles here – one which does not discount specific solutions like the WiFi hat.

Angle one – obviously – is the hardware aspect of managing to actually talk to the WiFi device. This will have to be device specific, and in the case of the Pi that may imply machine specific.

Angle two, on the other hand, is the need for an improved TCP/IP stack that can handle the challenges that WiFi brings, like the signal vanishing, coming back, and you having a different IP address when it returns. Or co-use of WiFi and/or wired LAN, different addresses for each, an an intelligent way to deal with which to prefer if both are connected and active. Ditto if WiFi can see numerous APs on two different frequencies. And, of course, the use of public APs that has a “accept our terms and conditions” sign in before it’ll work. And not to mention the little issue of IPv6. These changes to the network stack are RISC OS specific, not aimed at any particular machine, and encompass behaviour sometimes unique to WiFi but agnostic to the actual WiFi chip that happens to be installed. These enhancements would benefit everybody, as you intend them to, and hopefully lead to more WiFi solutions appearing.

Why I write that last sentence like that? Well, there currently are no shortage of USB WiFi dongles. Exactly how many are supported under RISC OS? Exactly how many is the current ancient network stack capable of usefully supporting? I don’t think it’s reasonable to consider (or demean) device-specific solutions until the groundwork has been laid to make them actually work.

If RISC OS is to succeed, it needs wifi because the reality is that modern devices expect wifi networking.

Which is, I suspect, why Rob created the WiFi hat. It may be a partial implementation (Pi only), however it works even within the existing limitations of the OS and it works today.

The new network stack will be a breathe of fresh air, and much needed. However it is worth pointing out that people have been complaining about the lack of “modern” networking for RISC OS for over a decade. It’s great that things look to be finally moving, but today we have Elesar’s hat, not a new stack.
Tomorrow, hopefully we’ll have both. :-)

With our private funding, a team-based approach is much more practical.

For a major OS change, a one-man-does-it-all approach probably doesn’t make any sense anyway. RISC OS itself (well, Arthur, as it was) was written by a number of people who each tackled different parts to make a working whole. It would make sense to have a similar approach to a network stack, as it’s hardly a little weekend project.

BUT, I want to see it in a way that is viable for Pi and ARMX6 too (the other platforms with wifi chips).

Again we come back to the two angles I mentioned above. The underlying network stack is not the WiFi hardware support. One would hope that low level talking to WiFi hardware is “broadly similar” in how they operate and behave. Even if the registers and behaviour differ, it would just need an appropriate backend, like the six built into EtherUSB.

So, don’t think of it as individual hardware solutions. That is conflating two separate issues. Any that people create now will suffer the disadvantages of how things are today. No matter how good Rob’s attempts, it simply isn’t going to be capable of IPv6. Not until the underlying system itself is capable of such things. Then? Then Rob’s WiFi hat will just need a backend like the other devices.

I see zero benefit in hardware-specific solutions, because it doesn’t help RISC OS one jot.

Users want WiFi. Because unlike olden times, WiFi is now commonplace and just ‘expected’. It probably says a lot that you can buy dev boards with WiFi but no USB (the USB on the ESP32 is a serial interface chip, primarily used for programming the thing).

Some people (like me) buy a Vonets, plug in cables.

Smarter people design devices that can plug in to make it “just work” under RISC OS.

Neither solution is wrong or bad, and indirectly it helps RISC OS because it is fulfilling a user need in the absence of anything else, keeping that user in the realm of RISC OS rather than wandering off to Linux or somesuch. Make no mistake, WiFi is essential on my Pi. Some of my programs expect networking, and I get it via WiFi. If this was not available under RISC OS, well, I wonder how long I would have stayed around with a machine that had no connectivity to the world (no, I don’t do wired LAN).
There’s a need. These solutions are filling that need. Arguing about their merits in the bigger picture doesn’t make those needs go away. We can hope for better in the future, but today’s needs are still today’s needs.

OK Rick, you’re right, I did “over-egg” it a bit, but with now four “add-on” wifi solutions (PiFi, Wispy, Vonets/TPlink bridges, Wifi Hat) surely it is time to focus on doing it properly? We can’t really expect new folks to buy add-ons when they are trying out RISC OS. But you are right – we need the stop-gap solutions until the work happens. I’d just like that to be soon :)

Secondly, your post kinda paints ROOL as me as different camps and has a sense of “good guy/bad guy” mentality.

With respect, your history of posting on this forum has sowed that seed to some extent. You’ve certainly posted publicly critical things from an R-Comp position (“we disagree on what is being done; can a bounty claimant please contact me direct¹”, and that kind of thing, from an ARMX6 perspective IIRC)², which IMO would have been far better off done away from the forum. You can’t be surprised now if people’s memories trigger when stuff like this comes up.

FWIW, I’d echo Alan’s point. If there are constraints on the bounty from ROD’s point of view, then presumably if ROOL are on board they will be aware of these and will be communicating them to anyone who follows Alan’s advice and contacts ROOL about the bounty. Thus the correct approach is for those interested to contact ROOL, and ROOL will ensure that they are fully aware of the constraints and requirements of the ROD funding.

The only reason that people would conceivably need to contact ROD over ROOL is if ROD and ROOL don’t agree on the way forward. In which case, ROD shouldn’t be throwing cash at people to subvert ROOL’s decisions on how to proceed. Unless, of course, ROD plan to fork the OS and have ROD and ROOL versions – in which case, people would be very correct to question your motives.

¹ Edited to fix memory, in the light of ².

² For what it’s worth, here’s the one that really stuck in my mind. The right thing to have done would have been to have dropped an email to ROOL, outlining the concerns. The wrong thing was to publicly announce a wish to bypass ROOL and contact the bounty claimant directly – why would this be necessary, unless trying to subvert ROOL’s decision?

[Edited]

Whilst I applaud Elesar’s creativity and elegant solution, and from a business perspective, I am sure it was a smart move, I wish Rob’s skill/time had been focussed on delivering that agnostic wifi you mention.

Unless I’ve mis-read, one of the fall-outs from Elesar’s work has been a front-end that could be used on the future WiFi implementation – so not all wasted time.

It’s not that edifying seeing RISC OS companies attacking each other in these forums. If you have a problem with what Elesar are doing, talk to them and suggest your alternative view. If both sides agree, things might get done differently.

On the other hand, Elesar’s fix gets a solution now. We’re still talking about native WiFi many years on.

By which token, Steve, I’ll write to you privately and explain in more detail.

Background… ROD bought and own RISC OS, but have given it away free under the Apache licence. When we met with ROOL about this, ROOL asked us to take the lead on the future of the OS in the Open Source world. When commercial contracts involve ROD (or other RISC OS companies like R-Comp or Elesar or CJE or….) those companies cannot be two-steps removed from the work that affects them. Communication is absolutely the key, but it has to be two-way. ROD is trying to push forwards with the key work that needs to happen, as quickly as possible.

The forum provides a way for initial contact to be made, which may not be possible otherwise. Hence why I sometimes post asking to make contact.
Most notably, many of us in ROD like phonecalls rather than other forms of communication because we find it helpful in terms of avoiding misunderstandings (like this thread). Text is horrible for misunderstandings. However, without initial contact, phonecalls are impossible.

I’d just like that to be soon :)

We all would agree on that.

Text is horrible for misunderstandings.

Meanwhile phonecalls are horrible for traceability, the who-said-what-when. I have an app now that habitually records all of my phone conversations (on my mobile; with the landline, I put it to speakerphone mode and record it the traditional way) in case I should ever need to go back and say “but you said…” or, should it happen, to deflect the “you didn’t understand, you don’t speak French” or the like.

Text might be horrible for misunderstandings, but it is essential for following on what should/shouldn’t be done, when, and how. Phone calls should be followed by a summary email recapping the points of the call.

Note: I may be biased, I detest speaking to people on the phone because there is a voice and no associated expression/mannerisms to read, and one is expected to come up with immediate replies sometimes without time to consider what is actually being asked; I have sometimes agreed to something I didn’t want to do just to get the caller to naff off (I’m too polite to just hang up, even if I’ve considered it). As such, I regard a telephone as there for my benefit (as the bill payer), not for the benefit of others. Unless I’m expecting a call, expect it to go to answering service. If your number is withheld (even if I’m expecting the call) expect it to go to answering service (my mobile actually does that automatically ☺). And if it goes to answering service and no message is left, don’t expect me to do anything other than delete the missed call notification. No, I will not look up numbers. If there’s no message, it clearly isn’t important enough to concern me…

I just noticed this in a previous message:

We can’t really expect new folks to buy add-ons when they are trying out RISC OS.

But…

They’re expected to be willing to buy:

• A half-decent browser
• Useful email software
• A tool to fix the filesystem when it screws up
• A tool to create the dual-format filesystem if they want something better than 2GB
• The development suite if they’re interested in fiddling with the OS
• And so on.

Yes, the stated functionality of the WiFi adaptor is generally provided “out of the box” on other platforms. OSMC on my Pi Zero “just worked” with a USB dongle.
But, then, all of the above is an expectation on these same other platforms as well. Firefox? fsck/chkdsk? Partition/formatting tools? The entire dev suite? All just basic expectations these days.

Don’t cherry pick.

Rick, funny you should mention that ROD’s actively working to resolve all those issues.

1) The new browsers should be available free in the next few months. We’re doing a staggered roll out because we don’t want to handle the support burden of alpha/beta software at this stage. We have always clearly stated that they will be available for free, but paid for by ROD and its investors.

2) Touche – but I have made suitable versions of Messenger available on NutPi for this reason. Also, the browser should allow for webmail usage which (for most users) largely negates the need for dedicated email software. The Pi disc image will also include email tools.

3) DiscKnight is now on !Store for easier availability, and I have made overtures to Druck about ROD buying it to give away free. It’s something that’s on-going.

4 and 5) are ROOL related (or ROOL people).

Regarding dev tools, ROD is in the process of trying to make more tools available free of charge, open source (watch this space – it is agreed, but we’re awaiting source). The Iris browser project (Lee Noar) has resulted in GCC 8 being available for RISC OS use, and I believe Chris G is already making use of that elsewhere on the forums (RPCemu thread).

We’re also putting together (well, I already have) an open-source dev-kit for Pi users, so that they can easily get started programming on RISC OS without paying for anything. However, RISC OS itself is still largely wedded to the ex-Acorn tools.

Hopefully you catch my drift. ROD are committed to this, and are trying to resolve the things you mention.

Final post (I have to go out now). If anyone wishes to talk properly with myself (01925 755043) or Richard (01702 462385) please call us. We would be more than happy to explain ROD’s plans, its needs, and those of its customers, to anyone with interest. If you’re overseas, we do Skype. I won’t put my skype details on the forum, but email and ask, and off we go.

This isn’t an idle offer. We’d like to hear from people. Although I reserve the right to be out :)

…and ROD was the one who originally asked ROOL to spec up the bounty.

I take exception to anyone claiming credit where undue, so can fact check that a bit. The origin of the dull network stack analysis document was an email from Ben on 16-Jul-2016, in my reply on 17th I said

‘a proper analysis is certainly needed sometime: I trawled the roadmap and forums a couple of weeks back to come up with some new bounty candidates and TCP/IP stack is certainly in the mix.’

Being summer there was a delay because the sun’s out, but Word’s document properties box says I started that on 10-Aug-2016 which is 7 months before ROD was founded. The publishing of the bounties came much later of course, either delayed by ROOL’s dislike of having too many collecting at once, or spurred on by ROD’s interest in pledging towards them.

Anyone thinking about step 2 will see mentions like ‘we can supply a list of these’ in the description which in practice means you’d likely get a copy of the document and see the full horrors/implications of the current network stack; that’s a normal part of planning any large project – you assess the risks and decide how to limit them rather than barging in with a chainsaw.

This thread’s got a bit hot to handle…jelly & ice cream for everyone.

OK Rob, my apologies. I wasn’t at the meeting, but I thought Richard had asked you (or maybe ROOL, I wasn’t there) to spec it up at the Cambridge pub meeting you guys had. He mentioned that you’d (but it may have been Ben) rough things out on paper together, and I thought that was the origin. Didn’t know there was preceding work – I stand corrected, and point well made.

and see the full horrors/implications of the current network stack

Or just ask Steve… :-)

Hello I see “…GCC 8 being available for RISC OS…” when and where will it be available. I’m working on bluetooth for RISCOS currently and have it compiled with the current version of gcc for RISCOS is bit a pain in the ass to say it mildly.

Timo – please drop me a line at the riscosdev.com email address, and I’ll put you in touch with the GCC folks. At the moment, I think it is primarily cross-compiler based, but it has facilitated projects like Iris.