Re: [RFC v2 00/16] barebox picotcp integration (2015.07.19)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 20 Jul 2015 09:10:13 +0200
Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote:

> Hi Antony,
> 
> On Sun, Jul 19, 2015 at 11:07:07PM +0300, Antony Pavlov wrote:
> > I have just published latest picotcp-enabled barebox.
> > Please see my 20150719.picotcp branch in my github barebox repo
> > (https://github.com/frantony/barebox/tree/20150719.picotcp).
> > 
> > This version is based on the latest barebox-next and picotcp v1.5.0
> > (there is also picotcp v1.5.1, but is has no interested
> > for barebox changes since v1.5.0).
> > 
> > 
> > Changes since 2015.07.15 (see http://lists.infradead.org/pipermail/barebox/2015-June/024174.html):
> > 
> >     * net: UDP API changed to satisfy the picotcp integration needs;
> >     * nfs, tftp and dns subsystems have no picotcp-related stuff anymore.
> >     * netconsole works on top of picotcp with no additional changes.
> > 
> > 
> > Here are some notes:
> > 
> >   1. just now tftp/nfs file transfer on top of picotcp is slower than
> >      the same transfer on top of legacy network stack;
> > 
> >   2. there is no $<current network interface> anymore,
> >      so dhcp, tftp and ifup commands don't work on top of picotcp.
> >      The ifconfig command is used for network interfaces setup.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the reason of your 'Ping timeout!!!'

> 
> I can't get this version to work. I have done:
> 
> # eth0.ethaddr=00:04:9f:01:b5:37
> # eth0.ipaddr=192.168.23.170
> # eth0.netmask=255.255.0.0
> # mount -t tftp 192.168.23.4 /mnt/
> # cp mnt/b b
> T T T T could not open mnt/b: Interrupted system call
> # picoping 192.168.23.4
>  ---- Ping timeout!!!
> PING 1 to 192.168.23.4: Error 1
> picoping: I/O error
> 
> Anything I have missed?

Please use ifconfig for interface setup. E.g.

ifconfig eth 192.168.23.170 255.255.0.0

I think it is possible to implement network interface setup via 
eth0.ipaddr and eth0.netmask manipulation (and even sacrifice ifconfig command).


Here is my picotcp test script

#!/bin/sh

SERVER=192.168.100.1
ifconfig eth 192.168.100.2 255.255.255.0

picoping $SERVER

net.nameserver=$SERVER
host barebox.example.com
host www.example.com

mount -t nfs $SERVER:/tftpboot /mnt
ls /mnt
md5sum /mnt/bash
umount /mnt
ls /mnt

mount -t tftp $SERVER /mnt
md5sum /mnt/test
umount /mnt

> I noticed that the MAC address is no longer set and the stack no longer
> checks for a link. I believe picotcp should call eth_send rather than
> invoking eth->send directly.

Hmmm, It looks like I have completely missed any MAC-address manipulation stuff.

I see no means to use eth_send() from picotcp code at the moment.

Just now picotcp "parasitize" on legacy stack: for one phisical network interface
there are the picotcp network interface and the legacy network interface at the same time,
but only picotcp actualy operates (but some legacy network interface functions are not
realized).

The main problem is that barebox has the 'only one network interface is active' conception,
but picotcp can handle several active network interfaces at the same time.
In this patchseries the 'only one network interface is active' conception is not used, so
some commands (dhcp, ifup) do not work.

Picotcp selects necessary network interface for eth->send() invoking after routing.
But if I just call eth_send() from picotcp a collision is possible.
E.g. if you have two network interfaces and picotcp want to use the 2nd for packet sending
but barebox thinks that the 1st interface is active then eth_send() leads to sending via the 1st one.

I think it is possible to impart current_active_interface
property to picotcp-barebox glue code for smooth integration.

I'll try to take into account your notes in the next picotcp integration patchseries;

-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox




[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux