On Mon, 4 Mar 2024 15:47:39 +0100 Sascha Hauer <sha@xxxxxxxxxxxxxx> 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
