[WLANware] SNMP plugin for OSLR - GSoC 2011

[ambarisha b]

Hi,
I was very busy with a presentation last couple of days, so I couldn't
be in touch.Still, I have some work to report.

On Thu, Mar 24, 2011 at 4:11 PM, Mitar <mmitar at gmail.com> wrote:
> uIP does not need to be ported to any platform, because we will port
> it to "libpcap" platform. This will be the platform (network
> interface) from its point of view. libpcap is suppoorted on many
> UNIX-based systems (including Mac OS X) and also Windows. So we are
> covering majority of platforms in this way. winpcap is compatibile
> with libpcap. This is not a big problem.

Very clearly put.Now we have some new issues to worry about.Marek was
mentioning some problems they had with the 64bit build of
libpcap.Marek,can you please describe the problems and anything we can
do about it?

> OK. If you really want to pursue this than I would recommend that you
> start by looking at this code:
>
> http://dev.wlan-si.net/browser/imageflasher
>
> You should make it compile and run. You should familiarize yourself
> with cmake. So to compile you need Qt, obviously, and then run:
>
> mkdir build
> cd build
> cmake ../
>
> Or something like this. ;-)
> This should show you how we imagined GUI. So flashing steps will be
> defined as a graph moving from one node to another, in the case of GUI
> each node will have its window.
No worries,I got that.Its looking good.And quoting from the code
(main.cpp line:36):
  <code >progress->appendTerminalOutput("bash$ rm -rf /\nRemoving all
files ... \nBye :D");</code>
Nice touch!!

> Then there was my initial work uipcap library. This is the idea of
> having a stand-alone TCP/IP library over libpcap. Cross-platform. So
> that from then one you can ignore platforms. Check it out. Currently
> it does not do much. It tries to find information about all network
> interfaces in cross-platform manner. And it tries to compile against
> libpcap or winpcap and so on. So that we know that initial things
> work. And then we would start real interaction with uIP.

Great ,I am still going through the code,now.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.The
following is an extract from a document I read:

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.

Is this a problem?If so,we can try hacking into uIP and fixing this.We
wouldn't even have a problem with the license.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.

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 was thinking of
making the official submission by 5th.What should I put in the
technical description of the project.This is what I was thinking of:

1.Completing the work on porting uIP to libpcap.
2.Getting the entire backend script ready.
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.

What do you think? What do you suggest I put in the proposal?
Please,inform if there are any specific things you would like to(or
not like to) see in the proposal?

Cheers
Ambarish