* Adding IPv4 multicast support @ 2014-07-13 10:11 Colin Leitner 2014-07-13 10:55 ` Antony Pavlov 0 siblings, 1 reply; 22+ messages in thread From: Colin Leitner @ 2014-07-13 10:11 UTC (permalink / raw) To: barebox Hello everyone, I'm working on adding multicast support to barebox (for device discovery) and wanted to know if there's interest in having that included in upstream. Cheers, Colin _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Adding IPv4 multicast support 2014-07-13 10:11 Adding IPv4 multicast support Colin Leitner @ 2014-07-13 10:55 ` Antony Pavlov 2014-07-13 10:52 ` Colin Leitner 2014-07-13 14:28 ` Daniele Lacamera 0 siblings, 2 replies; 22+ messages in thread From: Antony Pavlov @ 2014-07-13 10:55 UTC (permalink / raw) To: Colin Leitner; +Cc: barebox, Daniele Lacamera On Sun, 13 Jul 2014 12:11:17 +0200 Colin Leitner <colin.leitner@googlemail.com> wrote: > Hello everyone, > > I'm working on adding multicast support to barebox (for device discovery) and wanted to know if there's interest in having that included in upstream. There is an initiative on integrating picotcp into barebox. picotcp is a free TCP/IP stack implementation, see https://github.com/tass-belgium/picotcp AFAIK latest picotcp-enbled barebox anounced here: http://lists.infradead.org/pipermail/barebox/2014-June/019723.html Can be network device discovery realized using picotcp entities? To Daniele: how things stand with picotcp tftp support? > _______________________________________________ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox -- -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Adding IPv4 multicast support 2014-07-13 10:55 ` Antony Pavlov @ 2014-07-13 10:52 ` Colin Leitner 2014-07-13 13:15 ` Colin Leitner 2014-07-13 14:28 ` Daniele Lacamera 1 sibling, 1 reply; 22+ messages in thread From: Colin Leitner @ 2014-07-13 10:52 UTC (permalink / raw) To: Antony Pavlov, Colin Leitner; +Cc: barebox, Daniele Lacamera > Can be network device discovery realized using picotcp entities? A quick glance at picotcp seems to indicate mcast support, so that should work. I'll probably just push the patches to a github repository until picotcp lands. _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Adding IPv4 multicast support 2014-07-13 10:52 ` Colin Leitner @ 2014-07-13 13:15 ` Colin Leitner 0 siblings, 0 replies; 22+ messages in thread From: Colin Leitner @ 2014-07-13 13:15 UTC (permalink / raw) To: Colin Leitner, Antony Pavlov; +Cc: barebox, Daniele Lacamera > > I'll probably just push the patches to a github repository until picotcp lands. > Patches can be found at https://github.com/cleitner/barebox-mcast/tree/multicast Commits * 8e99783f775ef8013ea9f5e5f9fa881002cd21a2 * f5f78253ce2e48affbb0b3bf9726b3b6e684b509 * 0dd506b341a61855b9b526c6c0de3da2d4c4e0a9 are small cleanups to the network code and could be merged even if multicast support is deemed unnecessary. Multicast connections are used like any other UDP connection: con = net_udp_new(string_to_ip("224.0.0.123"), 12345, handler, priv); net_udp_bind(con, 12345); I only patched the drivers smc91111 (tested) and smc911x (untested) to receive multicast packets. Other drivers are likely just as easy to patch. Have fun, Colin _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Adding IPv4 multicast support 2014-07-13 10:55 ` Antony Pavlov 2014-07-13 10:52 ` Colin Leitner @ 2014-07-13 14:28 ` Daniele Lacamera 2014-07-15 7:01 ` picotcp tftp support [was Adding IPv4 multicast support] Antony Pavlov 2014-07-15 18:17 ` Adding IPv4 multicast support Colin Leitner 1 sibling, 2 replies; 22+ messages in thread From: Daniele Lacamera @ 2014-07-13 14:28 UTC (permalink / raw) To: Antony Pavlov; +Cc: Colin Leitner, PicoTCP, barebox On Sun, Jul 13, 2014 at 12:55 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > On Sun, 13 Jul 2014 12:11:17 +0200 > Colin Leitner <colin.leitner@googlemail.com> wrote: > >> Hello everyone, >> >> I'm working on adding multicast support to barebox (for device discovery) and wanted to know if there's interest in having that included in upstream. > > There is an initiative on integrating picotcp into barebox. > > picotcp is a free TCP/IP stack implementation, see > https://github.com/tass-belgium/picotcp > > AFAIK latest picotcp-enbled barebox anounced here: > http://lists.infradead.org/pipermail/barebox/2014-June/019723.html > > Can be network device discovery realized using picotcp entities? > > To Daniele: how things stand with picotcp tftp support? > > >> _______________________________________________ >> barebox mailing list >> barebox@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/barebox > > > -- > -- > Best regards, > Antony Pavlov TFTP is integrated in masterbranch, documented and tested. PicoTCP app can act as TFTP server as well as client. Supports put/get operations. Tested against tftp(d)-hpa. What would you need for "network discovery"? Currently picotcp supports the following protocols: - IPv6 neighbor discovery - IPv4 SLAAC (like avahi-style autoconf) - mDNS (at the moment over v4 only) - OLSR (automatic detection of neighbors and best route calculation to N-hops nodes) Regards, -- Daniele _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-07-13 14:28 ` Daniele Lacamera @ 2014-07-15 7:01 ` Antony Pavlov 2014-07-15 9:31 ` Daniele Lacamera 2014-07-15 18:17 ` Adding IPv4 multicast support Colin Leitner 1 sibling, 1 reply; 22+ messages in thread From: Antony Pavlov @ 2014-07-15 7:01 UTC (permalink / raw) To: Daniele Lacamera; +Cc: barebox, PicoTCP On Sun, 13 Jul 2014 16:28:58 +0200 Daniele Lacamera <daniele.lacamera@tass.be> wrote: > On Sun, Jul 13, 2014 at 12:55 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > > On Sun, 13 Jul 2014 12:11:17 +0200 > > Colin Leitner <colin.leitner@googlemail.com> wrote: > > > >> Hello everyone, > >> > >> I'm working on adding multicast support to barebox (for device discovery) and wanted to know if there's interest in having that included in upstream. > > > > There is an initiative on integrating picotcp into barebox. > > > > picotcp is a free TCP/IP stack implementation, see > > https://github.com/tass-belgium/picotcp > > > > AFAIK latest picotcp-enbled barebox anounced here: > > http://lists.infradead.org/pipermail/barebox/2014-June/019723.html > > > > Can be network device discovery realized using picotcp entities? > > > > To Daniele: how things stand with picotcp tftp support? ... > > TFTP is integrated in masterbranch, documented and tested. > PicoTCP app can act as TFTP server as well as client. Supports put/get > operations. Tested against tftp(d)-hpa. barebox uses POSIX file interface for working with tftp. We have to provide these basic functions (see fs/tftp.c): static struct fs_driver_d tftp_driver = { .open = tftp_open, .read = tftp_read, .write = tftp_write, .close = tftp_close, /* Other functions for unlink, truncate, mkdir, rmdir, stat, opendir, lseek, create are not so important. */ }; So **fs/tftp.c code is driven** by user code that uses file interface for accessing to the files on tftp-server. AFAI understand picotcp tftp support uses event-driven interface so **user code is driven** by picotcp tftp support code. How we can use picotcp tftp support for realization of POSIX file interface? -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-07-15 7:01 ` picotcp tftp support [was Adding IPv4 multicast support] Antony Pavlov @ 2014-07-15 9:31 ` Daniele Lacamera 2014-07-15 10:27 ` Antony Pavlov 0 siblings, 1 reply; 22+ messages in thread From: Daniele Lacamera @ 2014-07-15 9:31 UTC (permalink / raw) To: Antony Pavlov; +Cc: barebox On Tue, Jul 15, 2014 at 9:01 AM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > > barebox uses POSIX file interface for working with tftp. > > We have to provide these basic functions (see fs/tftp.c): > > static struct fs_driver_d tftp_driver = { > .open = tftp_open, > .read = tftp_read, > .write = tftp_write, > .close = tftp_close, > /* Other functions for unlink, truncate, > mkdir, rmdir, stat, opendir, lseek, create > are not so important. */ > }; > > So **fs/tftp.c code is driven** by user code that > uses file interface for accessing to the files > on tftp-server. > > AFAI understand picotcp tftp support uses event-driven interface > so **user code is driven** by picotcp tftp support code. > > How we can use picotcp tftp support for realization > of POSIX file interface? Hi Antony, I will be able to provide such an interface by using a similar approach to what you used for ping (so via net_poll() routine called in a loop), assuming that your posix-like interface expects blocking calls for read/write operations. The loop will also be interruptible via CTRL+C. I would like to know more about this approach though, are you implementing client only functionality (get/put) or do you want to be able to listen for client "connections" as well? How is the connection initiated (I see there is a tftp_probe function that's not included in the API group)? Thanks, /d _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-07-15 9:31 ` Daniele Lacamera @ 2014-07-15 10:27 ` Antony Pavlov 2014-07-15 10:57 ` Daniele Lacamera 0 siblings, 1 reply; 22+ messages in thread From: Antony Pavlov @ 2014-07-15 10:27 UTC (permalink / raw) To: Daniele Lacamera; +Cc: barebox On Tue, 15 Jul 2014 11:31:29 +0200 Daniele Lacamera <daniele.lacamera@tass.be> wrote: > On Tue, Jul 15, 2014 at 9:01 AM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > > > > barebox uses POSIX file interface for working with tftp. > > > > We have to provide these basic functions (see fs/tftp.c): > > > > static struct fs_driver_d tftp_driver = { > > .open = tftp_open, > > .read = tftp_read, > > .write = tftp_write, > > .close = tftp_close, > > /* Other functions for unlink, truncate, > > mkdir, rmdir, stat, opendir, lseek, create > > are not so important. */ > > }; > > > > So **fs/tftp.c code is driven** by user code that > > uses file interface for accessing to the files > > on tftp-server. > > > > AFAI understand picotcp tftp support uses event-driven interface > > so **user code is driven** by picotcp tftp support code. > > > > How we can use picotcp tftp support for realization > > of POSIX file interface? > > Hi Antony, > > I will be able to provide such an interface by using a similar > approach to what you used for ping (so via net_poll() routine called > in a loop), assuming that your posix-like interface expects blocking > calls for read/write operations. Alas! We can't use this approach for tftp because tftp is a FILESYSTEM in barebox. Tftp user code know nothing about network stuff. User code just use read and write for acessing file data, no matter which driver (ramdisk, SATA, MTD, I2C or network) is used for actual data transfer. > The loop will also be interruptible via CTRL+C. > > I would like to know more about this approach though, are you > implementing client only functionality (get/put) or do you want to be > able to listen for client "connections" as well? How is the connection > initiated (I see there is a tftp_probe function that's not included in > the API group)? > > Thanks, > > /d -- -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-07-15 10:27 ` Antony Pavlov @ 2014-07-15 10:57 ` Daniele Lacamera 2014-07-15 12:57 ` Antony Pavlov 2014-07-16 6:30 ` Sascha Hauer 0 siblings, 2 replies; 22+ messages in thread From: Daniele Lacamera @ 2014-07-15 10:57 UTC (permalink / raw) To: Antony Pavlov; +Cc: barebox On Tue, Jul 15, 2014 at 12:27 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: >> I will be able to provide such an interface by using a similar >> approach to what you used for ping (so via net_poll() routine called >> in a loop), assuming that your posix-like interface expects blocking >> calls for read/write operations. > > Alas! We can't use this approach for tftp because tftp is a FILESYSTEM in barebox. Then again, I'd like to know if your FS implementation actually needs blocking call, and in case, where is the code supposed to block. Does barebox have some kind of support for multiple threads, or a default event loop where background operations can be added? Or are the FS calls non blocking? Sorry for asking dumb questions, I am not a barebox developer and I am just trying to figure out what is your execution model. There certainly is a way to integrate my TFTP implementation as soon as I realize what is your model: as for instance we have blocking POSIX socket calls implemented with and without an OS infrastructure, and we are able to realize blocking calls on any systems, being baremetal or multithtreaded. Thanks /D _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-07-15 10:57 ` Daniele Lacamera @ 2014-07-15 12:57 ` Antony Pavlov 2014-07-15 15:55 ` Daniele Lacamera 2014-07-16 6:30 ` Sascha Hauer 1 sibling, 1 reply; 22+ messages in thread From: Antony Pavlov @ 2014-07-15 12:57 UTC (permalink / raw) To: Daniele Lacamera; +Cc: barebox On Tue, 15 Jul 2014 12:57:21 +0200 Daniele Lacamera <daniele.lacamera@tass.be> wrote: > On Tue, Jul 15, 2014 at 12:27 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > > >> I will be able to provide such an interface by using a similar > >> approach to what you used for ping (so via net_poll() routine called > >> in a loop), assuming that your posix-like interface expects blocking > >> calls for read/write operations. > > > > Alas! We can't use this approach for tftp because tftp is a FILESYSTEM in barebox. > > Then again, I'd like to know if your FS implementation actually needs > blocking call, and in case, where is the code supposed to block. Does > barebox have some kind of support for multiple threads, or a default > event loop where background operations can be added? Or are the FS > calls non blocking? AFAIK barebox does not support threads. Also all filesystem calls are blocking. > Sorry for asking dumb questions, I am not a barebox developer and I am > just trying to figure out what is your execution model. There > certainly is a way to integrate my TFTP implementation as soon as I > realize what is your model: as for instance we have blocking POSIX > socket calls implemented with and without an OS infrastructure, and we > are able to realize blocking calls on any systems, being baremetal or > multithtreaded. > > Thanks > > /D -- -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-07-15 12:57 ` Antony Pavlov @ 2014-07-15 15:55 ` Daniele Lacamera 2014-07-15 19:02 ` Antony Pavlov 0 siblings, 1 reply; 22+ messages in thread From: Daniele Lacamera @ 2014-07-15 15:55 UTC (permalink / raw) To: Antony Pavlov; +Cc: barebox On Tue, Jul 15, 2014 at 2:57 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > On Tue, 15 Jul 2014 12:57:21 +0200 > Daniele Lacamera <daniele.lacamera@tass.be> wrote: > >> On Tue, Jul 15, 2014 at 12:27 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: >> >> >> I will be able to provide such an interface by using a similar >> >> approach to what you used for ping (so via net_poll() routine called >> >> in a loop), assuming that your posix-like interface expects blocking >> >> calls for read/write operations. >> > >> > Alas! We can't use this approach for tftp because tftp is a FILESYSTEM in barebox. >> >> Then again, I'd like to know if your FS implementation actually needs >> blocking call, and in case, where is the code supposed to block. Does >> barebox have some kind of support for multiple threads, or a default >> event loop where background operations can be added? Or are the FS >> calls non blocking? > > AFAIK barebox does not support threads. > Also all filesystem calls are blocking. > Then for me it is still not clear *where* a filesystem call is blocking. On a multi-threaded system, the calls is supposed to block somewhere in thread_sleep() functions. On a single thread execution model, we will need to tick the TCP/IP stack in the background while the call is "busy". Suppose that you issue a read call to any network filesystem (in this case TFTP issuing a get command). The file needs to be retreived by the TCP/IP stack, so I guess that the only implementation that makes sense would be something like: while (callback_has_not_been_called) { if(ctrlc()) break; pico_stack_tick(); // maybe sleep here } What you stated earlier, i.e. > Tftp user code know nothing about network stuff. User code just use read and write > for acessing file data, no matter which driver (ramdisk, SATA, MTD, I2C or network) > is used for actual data transfer. does not make much sense to me, as the network is required to access remote files, so the stack needs to tick constantly under the hood if you want to receive packets while your read call is blocked waiting for data. User does not need to know that her read call is going through the network, but the TFTP fs module (or another underlying "driver") is supposed to access the picotcp API properly to retrieve the data needed when I/O operations are running. The intermediate layer (the new fs/tftp.c) is supposed to issue a stack tick whenever it is suspended waiting for network events. Finally, I will assume that the use case needed is TFTP working in client mode, issuing GET/PUT commands upon open posix calls. I can provide to you (and the list) an example implementation, which I will develop on top of your latest picotcp branch and test via sandbox/tuntap. In the meanwhile, any comment on the topic by barebox developers are more than welcome. Thanks /d _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-07-15 15:55 ` Daniele Lacamera @ 2014-07-15 19:02 ` Antony Pavlov 0 siblings, 0 replies; 22+ messages in thread From: Antony Pavlov @ 2014-07-15 19:02 UTC (permalink / raw) To: Daniele Lacamera; +Cc: barebox On Tue, 15 Jul 2014 17:55:21 +0200 Daniele Lacamera <daniele.lacamera@tass.be> wrote: > On Tue, Jul 15, 2014 at 2:57 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > > On Tue, 15 Jul 2014 12:57:21 +0200 > > Daniele Lacamera <daniele.lacamera@tass.be> wrote: > > > >> On Tue, Jul 15, 2014 at 12:27 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > >> > >> >> I will be able to provide such an interface by using a similar > >> >> approach to what you used for ping (so via net_poll() routine called > >> >> in a loop), assuming that your posix-like interface expects blocking > >> >> calls for read/write operations. > >> > > >> > Alas! We can't use this approach for tftp because tftp is a FILESYSTEM in barebox. > >> > >> Then again, I'd like to know if your FS implementation actually needs > >> blocking call, and in case, where is the code supposed to block. Does > >> barebox have some kind of support for multiple threads, or a default > >> event loop where background operations can be added? Or are the FS > >> calls non blocking? > > > > AFAIK barebox does not support threads. > > Also all filesystem calls are blocking. > > > > Then for me it is still not clear *where* a filesystem call is > blocking. On a multi-threaded system, the calls is supposed to block > somewhere in thread_sleep() functions. On a single thread execution > model, we will need to tick the TCP/IP stack in the background while > the call is "busy". Suppose that you issue a read call to any network > filesystem (in this case TFTP issuing a get command). The file needs > to be retreived by the TCP/IP stack, so I guess that the only > implementation that makes sense would be something like: > > while (callback_has_not_been_called) { > if(ctrlc()) > break; > pico_stack_tick(); > // maybe sleep here > } > > What you stated earlier, i.e. > > Tftp user code know nothing about network stuff. User code just use read and write > > for acessing file data, no matter which driver (ramdisk, SATA, MTD, I2C or network) > > is used for actual data transfer. > > does not make much sense to me, as the network is required to access > remote files, so the stack needs to tick constantly under the hood if > you want to receive packets while your read call is blocked waiting > for data. > > User does not need to know that her read call is going through the > network, but the TFTP fs module (or another underlying "driver") is > supposed to access the picotcp API properly to retrieve the data > needed when I/O operations are running. The intermediate layer (the > new fs/tftp.c) is supposed to issue a stack tick whenever it is > suspended waiting for network events. > > Finally, I will assume that the use case needed is TFTP working in > client mode, issuing GET/PUT commands upon open posix calls. > > I can provide to you (and the list) an example implementation, which I > will develop on top of your latest picotcp branch and test via > sandbox/tuntap. In the meanwhile, any comment on the topic by barebox > developers are more than welcome. First of all please make it possible to use several tftp clients simultaneously (current picotcp tftp API has no "tftp session descriptor"). Here is a simple tftp barebox usecase (I have just checked it): barebox:/ mkdir /mnt barebox:/ dhcp # get $eth0.serverip from dhcp barebox:/ mount -t tftp $eth0.serverip /mnt barebox:/ cp /mnt/file1 /mnt/file2 In this sample we have two tftp clients working simultaneously, One can easely construct more complex usecase, e.g. two tftp servers, one is mounted to /mnt1 and another is mounted to /mnt2. -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-07-15 10:57 ` Daniele Lacamera 2014-07-15 12:57 ` Antony Pavlov @ 2014-07-16 6:30 ` Sascha Hauer 2014-07-16 6:48 ` Daniele Lacamera 1 sibling, 1 reply; 22+ messages in thread From: Sascha Hauer @ 2014-07-16 6:30 UTC (permalink / raw) To: Daniele Lacamera; +Cc: barebox On Tue, Jul 15, 2014 at 12:57:21PM +0200, Daniele Lacamera wrote: > On Tue, Jul 15, 2014 at 12:27 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > > >> I will be able to provide such an interface by using a similar > >> approach to what you used for ping (so via net_poll() routine called > >> in a loop), assuming that your posix-like interface expects blocking > >> calls for read/write operations. > > > > Alas! We can't use this approach for tftp because tftp is a FILESYSTEM in barebox. > > Then again, I'd like to know if your FS implementation actually needs > blocking call, and in case, where is the code supposed to block. Does > barebox have some kind of support for multiple threads, or a default > event loop where background operations can be added? Or are the FS > calls non blocking? > > Sorry for asking dumb questions, I am not a barebox developer and I am > just trying to figure out what is your execution model. There > certainly is a way to integrate my TFTP implementation as soon as I > realize what is your model: as for instance we have blocking POSIX > socket calls implemented with and without an OS infrastructure, and we > are able to realize blocking calls on any systems, being baremetal or > multithtreaded. Right now the network users register to a udp port and provide a handler which is called whenever a packet to this port is received. The prototype for this function is: struct net_connection *net_udp_new(IPaddr_t dest, uint16_t dport, rx_handler_f *handler, void *ctx); Then network users can send packets on this connection: int net_udp_send(struct net_connection *con, int len); The function returns after the packet has been sent. The network user has to keep the ball rolling by calling void net_poll(void); in a loop. This function will call into the network drivers receive function and dispatch the received packets. ARP packets are handled internally, the UDP packets are passed to the registered handlers. The handlers usually will send answers to received packets (so a tftp client will send an ack here or request the next packet). Usually the loop calling net_poll() also has some functionality to detect progress and will send the last packet again if it was lost. Hope that explains the networking model in barebox. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-07-16 6:30 ` Sascha Hauer @ 2014-07-16 6:48 ` Daniele Lacamera 2014-09-04 17:14 ` Antony Pavlov 0 siblings, 1 reply; 22+ messages in thread From: Daniele Lacamera @ 2014-07-16 6:48 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox, PicoTCP On Wed, Jul 16, 2014 at 8:30 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > Right now the network users register to a udp port and provide a handler > which is called whenever a packet to this port is received. The > prototype for this function is: > > struct net_connection *net_udp_new(IPaddr_t dest, uint16_t dport, > rx_handler_f *handler, void *ctx); > > Then network users can send packets on this connection: > > int net_udp_send(struct net_connection *con, int len); > > The function returns after the packet has been sent. > > The network user has to keep the ball rolling by calling > > void net_poll(void); > > in a loop. This function will call into the network drivers receive > function and dispatch the received packets. ARP packets are handled > internally, the UDP packets are passed to the registered handlers. > > The handlers usually will send answers to received packets (so a tftp > client will send an ack here or request the next packet). > > Usually the loop calling net_poll() also has some functionality to > detect progress and will send the last packet again if it was lost. > > Hope that explains the networking model in barebox. > Hi Sascha, Thanks a lot for this clarification. The mechanism you described is the same as the native execution model of PicoTCP, and looking around in the code it seems that looping around net_poll() was in fact the way to go. to Antony: I will improve TFTP first, by allowing multiple sessions at the same time. I will keep you posted on the progress. Thanks, /d _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-07-16 6:48 ` Daniele Lacamera @ 2014-09-04 17:14 ` Antony Pavlov 2014-09-05 7:37 ` Daniele Lacamera 2014-09-26 9:27 ` PicoTCP 0 siblings, 2 replies; 22+ messages in thread From: Antony Pavlov @ 2014-09-04 17:14 UTC (permalink / raw) To: Daniele Lacamera; +Cc: barebox, PicoTCP On Wed, 16 Jul 2014 08:48:18 +0200 Daniele Lacamera <daniele.lacamera@tass.be> wrote: > On Wed, Jul 16, 2014 at 8:30 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > > Right now the network users register to a udp port and provide a handler > > which is called whenever a packet to this port is received. The > > prototype for this function is: > > > > struct net_connection *net_udp_new(IPaddr_t dest, uint16_t dport, > > rx_handler_f *handler, void *ctx); > > > > Then network users can send packets on this connection: > > > > int net_udp_send(struct net_connection *con, int len); > > > > The function returns after the packet has been sent. > > > > The network user has to keep the ball rolling by calling > > > > void net_poll(void); > > > > in a loop. This function will call into the network drivers receive > > function and dispatch the received packets. ARP packets are handled > > internally, the UDP packets are passed to the registered handlers. > > > > The handlers usually will send answers to received packets (so a tftp > > client will send an ack here or request the next packet). > > > > Usually the loop calling net_poll() also has some functionality to > > detect progress and will send the last packet again if it was lost. > > > > Hope that explains the networking model in barebox. > > > > Hi Sascha, > > Thanks a lot for this clarification. The mechanism you described is > the same as the native execution model of PicoTCP, and looking around > in the code it seems that looping around net_poll() was in fact the > way to go. > > to Antony: I will improve TFTP first, by allowing multiple sessions at > the same time. I will keep you posted on the progress. I see a barebox-related publication with nice pictures on the picotcp website :) http://www.picotcp.com/barebox-on-top-of-picotcp We are awaiting improved TFTP... -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-09-04 17:14 ` Antony Pavlov @ 2014-09-05 7:37 ` Daniele Lacamera 2014-09-26 9:27 ` PicoTCP 1 sibling, 0 replies; 22+ messages in thread From: Daniele Lacamera @ 2014-09-05 7:37 UTC (permalink / raw) To: Antony Pavlov; +Cc: Serge Franchois, barebox, Sarah Terryn Hi Antony, hello all, It's been a bit of slow-business here lately, due to the end of the summer holidays. We have put two people on the task since this week, we will keep you posted! Thanks for bearing with us! Greetings, -- Daniele On Thu, Sep 4, 2014 at 7:14 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > On Wed, 16 Jul 2014 08:48:18 +0200 > Daniele Lacamera <daniele.lacamera@tass.be> wrote: > >> On Wed, Jul 16, 2014 at 8:30 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote: >> > Right now the network users register to a udp port and provide a handler >> > which is called whenever a packet to this port is received. The >> > prototype for this function is: >> > >> > struct net_connection *net_udp_new(IPaddr_t dest, uint16_t dport, >> > rx_handler_f *handler, void *ctx); >> > >> > Then network users can send packets on this connection: >> > >> > int net_udp_send(struct net_connection *con, int len); >> > >> > The function returns after the packet has been sent. >> > >> > The network user has to keep the ball rolling by calling >> > >> > void net_poll(void); >> > >> > in a loop. This function will call into the network drivers receive >> > function and dispatch the received packets. ARP packets are handled >> > internally, the UDP packets are passed to the registered handlers. >> > >> > The handlers usually will send answers to received packets (so a tftp >> > client will send an ack here or request the next packet). >> > >> > Usually the loop calling net_poll() also has some functionality to >> > detect progress and will send the last packet again if it was lost. >> > >> > Hope that explains the networking model in barebox. >> > >> >> Hi Sascha, >> >> Thanks a lot for this clarification. The mechanism you described is >> the same as the native execution model of PicoTCP, and looking around >> in the code it seems that looping around net_poll() was in fact the >> way to go. >> >> to Antony: I will improve TFTP first, by allowing multiple sessions at >> the same time. I will keep you posted on the progress. > > I see a barebox-related publication with nice pictures on the picotcp website :) > > http://www.picotcp.com/barebox-on-top-of-picotcp > > We are awaiting improved TFTP... > > -- > Best regards, > Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-09-04 17:14 ` Antony Pavlov 2014-09-05 7:37 ` Daniele Lacamera @ 2014-09-26 9:27 ` PicoTCP 2014-09-28 14:22 ` Antony Pavlov 1 sibling, 1 reply; 22+ messages in thread From: PicoTCP @ 2014-09-26 9:27 UTC (permalink / raw) To: Antony Pavlov; +Cc: barebox, PicoTCP, Michele Di Pede Antony Pavlov wrote: > I see a barebox-related publication with nice pictures on the picotcp website :) > > http://www.picotcp.com/barebox-on-top-of-picotcp > > We are awaiting improved TFTP... > Hi Antony, hello all. Michele just pushed a TFTP which provides support for multiple sessions. API is slightly changed, to keep track of the sessions themselves. Please refer to the example in test/examples/tftp.c, or to the updated user manual. Let us know if we can provide any support to help you progress with the integration. Regards, -- Daniele + the picoTCP team _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-09-26 9:27 ` PicoTCP @ 2014-09-28 14:22 ` Antony Pavlov 2014-09-29 9:45 ` Daniele Lacamera 0 siblings, 1 reply; 22+ messages in thread From: Antony Pavlov @ 2014-09-28 14:22 UTC (permalink / raw) To: PicoTCP; +Cc: barebox, Michele Di Pede On Fri, 26 Sep 2014 11:27:16 +0200 PicoTCP <picotcp@tass.be> wrote: > Michele just pushed a TFTP which provides support for multiple > sessions. API is slightly changed, to keep track of the sessions > themselves. Please refer to the example in test/examples/tftp.c, or to > the updated user manual. > > Let us know if we can provide any support to help you progress with > the integration. I have just pushed my latest picotcp-enabled barebox branch to github: https://github.com/frantony/barebox/tree/picotcp.20140928 (this branch contain latest barebox and latest picotcp). There are two questions. 1. Do we really need this '#ifdef PICO_SUPPORT_UDP' BEFORE (!) guard macro in pico_dhcp_client.h? https://github.com/frantony/barebox/commit/01de589b30ebca32d44efbfbdee8026a0ae09fe5 2. New pico_tftp_start_{r,t}x programming interface can be used for realization legacy standalone 'tftp' command. But I have no idea how to use this interface for filesystem-over-tftp (it's the modern barebox' tftp realization)! Barebox filesystem interface needs something like this programming interface: struct pico_tftp_session *s; s = pico_tftp_new_session_rx(addr, port, family, filename); ... filesize = pico_tftp_get_file_size(s); ... pico_tftp_receive(s, buf, len); ... pico_tftp_receive(s, buf, len); ... ... ... pico_tftp_receive(s, buf, len); ... pico_tftp_close(s); I mean that receiving process has to be controlled by barebox, not by picotcp. Because a new portion of data is received by filesystem user initiative, not by network stack initiative. Sascha! Please comment this problem. -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-09-28 14:22 ` Antony Pavlov @ 2014-09-29 9:45 ` Daniele Lacamera 2014-09-29 10:10 ` Michele Di Pede 2014-09-29 10:19 ` Antony Pavlov 0 siblings, 2 replies; 22+ messages in thread From: Daniele Lacamera @ 2014-09-29 9:45 UTC (permalink / raw) To: Antony Pavlov; +Cc: barebox, Michele Di Pede On Sun, Sep 28, 2014 at 4:22 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > > 1. Do we really need this '#ifdef PICO_SUPPORT_UDP' BEFORE (!) > guard macro in pico_dhcp_client.h? > I moved these in latest PicoTCP commit. Thanks. > 2. New pico_tftp_start_{r,t}x programming interface can be used for > realization legacy standalone 'tftp' command. > But I have no idea how to use this interface for filesystem-over-tftp > (it's the modern barebox' tftp realization)! > > Barebox filesystem interface needs something like this programming > interface: > > struct pico_tftp_session *s; > > s = pico_tftp_new_session_rx(addr, port, family, filename); > ... > filesize = pico_tftp_get_file_size(s); > ... > pico_tftp_receive(s, buf, len); > ... > pico_tftp_receive(s, buf, len); > ... ... ... > pico_tftp_receive(s, buf, len); > ... > pico_tftp_close(s); > > > I mean that receiving process has to be controlled by barebox, > not by picotcp. Because a new portion of data is received > by filesystem user initiative, not by network stack initiative. Thanks for the comments. A few from my side: - pico_tftp_receive is non-blocking, and will return immediately if no data is available. You always have to be bound to some RX event to be sure that your next receive() call is successful, so in some way you still want it network-bound. - We can implement the get_file_size, but not all servers will support it. Michele has a strategy for developing more advanced TFTP features, he will post on it later regards, /d _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-09-29 9:45 ` Daniele Lacamera @ 2014-09-29 10:10 ` Michele Di Pede 2014-09-29 10:19 ` Antony Pavlov 1 sibling, 0 replies; 22+ messages in thread From: Michele Di Pede @ 2014-09-29 10:10 UTC (permalink / raw) To: Daniele Lacamera; +Cc: barebox On Mon, Sep 29, 2014 at 11:45 AM, Daniele Lacamera <daniele.lacamera@tass.be> wrote: > On Sun, Sep 28, 2014 at 4:22 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: >> >> 1. Do we really need this '#ifdef PICO_SUPPORT_UDP' BEFORE (!) >> guard macro in pico_dhcp_client.h? >> > > I moved these in latest PicoTCP commit. Thanks. > > >> 2. New pico_tftp_start_{r,t}x programming interface can be used for >> realization legacy standalone 'tftp' command. >> But I have no idea how to use this interface for filesystem-over-tftp >> (it's the modern barebox' tftp realization)! >> >> Barebox filesystem interface needs something like this programming >> interface: >> >> struct pico_tftp_session *s; >> >> s = pico_tftp_new_session_rx(addr, port, family, filename); >> ... >> filesize = pico_tftp_get_file_size(s); >> ... >> pico_tftp_receive(s, buf, len); >> ... >> pico_tftp_receive(s, buf, len); >> ... ... ... >> pico_tftp_receive(s, buf, len); >> ... >> pico_tftp_close(s); >> >> >> I mean that receiving process has to be controlled by barebox, >> not by picotcp. Because a new portion of data is received >> by filesystem user initiative, not by network stack initiative. > > Thanks for the comments. A few from my side: > > - pico_tftp_receive is non-blocking, and will return immediately if no > data is available. You always have to be bound to some RX event to be > sure that your next receive() call is successful, so in some way you > still want it network-bound. I'll modify the API in order to add this capability, the application will be responsible to sending ACK message as soon as possible (it will be wrapped into the new applications API we will provide. > - We can implement the get_file_size, but not all servers will support > it. Michele has a strategy for developing more advanced TFTP features, > he will post on it later > TFTP version 2 (RFC 1350) handles only simple GET and PUT requests. Query for file size is not there, it's stated in RFC 2359 as an OPTIONAL feature; this means that his support is not guaranteed by all servers. We currently support only RFC 1350 but we plan to add support for RFC 2359 soon. I've just added two new feature request on our issue tracker. In meanwhile please try if you can use the current API as suggested in the example file test/examples/tftp.c > regards, Best regards Michele _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: picotcp tftp support [was Adding IPv4 multicast support] 2014-09-29 9:45 ` Daniele Lacamera 2014-09-29 10:10 ` Michele Di Pede @ 2014-09-29 10:19 ` Antony Pavlov 1 sibling, 0 replies; 22+ messages in thread From: Antony Pavlov @ 2014-09-29 10:19 UTC (permalink / raw) To: Daniele Lacamera; +Cc: barebox, Michele Di Pede On Mon, 29 Sep 2014 11:45:08 +0200 Daniele Lacamera <daniele.lacamera@tass.be> wrote: > On Sun, Sep 28, 2014 at 4:22 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote: > > > > 1. Do we really need this '#ifdef PICO_SUPPORT_UDP' BEFORE (!) > > guard macro in pico_dhcp_client.h? > > > > I moved these in latest PicoTCP commit. Thanks. > > > > 2. New pico_tftp_start_{r,t}x programming interface can be used for > > realization legacy standalone 'tftp' command. > > But I have no idea how to use this interface for filesystem-over-tftp > > (it's the modern barebox' tftp realization)! > > > > Barebox filesystem interface needs something like this programming > > interface: > > > > struct pico_tftp_session *s; > > > > s = pico_tftp_new_session_rx(addr, port, family, filename); > > ... > > filesize = pico_tftp_get_file_size(s); > > ... > > pico_tftp_receive(s, buf, len); > > ... > > pico_tftp_receive(s, buf, len); > > ... ... ... > > pico_tftp_receive(s, buf, len); > > ... > > pico_tftp_close(s); > > > > > > I mean that receiving process has to be controlled by barebox, > > not by picotcp. Because a new portion of data is received > > by filesystem user initiative, not by network stack initiative. > > Thanks for the comments. A few from my side: > > - pico_tftp_receive is non-blocking, and will return immediately if no > data is available. You always have to be bound to some RX event to be > sure that your next receive() call is successful, so in some way you > still want it network-bound. > > - We can implement the get_file_size, but not all servers will support > it. Michele has a strategy for developing more advanced TFTP features, > he will post on it later I want just to say that barebox tries to get file size if it's possible. Please see tftp_parse_oack() function in fs/tftp.c: if (!strcmp(opt, "tsize")) priv->filesize = simple_strtoul(val, NULL, 10); This priv->filesize is used in tftp filesystem stat() call realization. So it's reasonable to give barebox a means to set priv->filesize after switching to picotcp. -- Best regards, Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Adding IPv4 multicast support 2014-07-13 14:28 ` Daniele Lacamera 2014-07-15 7:01 ` picotcp tftp support [was Adding IPv4 multicast support] Antony Pavlov @ 2014-07-15 18:17 ` Colin Leitner 1 sibling, 0 replies; 22+ messages in thread From: Colin Leitner @ 2014-07-15 18:17 UTC (permalink / raw) To: Daniele Lacamera, Antony Pavlov; +Cc: Colin Leitner, PicoTCP, barebox > What would you need for "network discovery"? Currently picotcp > - mDNS (at the moment over v4 only) That's what you want (with DNS-SD over mDNS). Sounds great and would save me lots of work :) Thanks for your effort! -Colin _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2014-09-29 10:19 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-07-13 10:11 Adding IPv4 multicast support Colin Leitner 2014-07-13 10:55 ` Antony Pavlov 2014-07-13 10:52 ` Colin Leitner 2014-07-13 13:15 ` Colin Leitner 2014-07-13 14:28 ` Daniele Lacamera 2014-07-15 7:01 ` picotcp tftp support [was Adding IPv4 multicast support] Antony Pavlov 2014-07-15 9:31 ` Daniele Lacamera 2014-07-15 10:27 ` Antony Pavlov 2014-07-15 10:57 ` Daniele Lacamera 2014-07-15 12:57 ` Antony Pavlov 2014-07-15 15:55 ` Daniele Lacamera 2014-07-15 19:02 ` Antony Pavlov 2014-07-16 6:30 ` Sascha Hauer 2014-07-16 6:48 ` Daniele Lacamera 2014-09-04 17:14 ` Antony Pavlov 2014-09-05 7:37 ` Daniele Lacamera 2014-09-26 9:27 ` PicoTCP 2014-09-28 14:22 ` Antony Pavlov 2014-09-29 9:45 ` Daniele Lacamera 2014-09-29 10:10 ` Michele Di Pede 2014-09-29 10:19 ` Antony Pavlov 2014-07-15 18:17 ` Adding IPv4 multicast support Colin Leitner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.