[WLANware] SNMP plugin for OSLR - GSoC 2011

[Mitar]

Hi!

On Tue, Mar 29, 2011 at 9:32 AM, ambarisha b <b.ambarisha at gmail.com> wrote:
> I have a concern
> though.I'll put down the reasons I was a bit hesitant about uIP,
> earlier.From what I have read,uIP supports only one outstanding ACK
> for each tcp session.That means you cannot send the next tcp segment
> till you have recieved the ACK or you timeout.So,we will be giving up
> a lot of synchronous transmission.Further ,uIP can handle multiple tcp
> sessions but the performance will be degraded considerably.

I am hesitant about writing our own TCP implementation. I am not sure
if this is not too much work? I do not believe this is so easy task.
So maybe using something existing and at least improving it would be a
better choice? Marek, you believe writing your own TCP implementation
is a wise move?

I am not so sure if we really need high performance? I mean, we mostly
just need to transmit one file.

> If the (uIP)buffers are full, the incoming packet is dropped. This
> will cause performance degradation, but only when multiple connections
> are running in parallel. This is because uIP advertises a very small
> receiver window, which means that only a single TCP segment will be in
> the network per connection.

You should not forget that uIP is targeted primarily for very low-end
and low-resource platforms. If we are running it on PCs (or even our
routers) we can increase those limits and also probably CPU will
manage to process things fast enough.

> The idea of porting uIP
> to libpcap is a novel one.I can see a lot of uses for this.So, I
> thought we should not compromise with the implementation.But, is it
> necessary? Its your call.

I think it would be very useful to have a separate TCP/IP
high-performance, stable and portable library based on libpcap and/or
raw sockets (where available). So I am not sure if we really need
libpcap on all platforms (raw sockets are probably enough). And I am
not sure if uIP is the right choice. But this are implementation
details. What I know that something like this would be useful. So we
could even use Marek's work and build upon it.

And then upon that as an example put different other layers
(protocols/applications). And then use that in flasher app.

> The student application period has begun.So, I think its time I put
> pen to paper.I am planning to complete the draft by 3rd and post it to
> you people so that I still have time to make changes and also I don't
> want to distract you right before the deadline.

I doubt we will have to time to check your draft. Also it is
impossible to check it if all students would do that. I also believe
it is a good test of your capabilities of individual work. We have
discussed much. Now you have to do some research and decide for
something. Write pros/cons for what you decide and put references to
your arguments (articles, tests, libraries you found).

If you will be accepted there will much much more time to discuss then
concrete details and really get into the sync what we would like. Now
it is time for you to do your home-work, research things, propose that
and convince us that you understand the idea and that you will be able
to code it.

There would not be much use of your proposal for our student selection
if we would work together on it. We want you to work on it so that we
can evaluate you. ;-)

> 1.Completing the work on porting uIP to libpcap.

Or some other library. Or combination of libpcap (on Windows, or is
there some other way there) and raw sockets. In general: make and
independent UDP/TCP/IP library (re)using or not existing things. (You
should research this and find the best way.)

> 2.Getting the entire backend script ready.

Script?

> 3.Testing the script on various platform(here I mean to fix any
> issues,if we have any, with winpcap)
> 3.Integrating that with the GUI
> 4.Test the flasher GUI on various platforms
> 5.Adding support for flashing new routers.

I think we should make this system modular. So there would be more modules:

- UDP/TCP/IP library
- protocols above it (TFTP, HTTP, telnet, SSH)
- definition of necessary steps for flashing a device (so easy adding
of new routers), with example of common ones (Linksys, Fonera)
- GUI library (terminal (dialog/ncurses/text) and Qt)

It would be great imagine this as a generic open-source flashing tools
for various devices. Not just our routers, but maybe someday also
mobile phones and so on. Everything OpenWrt might support. Or also
some other projects (OpenMoko and Android comes to mind).


Mitar