barebox + picotcp-1.7.0

barebox + picotcp-1.7.0

[Antony Pavlov]

Hi all!

In the message [1] Sascha proposed to have the barebox network stack
and picotcp in parallel.

This approach is used in the branch 20240303.picotcp-1.7.0 from
https://github.com/frantony/barebox/ repo [2]:

* all incoming packets go through the barebox network stack and only if
  they are not processed by it, they are forwarded to the picotcp network
  stack (all incoming ARP packets always go to the picotcp network stack).

* risc-v virtual qemu machine with user networking (slirp network stack)
  is used for demonstration; one needs only qemu risc-v emulator
  for demonstration;

* these barebox commands are introduced for picotcp stack capabilities
  demonstration:

  * dhclient --- setup picotcp network interface using the DHCP protocol;
  * ifconfig --- print/setup picotcp network interface information;
  * route --- print picotcp routing table;
  * picoping --- send ICMP ECHO_REQUEST to network hosts, receive replies;
  * picohost --- perform DNS lookup (google DNS server is used);
  * app_wget --- download file using the HTTP protocol.

* tcpdump code is incorporated into barebox for network stack debugging.
  tcpdump supports parsing most of the protocols supported by barebox
  (DHCP, ARP, ICMP, DNS, TFTP and TCP).

Please comment!

  [1] http://lists.infradead.org/pipermail/barebox/2024-February/045937.html
  [2] https://github.com/frantony/barebox/tree/20240303.picotcp-1.7.0

-- 
Best regards,
  Antony Pavlov

Re: barebox + picotcp-1.7.0

[Sascha Hauer]

Hi Antony,

On Sun, Mar 03, 2024 at 09:58:03PM +0300, Antony Pavlov wrote:
> Hi all!
> 
> In the message [1] Sascha proposed to have the barebox network stack
> and picotcp in parallel.
> 
> This approach is used in the branch 20240303.picotcp-1.7.0 from
> https://github.com/frantony/barebox/ repo [2]:
> 
> * all incoming packets go through the barebox network stack and only if
>   they are not processed by it, they are forwarded to the picotcp network
>   stack (all incoming ARP packets always go to the picotcp network stack).
> 
> * risc-v virtual qemu machine with user networking (slirp network stack)
>   is used for demonstration; one needs only qemu risc-v emulator
>   for demonstration;
> 
> * these barebox commands are introduced for picotcp stack capabilities
>   demonstration:
> 
>   * dhclient --- setup picotcp network interface using the DHCP protocol;
>   * ifconfig --- print/setup picotcp network interface information;
>   * route --- print picotcp routing table;
>   * picoping --- send ICMP ECHO_REQUEST to network hosts, receive replies;
>   * picohost --- perform DNS lookup (google DNS server is used);
>   * app_wget --- download file using the HTTP protocol.
> 
> * tcpdump code is incorporated into barebox for network stack debugging.
>   tcpdump supports parsing most of the protocols supported by barebox
>   (DHCP, ARP, ICMP, DNS, TFTP and TCP).

I gave this a test on real hardware. I think the result is similar to
yours, dhclient, ifconfig, route, picoping, picohost work as expected.
app_wget does not work, it bails out with a NULL pointer exception.

I don't seem to have access to the Google DNS server, I switched this to
our local nameserver. Here global.net.nameserver should be used finally.

It's a bit odd that barebox and picotcp both use different configs, so
that we have to call barebox dhcp and also dhclient to make a network
interface usable in both barebox and picotcp. That should be a solvable
issue though.

Overall this looks like a good base for having both barebox network
stack and picotcp in parallel, so we could enable picotcp when needed
and still keep traditional barebox networking at least for a grace
period.

I'd still like to test lwip as well. Given that there are patches for
U-Boot already this should be doable without too much effort. The
integration into U-Boot likely shows the places we have to touch.

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 |

Re: barebox + picotcp-1.7.0

[Antony Pavlov]

On Mon, 4 Mar 2024 15:47:39 +0100
Sascha Hauer <sha@pengutronix.de> wrote:

Hi Sascha!

> On Sun, Mar 03, 2024 at 09:58:03PM +0300, Antony Pavlov wrote:
> > Hi all!
> > 
> > In the message [1] Sascha proposed to have the barebox network stack
> > and picotcp in parallel.
> > 
> > This approach is used in the branch 20240303.picotcp-1.7.0 from
> > https://github.com/frantony/barebox/ repo [2]:
> > 
> > * all incoming packets go through the barebox network stack and only if
> >   they are not processed by it, they are forwarded to the picotcp network
> >   stack (all incoming ARP packets always go to the picotcp network stack).
> > 
> > * risc-v virtual qemu machine with user networking (slirp network stack)
> >   is used for demonstration; one needs only qemu risc-v emulator
> >   for demonstration;
> > 
> > * these barebox commands are introduced for picotcp stack capabilities
> >   demonstration:
> > 
> >   * dhclient --- setup picotcp network interface using the DHCP protocol;
> >   * ifconfig --- print/setup picotcp network interface information;
> >   * route --- print picotcp routing table;
> >   * picoping --- send ICMP ECHO_REQUEST to network hosts, receive replies;
> >   * picohost --- perform DNS lookup (google DNS server is used);
> >   * app_wget --- download file using the HTTP protocol.
> > 
> > * tcpdump code is incorporated into barebox for network stack debugging.
> >   tcpdump supports parsing most of the protocols supported by barebox
> >   (DHCP, ARP, ICMP, DNS, TFTP and TCP).
> 
> I gave this a test on real hardware. I think the result is similar to
> yours, dhclient, ifconfig, route, picoping, picohost work as expected.
> app_wget does not work, it bails out with a NULL pointer exception.

I have updated my picotcp branches (see [1], [2]). I have tested
picotcp-1.7.0 on my Raspberry Pi 2. app_wget works on Raspberry Pi 2
without any exceptions.

I have found that using picotcp on real hardware has negative effect
on UART console (at least on Praspberry Pi 2 with USB-connected ethernet
adapter): console drops characters from time to time.

> I don't seem to have access to the Google DNS server, I switched this to
> our local nameserver. Here global.net.nameserver should be used finally.
>
> It's a bit odd that barebox and picotcp both use different configs, so
> that we have to call barebox dhcp and also dhclient to make a network
> interface usable in both barebox and picotcp. That should be a solvable
> issue though.

I have fixed this problem. Now dhclient updates ethX.* and global.net.*
variables. Please note that picotcp dhcp client does not handle
rootpath, device tree and tftp server parameters. I think
that we can ignore current disadvantages of dhclient, picoping and picohost.
These commands are used just for demonstration. They are just
slightly reworked demo programs. We have to rework them more
carefully to replace our traditional network commands.

The TCP support is much more attractive feature. app_wget is adapted
example from picotcp-modules repo [3] (not the main picotcp repo!).
app_wget relies on incomplete libhttp library. You can see that app_wget
dumps html-page with wrong offset. I used app_wget just for demonstration
because it was most simple TCP-enabled application.
Now I think that telnet-client/server would be more useful demo program.
Also please note that there is "the old" picotcp-1.7.0 and "the modern"
picotcp-2.1. I have the branch with picotcp-2.1 but it lacks
libhttp support.

My next step is to add tcp-enabled application to picotcp-2.1.

[1] https://github.com/frantony/barebox/tree/20240310.picotcp-1.7.0
[2] https://github.com/frantony/barebox/tree/20240310.picotcp-2.1
[3] https://github.com/tass-belgium/picotcp-modules

-- 
Best regards,
  Antony Pavlov