* Re: NFSv4 boot support?
2024-02-17 8:51 ` Ahmad Fatoum
@ 2024-02-19 2:17 ` Dan Shelton
2024-02-20 14:17 ` Ahmad Fatoum
2024-02-19 21:43 ` Antony Pavlov
2024-02-28 7:26 ` Antony Pavlov
2 siblings, 1 reply; 18+ messages in thread
From: Dan Shelton @ 2024-02-19 2:17 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox
On Sat, 17 Feb 2024 at 09:51, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hello Antony,
>
> On 05.02.24 10:59, Antony Pavlov wrote:
> > On Wed, 31 Jan 2024 22:37:50 +0100
> > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> > Hi All!
> >
> >> Hello Dan,
> >>
> >> On 31.01.24 22:03, Dan Shelton wrote:
> >>> Hello!
> >>>
> >>> Does barebox support booting from a NFSv4 filesystem, e.g. boot from
> >>> NFSv4 filesystem into a Linux NFSv4 netroot (diskless machine)?
> >>
> >> The barebox network stack only does UDP/IP. There have been attempts to
> >> bring a TCP stack into barebox, but none have so far succeeded to
> >> make it mainline. This is a hard requirement before we can consider
> >> supporting NFSv4. I hope that lwIP could fill this gap in the future,
> >> but no one is actively continuing this work as far as I am aware[1].
> >
> > I have started integration on picotcp into barebox in 2015, see
> > https://lore.barebox.org/barebox/1436991230-14251-10-git-send-email-antonynpavlov@gmail.com/T/
> >
> > At the moment I have WIP barebox-v2023.11 with integrated picotcp 2.1:
> >
> > https://github.com/frantony/barebox/tree/20231127.picotcp
>
> Cool. Looking at Oleksij's repo, it was based on your work. How well does
> picotcp work for you? What open issues remain with the patch stack? Is the
> barebox integration actively used in projects?
>
> Is https://github.com/tass-belgium/picotcp the official repository? This hasn't
> seen development activity in 5 years. lwIP on the other hand still sees active
> development.
>
> Regarding the license, inclusion of BSD-licensed code is ok. You can check out
> the LICENSES/ subdirectory for the licenses covering barebox.
If TCP support lands in barebox, how fast can NFSv4 support be implemented?
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-02-19 2:17 ` Dan Shelton
@ 2024-02-20 14:17 ` Ahmad Fatoum
2024-02-20 15:28 ` Uwe Kleine-König
0 siblings, 1 reply; 18+ messages in thread
From: Ahmad Fatoum @ 2024-02-20 14:17 UTC (permalink / raw)
To: Dan Shelton, Uwe Kleine-König; +Cc: barebox
Hello Dan,
On 19.02.24 03:17, Dan Shelton wrote:
> On Sat, 17 Feb 2024 at 09:51, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>
>> Hello Antony,
>>
>> On 05.02.24 10:59, Antony Pavlov wrote:
>>> On Wed, 31 Jan 2024 22:37:50 +0100
>>> Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>>
>>> Hi All!
>>>
>>>> Hello Dan,
>>>>
>>>> On 31.01.24 22:03, Dan Shelton wrote:
>>>>> Hello!
>>>>>
>>>>> Does barebox support booting from a NFSv4 filesystem, e.g. boot from
>>>>> NFSv4 filesystem into a Linux NFSv4 netroot (diskless machine)?
>>>>
>>>> The barebox network stack only does UDP/IP. There have been attempts to
>>>> bring a TCP stack into barebox, but none have so far succeeded to
>>>> make it mainline. This is a hard requirement before we can consider
>>>> supporting NFSv4. I hope that lwIP could fill this gap in the future,
>>>> but no one is actively continuing this work as far as I am aware[1].
>>>
>>> I have started integration on picotcp into barebox in 2015, see
>>> https://lore.barebox.org/barebox/1436991230-14251-10-git-send-email-antonynpavlov@gmail.com/T/
>>>
>>> At the moment I have WIP barebox-v2023.11 with integrated picotcp 2.1:
>>>
>>> https://github.com/frantony/barebox/tree/20231127.picotcp
>>
>> Cool. Looking at Oleksij's repo, it was based on your work. How well does
>> picotcp work for you? What open issues remain with the patch stack? Is the
>> barebox integration actively used in projects?
>>
>> Is https://github.com/tass-belgium/picotcp the official repository? This hasn't
>> seen development activity in 5 years. lwIP on the other hand still sees active
>> development.
>>
>> Regarding the license, inclusion of BSD-licensed code is ok. You can check out
>> the LICENSES/ subdirectory for the licenses covering barebox.
>
> If TCP support lands in barebox, how fast can NFSv4 support be implemented?
Depends on who's volunteering to do it. :-)
If your question instead is how much effort a NFSv4 port would be, Uwe did the
NFSv3 port and may have an guesstimate for this?
Cheers,
Ahmad
>
> Dan
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-02-20 14:17 ` Ahmad Fatoum
@ 2024-02-20 15:28 ` Uwe Kleine-König
0 siblings, 0 replies; 18+ messages in thread
From: Uwe Kleine-König @ 2024-02-20 15:28 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: Dan Shelton, barebox
[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]
On Tue, Feb 20, 2024 at 03:17:02PM +0100, Ahmad Fatoum wrote:
> Hello Dan,
>
> On 19.02.24 03:17, Dan Shelton wrote:
> > On Sat, 17 Feb 2024 at 09:51, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>
> >> Hello Antony,
> >>
> >> On 05.02.24 10:59, Antony Pavlov wrote:
> >>> On Wed, 31 Jan 2024 22:37:50 +0100
> >>> Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>>
> >>> Hi All!
> >>>
> >>>> Hello Dan,
> >>>>
> >>>> On 31.01.24 22:03, Dan Shelton wrote:
> >>>>> Hello!
> >>>>>
> >>>>> Does barebox support booting from a NFSv4 filesystem, e.g. boot from
> >>>>> NFSv4 filesystem into a Linux NFSv4 netroot (diskless machine)?
> >>>>
> >>>> The barebox network stack only does UDP/IP. There have been attempts to
> >>>> bring a TCP stack into barebox, but none have so far succeeded to
> >>>> make it mainline. This is a hard requirement before we can consider
> >>>> supporting NFSv4. I hope that lwIP could fill this gap in the future,
> >>>> but no one is actively continuing this work as far as I am aware[1].
> >>>
> >>> I have started integration on picotcp into barebox in 2015, see
> >>> https://lore.barebox.org/barebox/1436991230-14251-10-git-send-email-antonynpavlov@gmail.com/T/
> >>>
> >>> At the moment I have WIP barebox-v2023.11 with integrated picotcp 2.1:
> >>>
> >>> https://github.com/frantony/barebox/tree/20231127.picotcp
> >>
> >> Cool. Looking at Oleksij's repo, it was based on your work. How well does
> >> picotcp work for you? What open issues remain with the patch stack? Is the
> >> barebox integration actively used in projects?
> >>
> >> Is https://github.com/tass-belgium/picotcp the official repository? This hasn't
> >> seen development activity in 5 years. lwIP on the other hand still sees active
> >> development.
> >>
> >> Regarding the license, inclusion of BSD-licensed code is ok. You can check out
> >> the LICENSES/ subdirectory for the licenses covering barebox.
> >
> > If TCP support lands in barebox, how fast can NFSv4 support be implemented?
>
> Depends on who's volunteering to do it. :-)
> If your question instead is how much effort a NFSv4 port would be, Uwe did the
> NFSv3 port and may have an guesstimate for this?
Without having taken a deeper look: I think the step from NFSv2 to NFSv3
was much easier than NFSv3 -> NFSv4 will be. For NFSv3 support I needed
4 full work days.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-02-17 8:51 ` Ahmad Fatoum
2024-02-19 2:17 ` Dan Shelton
@ 2024-02-19 21:43 ` Antony Pavlov
2024-02-20 13:53 ` Alessandro Rubini
2024-02-28 7:26 ` Antony Pavlov
2 siblings, 1 reply; 18+ messages in thread
From: Antony Pavlov @ 2024-02-19 21:43 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: Dan Shelton, barebox
On Sat, 17 Feb 2024 09:51:02 +0100
Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
Hi Ahmad!
> Hello Antony,
>
> On 05.02.24 10:59, Antony Pavlov wrote:
> > On Wed, 31 Jan 2024 22:37:50 +0100
> > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> > Hi All!
> >
> >> Hello Dan,
> >>
> >> On 31.01.24 22:03, Dan Shelton wrote:
> >>> Hello!
> >>>
> >>> Does barebox support booting from a NFSv4 filesystem, e.g. boot from
> >>> NFSv4 filesystem into a Linux NFSv4 netroot (diskless machine)?
> >>
> >> The barebox network stack only does UDP/IP. There have been attempts to
> >> bring a TCP stack into barebox, but none have so far succeeded to
> >> make it mainline. This is a hard requirement before we can consider
> >> supporting NFSv4. I hope that lwIP could fill this gap in the future,
> >> but no one is actively continuing this work as far as I am aware[1].
> >
> > I have started integration on picotcp into barebox in 2015, see
> > https://lore.barebox.org/barebox/1436991230-14251-10-git-send-email-antonynpavlov@gmail.com/T/
> >
> > At the moment I have WIP barebox-v2023.11 with integrated picotcp 2.1:
> >
> > https://github.com/frantony/barebox/tree/20231127.picotcp
>
> Cool. Looking at Oleksij's repo, it was based on your work. How well does
> picotcp work for you? What open issues remain with the patch stack? Is the
> barebox integration actively used in projects?
I don't use picotcp in any of my projects.
It is very experimental feature. At the moment my picotcp branch can't correctly
handle arp processing. Alas at the moment I have no much time to make picotcp work.
Instead of integration of picotcp into existing barebox code I think barebox needs
some work to make adding new "external" network interface more simple,
so a "new" network stack picotcp/lwIP/uIP/Cyclone/iPXE can be added easely.
> Is https://github.com/tass-belgium/picotcp the official repository? This hasn't
> seen development activity in 5 years.
Please see https://github.com/virtualsquare/picotcp
> lwIP on the other hand still sees active development.
I agree with you. It looks like lwIP is more popular than picotcp.
> Regarding the license, inclusion of BSD-licensed code is ok. You can check out
> the LICENSES/ subdirectory for the licenses covering barebox.
Thanks for the tip, now I see that we can use BSD-licensed code.
>
> Cheers,
> Ahmad
>
>
>
>
> >>> We need NFSv4, because it does not need rpcbind, and combines
> >>> filesystem, lockd and other stuff all in one TCP port (2049). Site
> >>> policy also does not allow NFSv2/NFSv3, but allows NFSv4.
> >>
> >> Please note that this only concerns barebox and that kernel nfsroot is
> >> unaffected. You can load kernel and device tree over TFTP and supply a
> >> suitable command line argument to the kernel to use a NFS root.
> >>
> >> The standard net boot target does just that:
> >> https://elixir.bootlin.com/barebox/v2024.01.0/source/defaultenv/defaultenv-2-base/boot/net
> >>
> >> It specifies TCP, but hardcodes v3 currently. I guess we could drop the v3 and let
> >> the kernel decide on its own what version it will use? If that doesn't work, you can
> >> override the file locally in your environment, e.g. via CONFIG_DEFAULT_ENVIRONMENT
> >> pointing at a directory that contains a boot/net file with the appropriate
> >> changes (or just call your boot target something else like boot/nfsv4).
> >>
> >> Hope this helps.
> >>
> >> [1]: Some attempts I am aware of:
> >> https://github.com/a3f/barebox/tree/lwip
> >> https://github.com/olerem/barebox/tree/picotcp-2019.06.29
> >> https://github.com/jmaselbas/barebox/commit/4a987bfdc2ad50c13126dd6290d2477c3fc0c87d
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>> Dan
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >>
> >>
> >
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Best regards,
Antony Pavlov
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-02-19 21:43 ` Antony Pavlov
@ 2024-02-20 13:53 ` Alessandro Rubini
2024-02-26 12:17 ` Ahmad Fatoum
2024-03-08 10:23 ` Sascha Hauer
0 siblings, 2 replies; 18+ messages in thread
From: Alessandro Rubini @ 2024-02-20 13:53 UTC (permalink / raw)
To: barebox
>> This hasn't
>> seen development activity in 5 years.
>
> Please see https://github.com/virtualsquare/picotcp
But the TCP/IPV4 standard didn't change, either.
>> lwIP on the other hand still sees active development.
>
> I agree with you. It looks like lwIP is more popular than picotcp.
Sure. It's older and it has a loyal (or addicted) user base and
commercial support. Or it just needs more commits because it'w worse and
full of bugs.
As far as I know, lwIP is horrible code, difficult to integrate and
maintain, while picotcp is designed in the right way (although I admit
I only looked at the former, about picotcp I only talked with the main
author without looking at the code).
I'd love to add mqtt to my microcontroller projects, where I have udp
but no tcp yet, and I would never rely on lwIP. That's just a personal
opinion, but I'd better not rely on the date of last commit to pick
or not pick a library.
Regards
/alessandro
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-02-20 13:53 ` Alessandro Rubini
@ 2024-02-26 12:17 ` Ahmad Fatoum
2024-03-08 10:23 ` Sascha Hauer
1 sibling, 0 replies; 18+ messages in thread
From: Ahmad Fatoum @ 2024-02-26 12:17 UTC (permalink / raw)
To: Alessandro Rubini, barebox
Hello,
On 20.02.24 14:53, Alessandro Rubini wrote:
>>> This hasn't
>>> seen development activity in 5 years.
>>
>> Please see https://github.com/virtualsquare/picotcp
>
> But the TCP/IPV4 standard didn't change, either.
I don't mind lack of new features, but I'd prefer that when we
adopt an external network stack, we adopt one that still sees
maintenance and bug fixes. The repository linked by Antony while
having more recent commits, also has a link to security considerations:
https://github.com/virtualsquare/picotcp/blob/master/docs/security.md
which lists 4 year old security issues that are acknowledged, but
unresolved.
>>> lwIP on the other hand still sees active development.
>>
>> I agree with you. It looks like lwIP is more popular than picotcp.
>
> Sure. It's older and it has a loyal (or addicted) user base and
> commercial support. Or it just needs more commits because it'w worse and
> full of bugs.
Yes, it can go both ways. I am not arguing in favor of comparing
absolute commit count, but I think we might be better off using
a network stack that we don't have to completely maintain ourselves,
given that we already had a network stack that we maintained ourselves
that we are looking to substitute.
In the end, the one who does the work is probably who gets to choose
(and argue their choice).
> As far as I know, lwIP is horrible code, difficult to integrate and
> maintain
Thanks for your input. My only interaction with lwIP so far was some
weekend time spent on integrating it into the barebox build system,
but I haven't went further than that to actually wire it with the network API.
> while picotcp is designed in the right way (although I admit
> I only looked at the former, about picotcp I only talked with the main
> author without looking at the code).
I think best case, we would proceed as suggested by Antony: Rework
the interfaces in barebox, so both the existing network stack and lwIP
(or picotcp) can be integrated using the same APIs.
> I'd love to add mqtt to my microcontroller projects, where I have udp
> but no tcp yet, and I would never rely on lwIP. That's just a personal
> opinion, but I'd better not rely on the date of last commit to pick
> or not pick a library.
Did you try integrating picotcp instead? What issues did you run into?
Thanks,
Ahmad
>
> Regards
> /alessandro
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-02-20 13:53 ` Alessandro Rubini
2024-02-26 12:17 ` Ahmad Fatoum
@ 2024-03-08 10:23 ` Sascha Hauer
2024-03-09 10:01 ` Alessandro Rubini
1 sibling, 1 reply; 18+ messages in thread
From: Sascha Hauer @ 2024-03-08 10:23 UTC (permalink / raw)
To: Alessandro Rubini; +Cc: barebox
On Tue, Feb 20, 2024 at 02:53:47PM +0100, Alessandro Rubini wrote:
> >> This hasn't
> >> seen development activity in 5 years.
> >
> > Please see https://github.com/virtualsquare/picotcp
>
> But the TCP/IPV4 standard didn't change, either.
>
> >> lwIP on the other hand still sees active development.
> >
> > I agree with you. It looks like lwIP is more popular than picotcp.
>
> Sure. It's older and it has a loyal (or addicted) user base and
> commercial support. Or it just needs more commits because it'w worse and
> full of bugs.
>
> As far as I know, lwIP is horrible code, difficult to integrate and
> maintain, while picotcp is designed in the right way (although I admit
> I only looked at the former, about picotcp I only talked with the main
> author without looking at the code).
I have played around with lwIP and tried to integrate it into barebox.
Now that there are patches integrating lwIP into U-Boot that was quite
easy to do as the patches show the places we have to touch.
It was easy to get ping and dns working, at least when the host to be
pinged is in the local network. I wasn't able though to figure out how I
can get lwIP to route packets through a gateway other than setting my
(currently only) network interface as the default fallback interface
which is used whenever no route is found.
It turns out that in lwIP the ip, netmask and gateway are members of
struct netif. It has no idea of separating a link from a network
interface. Yes, we do the same in barebox as well, but I don't need
a dedicated network stack to have the same limitations we have in our
adhoc network stack.
In order to get an idea of how routing is supposed to work I had to look
around in the code. It's really a pain to see and I really don't want to
have to debug it. The combination of two spaces indentation and a huge
#ifdef density makes it really hard to read.
>From that experience I can understand your concerns about lwIP.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-03-08 10:23 ` Sascha Hauer
@ 2024-03-09 10:01 ` Alessandro Rubini
0 siblings, 0 replies; 18+ messages in thread
From: Alessandro Rubini @ 2024-03-09 10:01 UTC (permalink / raw)
To: s.hauer; +Cc: barebox
Sascha:
> In order to get an idea of how routing is supposed to work I had to look
> around in the code. It's really a pain to see and I really don't want to
> have to debug it. The combination of two spaces indentation and a huge
> #ifdef density makes it really hard to read.
Indentation is affordable. We understand different people make different
choices (but I always suggest to read Linus' coding style guide, where every
choice is explained).
ifdef is a plague. There's almost no reason to use it nowadays, but I
see it had it's role when memory and processing power was so limited.
> From that experience I can understand your concerns about lwIP.
:)
Thanks a lot for taking a serious look. I never used it myself, I only
looked at the code and heard from mates who had to make their hands
dirty.
I love what Antony did, but I admit I didn't test it. My own plague is
being late with deliverables and with life in general -- but I'm sure
I'm not alone.
thanks
/alessandro
--
+39-0382-529554 sempre, solo se ci sono
+39-349-2689041 sempre, solo se c'e` campo
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-02-17 8:51 ` Ahmad Fatoum
2024-02-19 2:17 ` Dan Shelton
2024-02-19 21:43 ` Antony Pavlov
@ 2024-02-28 7:26 ` Antony Pavlov
2024-02-28 9:20 ` Sascha Hauer
2 siblings, 1 reply; 18+ messages in thread
From: Antony Pavlov @ 2024-02-28 7:26 UTC (permalink / raw)
To: Ahmad Fatoum, Sascha Hauer; +Cc: barebox, Dan Shelton
On Sat, 17 Feb 2024 09:51:02 +0100
Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
Hi All!
> Hello Antony,
>
> On 05.02.24 10:59, Antony Pavlov wrote:
> > On Wed, 31 Jan 2024 22:37:50 +0100
> > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> > Hi All!
> >
> >> Hello Dan,
> >>
> >> On 31.01.24 22:03, Dan Shelton wrote:
> >>> Hello!
> >>>
> >>> Does barebox support booting from a NFSv4 filesystem, e.g. boot from
> >>> NFSv4 filesystem into a Linux NFSv4 netroot (diskless machine)?
> >>
> >> The barebox network stack only does UDP/IP. There have been attempts to
> >> bring a TCP stack into barebox, but none have so far succeeded to
> >> make it mainline. This is a hard requirement before we can consider
> >> supporting NFSv4. I hope that lwIP could fill this gap in the future,
> >> but no one is actively continuing this work as far as I am aware[1].
> >
> > I have started integration on picotcp into barebox in 2015, see
> > https://lore.barebox.org/barebox/1436991230-14251-10-git-send-email-antonynpavlov@gmail.com/T/
Actually I made the first attempt to integrate picotcp into barebox in 2014,
see http://lists.infradead.org/pipermail/barebox/2014-May/019243.html
10 years is too long for this task :)
In the message http://lists.infradead.org/pipermail/barebox/2015-July/024244.html
if I understand correctly Sascha asked me to keep network stuff
users (tftp, nfs, netconsole) as intact as possible.
At the moment I understand that this task is too hard.
The problem is: the network stuff users don't rely on "a network stack"
in the true sense. E.g. tftp_handler() takes an ETHERNET PACKET on
it's input, tftp_handler() skips Ethernet and IP stuff by itself
and modifies UDP fields directly!
This week I have connected picotcp code to the existing network code
in the way that makes it possible to keep dhcp_handler() and
ftp_handler() intact. The result is ugly: barebox netdevice driver
receives frame from network, pass it to picotcp, picotcp parses
network protocol headers and extracts udp payload, next
picotcp passes udp payload back to my picotcp-to-barebox adapter,
the adapter RECONSTRUCTS ETHERNET PACKET and give it to tftp/dhcp_handler()!
This horrible approach creates more problems than it solves!
I propose another experiment: disable old network
stuff and integrate picotcp with all network applications (dhcp, tftp,
dns etc) on top of picotcp. This approach was used in the
'barebox picotcp integration (2015.06.14)' see
http://lists.infradead.org/pipermail/barebox/2015-June/023749.html
This experiment is not for use in production, probably it will break
compatibility but it will allow us to assess the benefits and drawbacks
of using a picotcp stack.
At the moment I understand that in order to achieve success in barebox
network stack upgrade I need to put more effort into ensuring the
reproducibility of the picotcp demonstration. E.g. in 2015 Sascha was unable
to get my code work, see http://lists.infradead.org/pipermail/barebox/2015-July/024304.html
> > At the moment I have WIP barebox-v2023.11 with integrated picotcp 2.1:
> >
> > https://github.com/frantony/barebox/tree/20231127.picotcp
>
> Cool. Looking at Oleksij's repo, it was based on your work. How well does
> picotcp work for you? What open issues remain with the patch stack? Is the
> barebox integration actively used in projects?
>
> Is https://github.com/tass-belgium/picotcp the official repository? This hasn't
> seen development activity in 5 years. lwIP on the other hand still sees active
> development.
>
> Regarding the license, inclusion of BSD-licensed code is ok. You can check out
> the LICENSES/ subdirectory for the licenses covering barebox.
>
> Cheers,
> Ahmad
>
>
>
>
> >>> We need NFSv4, because it does not need rpcbind, and combines
> >>> filesystem, lockd and other stuff all in one TCP port (2049). Site
> >>> policy also does not allow NFSv2/NFSv3, but allows NFSv4.
> >>
> >> Please note that this only concerns barebox and that kernel nfsroot is
> >> unaffected. You can load kernel and device tree over TFTP and supply a
> >> suitable command line argument to the kernel to use a NFS root.
> >>
> >> The standard net boot target does just that:
> >> https://elixir.bootlin.com/barebox/v2024.01.0/source/defaultenv/defaultenv-2-base/boot/net
> >>
> >> It specifies TCP, but hardcodes v3 currently. I guess we could drop the v3 and let
> >> the kernel decide on its own what version it will use? If that doesn't work, you can
> >> override the file locally in your environment, e.g. via CONFIG_DEFAULT_ENVIRONMENT
> >> pointing at a directory that contains a boot/net file with the appropriate
> >> changes (or just call your boot target something else like boot/nfsv4).
> >>
> >> Hope this helps.
> >>
> >> [1]: Some attempts I am aware of:
> >> https://github.com/a3f/barebox/tree/lwip
> >> https://github.com/olerem/barebox/tree/picotcp-2019.06.29
> >> https://github.com/jmaselbas/barebox/commit/4a987bfdc2ad50c13126dd6290d2477c3fc0c87d
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>> Dan
> >>
> >> --
> >> Pengutronix e.K. | |
> >> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >>
> >>
> >
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Best regards,
Antony Pavlov
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-02-28 7:26 ` Antony Pavlov
@ 2024-02-28 9:20 ` Sascha Hauer
2024-02-28 11:50 ` Antony Pavlov
0 siblings, 1 reply; 18+ messages in thread
From: Sascha Hauer @ 2024-02-28 9:20 UTC (permalink / raw)
To: Antony Pavlov; +Cc: Ahmad Fatoum, Dan Shelton, barebox
On Wed, Feb 28, 2024 at 10:26:15AM +0300, Antony Pavlov wrote:
> On Sat, 17 Feb 2024 09:51:02 +0100
> Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hi All!
>
> > Hello Antony,
> >
> > On 05.02.24 10:59, Antony Pavlov wrote:
> > > On Wed, 31 Jan 2024 22:37:50 +0100
> > > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> > >
> > > Hi All!
> > >
> > >> Hello Dan,
> > >>
> > >> On 31.01.24 22:03, Dan Shelton wrote:
> > >>> Hello!
> > >>>
> > >>> Does barebox support booting from a NFSv4 filesystem, e.g. boot from
> > >>> NFSv4 filesystem into a Linux NFSv4 netroot (diskless machine)?
> > >>
> > >> The barebox network stack only does UDP/IP. There have been attempts to
> > >> bring a TCP stack into barebox, but none have so far succeeded to
> > >> make it mainline. This is a hard requirement before we can consider
> > >> supporting NFSv4. I hope that lwIP could fill this gap in the future,
> > >> but no one is actively continuing this work as far as I am aware[1].
> > >
> > > I have started integration on picotcp into barebox in 2015, see
> > > https://lore.barebox.org/barebox/1436991230-14251-10-git-send-email-antonynpavlov@gmail.com/T/
>
> Actually I made the first attempt to integrate picotcp into barebox in 2014,
> see http://lists.infradead.org/pipermail/barebox/2014-May/019243.html
>
> 10 years is too long for this task :)
>
> In the message http://lists.infradead.org/pipermail/barebox/2015-July/024244.html
> if I understand correctly Sascha asked me to keep network stuff
> users (tftp, nfs, netconsole) as intact as possible.
>
> At the moment I understand that this task is too hard.
>
> The problem is: the network stuff users don't rely on "a network stack"
> in the true sense. E.g. tftp_handler() takes an ETHERNET PACKET on
> it's input, tftp_handler() skips Ethernet and IP stuff by itself
> and modifies UDP fields directly!
>
> This week I have connected picotcp code to the existing network code
> in the way that makes it possible to keep dhcp_handler() and
> ftp_handler() intact. The result is ugly: barebox netdevice driver
> receives frame from network, pass it to picotcp, picotcp parses
> network protocol headers and extracts udp payload, next
> picotcp passes udp payload back to my picotcp-to-barebox adapter,
> the adapter RECONSTRUCTS ETHERNET PACKET and give it to tftp/dhcp_handler()!
> This horrible approach creates more problems than it solves!
So if I understand correctly you tried passing *all* incoming packets to
picotcp and route some of them back to the barebox network stack.
Instead of passing all packets to picotcp, can't we just dispatch the
incoming packets on a per-port basis in barebox and only pass the ones
picotcp shall handle to picotcp?
So basically a struct net_connection with the handler set to the picotcp
receive function?
That way it might be possible to have the barebox network stack and
picotcp in parallel and port the handlers over to pictotcp one by one.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-02-28 9:20 ` Sascha Hauer
@ 2024-02-28 11:50 ` Antony Pavlov
2024-02-28 12:27 ` Sascha Hauer
0 siblings, 1 reply; 18+ messages in thread
From: Antony Pavlov @ 2024-02-28 11:50 UTC (permalink / raw)
To: Sascha Hauer; +Cc: Ahmad Fatoum, Dan Shelton, barebox
On Wed, 28 Feb 2024 10:20:27 +0100
Sascha Hauer <sha@pengutronix.de> wrote:
Hi Sascha!
> On Wed, Feb 28, 2024 at 10:26:15AM +0300, Antony Pavlov wrote:
> > On Sat, 17 Feb 2024 09:51:02 +0100
> > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> > Hi All!
> >
> > > Hello Antony,
> > >
> > > On 05.02.24 10:59, Antony Pavlov wrote:
> > > > On Wed, 31 Jan 2024 22:37:50 +0100
> > > > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> > > >
> > > > Hi All!
> > > >
> > > >> Hello Dan,
> > > >>
> > > >> On 31.01.24 22:03, Dan Shelton wrote:
> > > >>> Hello!
> > > >>>
> > > >>> Does barebox support booting from a NFSv4 filesystem, e.g. boot from
> > > >>> NFSv4 filesystem into a Linux NFSv4 netroot (diskless machine)?
> > > >>
> > > >> The barebox network stack only does UDP/IP. There have been attempts to
> > > >> bring a TCP stack into barebox, but none have so far succeeded to
> > > >> make it mainline. This is a hard requirement before we can consider
> > > >> supporting NFSv4. I hope that lwIP could fill this gap in the future,
> > > >> but no one is actively continuing this work as far as I am aware[1].
> > > >
> > > > I have started integration on picotcp into barebox in 2015, see
> > > > https://lore.barebox.org/barebox/1436991230-14251-10-git-send-email-antonynpavlov@gmail.com/T/
> >
> > Actually I made the first attempt to integrate picotcp into barebox in 2014,
> > see http://lists.infradead.org/pipermail/barebox/2014-May/019243.html
> >
> > 10 years is too long for this task :)
> >
> > In the message http://lists.infradead.org/pipermail/barebox/2015-July/024244.html
> > if I understand correctly Sascha asked me to keep network stuff
> > users (tftp, nfs, netconsole) as intact as possible.
> >
> > At the moment I understand that this task is too hard.
> >
> > The problem is: the network stuff users don't rely on "a network stack"
> > in the true sense. E.g. tftp_handler() takes an ETHERNET PACKET on
> > it's input, tftp_handler() skips Ethernet and IP stuff by itself
> > and modifies UDP fields directly!
> >
> > This week I have connected picotcp code to the existing network code
> > in the way that makes it possible to keep dhcp_handler() and
> > ftp_handler() intact. The result is ugly: barebox netdevice driver
> > receives frame from network, pass it to picotcp, picotcp parses
> > network protocol headers and extracts udp payload, next
> > picotcp passes udp payload back to my picotcp-to-barebox adapter,
> > the adapter RECONSTRUCTS ETHERNET PACKET and give it to tftp/dhcp_handler()!
> > This horrible approach creates more problems than it solves!
> So if I understand correctly you tried passing *all* incoming packets to
> picotcp and route some of them back to the barebox network stack.
for every barebox network device I create picotcp network device
which can send packets by picotcp initiative.
net_receive() just calls pico_stack_recv() with corresponding
picotcp network device as an argument, so no code change in drivers/net/.
net_poll() just calls pico_stack_tick().
So all incoming packets go to picotcp only.
Picotcp can send packet if necessary without barebox interraction.
UDP datagrams processed by picotcp routed to corresponding dhcp/tftp_handler().
Are dhcp/tftp_handlers parts of barebox network stack?
> Instead of passing all packets to picotcp, can't we just dispatch the
> incoming packets on a per-port basis in barebox and only pass the ones
> picotcp shall handle to picotcp?
Good idea. I have to try. We can reroute IPv6 traffic to picotcp in net_receive()
and reroute TCP/IPv4 traffic to picotcp in net_handle_ip().
> So basically a struct net_connection with the handler set to the picotcp
> receive function?
net_connection handler is set to the normal unamended dhcp/tftp_handlers.
> That way it might be possible to have the barebox network stack and
> picotcp in parallel and port the handlers over to pictotcp one by one.
But I see a problem here. If there is a ARP respond in the incoming traffic
I have no idea there to send it. Both barebox network code and picotcp
can make ARP request. I suppose can just route ARP respond to the both stacks.
But what I have to do if an ARP or ICMP echo __request__ is received?
I suppose it is possible to add some simple dynamic incoming packet filtration rules
that can be changed on-the-fly for testing purposes.
--
Best regards,
Antony Pavlov
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 boot support?
2024-02-28 11:50 ` Antony Pavlov
@ 2024-02-28 12:27 ` Sascha Hauer
0 siblings, 0 replies; 18+ messages in thread
From: Sascha Hauer @ 2024-02-28 12:27 UTC (permalink / raw)
To: Antony Pavlov; +Cc: Ahmad Fatoum, Dan Shelton, barebox
On Wed, Feb 28, 2024 at 02:50:58PM +0300, Antony Pavlov wrote:
> On Wed, 28 Feb 2024 10:20:27 +0100
> Sascha Hauer <sha@pengutronix.de> wrote:
>
>
> Hi Sascha!
>
> > On Wed, Feb 28, 2024 at 10:26:15AM +0300, Antony Pavlov wrote:
> > > On Sat, 17 Feb 2024 09:51:02 +0100
> > > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> > >
> > > Hi All!
> > >
> > > > Hello Antony,
> > > >
> > > > On 05.02.24 10:59, Antony Pavlov wrote:
> > > > > On Wed, 31 Jan 2024 22:37:50 +0100
> > > > > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> > > > >
> > > > > Hi All!
> > > > >
> > > > >> Hello Dan,
> > > > >>
> > > > >> On 31.01.24 22:03, Dan Shelton wrote:
> > > > >>> Hello!
> > > > >>>
> > > > >>> Does barebox support booting from a NFSv4 filesystem, e.g. boot from
> > > > >>> NFSv4 filesystem into a Linux NFSv4 netroot (diskless machine)?
> > > > >>
> > > > >> The barebox network stack only does UDP/IP. There have been attempts to
> > > > >> bring a TCP stack into barebox, but none have so far succeeded to
> > > > >> make it mainline. This is a hard requirement before we can consider
> > > > >> supporting NFSv4. I hope that lwIP could fill this gap in the future,
> > > > >> but no one is actively continuing this work as far as I am aware[1].
> > > > >
> > > > > I have started integration on picotcp into barebox in 2015, see
> > > > > https://lore.barebox.org/barebox/1436991230-14251-10-git-send-email-antonynpavlov@gmail.com/T/
> > >
> > > Actually I made the first attempt to integrate picotcp into barebox in 2014,
> > > see http://lists.infradead.org/pipermail/barebox/2014-May/019243.html
> > >
> > > 10 years is too long for this task :)
> > >
> > > In the message http://lists.infradead.org/pipermail/barebox/2015-July/024244.html
> > > if I understand correctly Sascha asked me to keep network stuff
> > > users (tftp, nfs, netconsole) as intact as possible.
> > >
> > > At the moment I understand that this task is too hard.
> > >
> > > The problem is: the network stuff users don't rely on "a network stack"
> > > in the true sense. E.g. tftp_handler() takes an ETHERNET PACKET on
> > > it's input, tftp_handler() skips Ethernet and IP stuff by itself
> > > and modifies UDP fields directly!
> > >
> > > This week I have connected picotcp code to the existing network code
> > > in the way that makes it possible to keep dhcp_handler() and
> > > ftp_handler() intact. The result is ugly: barebox netdevice driver
> > > receives frame from network, pass it to picotcp, picotcp parses
> > > network protocol headers and extracts udp payload, next
> > > picotcp passes udp payload back to my picotcp-to-barebox adapter,
> > > the adapter RECONSTRUCTS ETHERNET PACKET and give it to tftp/dhcp_handler()!
> > > This horrible approach creates more problems than it solves!
>
> > So if I understand correctly you tried passing *all* incoming packets to
> > picotcp and route some of them back to the barebox network stack.
>
> for every barebox network device I create picotcp network device
> which can send packets by picotcp initiative.
> net_receive() just calls pico_stack_recv() with corresponding
> picotcp network device as an argument, so no code change in drivers/net/.
> net_poll() just calls pico_stack_tick().
> So all incoming packets go to picotcp only.
> Picotcp can send packet if necessary without barebox interraction.
>
> UDP datagrams processed by picotcp routed to corresponding dhcp/tftp_handler().
> Are dhcp/tftp_handlers parts of barebox network stack?
>
> > Instead of passing all packets to picotcp, can't we just dispatch the
> > incoming packets on a per-port basis in barebox and only pass the ones
> > picotcp shall handle to picotcp?
>
> Good idea. I have to try. We can reroute IPv6 traffic to picotcp in net_receive()
> and reroute TCP/IPv4 traffic to picotcp in net_handle_ip().
You could route all TCP to picotcp. Also everything that falls through
net_handle_udp() can be routed to picotctp as well.
>
> > So basically a struct net_connection with the handler set to the picotcp
> > receive function?
>
> net_connection handler is set to the normal unamended dhcp/tftp_handlers.
>
> > That way it might be possible to have the barebox network stack and
> > picotcp in parallel and port the handlers over to pictotcp one by one.
>
> But I see a problem here. If there is a ARP respond in the incoming traffic
> I have no idea there to send it. Both barebox network code and picotcp
> can make ARP request. I suppose can just route ARP respond to the both stacks.
Yes, sending it to both stacks should be fine. When a response is coming
in and nobody wait for it then both barebox and picotctp should just
discard it.
>
> But what I have to do if an ARP or ICMP echo __request__ is received?
Should go to only one of both stacks, otherwise we would get duplicate
ping responses.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 18+ messages in thread