[WLANware] SNMP plugin for OSLR - GSoC 2011

[Mitar]

Hi!

On Wed, Mar 23, 2011 at 10:20 PM, ambarisha b <b.ambarisha at gmail.com> wrote:
> 1. Presently its just for Linux.(Socket functions like socket_open are
> problem)Our complete app would be cross platform.

Socket functions should be written over the internal TCP/IP
implementation (uIP based on tcpdump). The idea is that user does not
need to reconfigure its network interface (as this is not easy done
and it can break their connection to the Internet (you cannot
multitask)) but that we sniff all data with tcpdump and then emulate
TCP/IP stack over it. And also send raw packets we build ourselves.
The other positive side-effect of this is also that we can inject
special/nonstandard packets which are sometimes necessary to flash
some routers.

What would be useful is to make such library a generic library so that
also other programs might use it later. Not just this GUI flasher.

> 2. The protocol headers up the stack , arp , ip , tcp/udp are parsed
> by the functions handle_***_packet() calls except for udp which also
> handles the actual flashing(it would have been better if this were a
> separate function).One thing in handle_udp_packet() that struck me was
> that all the attributes that indicate that a block has been
> transferred are being set before the tftp_packet_send_data()
> call.If that call returns a '<0' these aren't being reverted
> back.tftp_packet_send_data() also
> doesn't seem to be cleaning it up.Is this a bug or did I miss something ?

I would restructure all this network stack into layers.

> 3. We should make the implementation of the network stack more
> robust.(Ofcourse I can see that this was just a mockup but I just want
> to make note of the point).Is there a specific reason for going with
> the uIP stack? I know its quite small, but can you please elaborate on
> the choice ?

Read above.

> 4. Coming to the GUI of the flasher, I agree the process should be
> made as simple as possible.I listed down the main things that are to
> be presented on the front end.
>    --> Firmware image( A file chooser to select the image)
>    --> Network interface information (This has to be easy to fill out)

No, this should be automatically done. We do not want any technical
data necessary (but of course for power users we might give them also
this, if they want it).

>    --> A progress bar that indicates the transfer of the image to the
> router(I guess this is going to be pretty quick but may be we could
> embed the gap that we give the router to install the image into this
> so that user needn't consider it explicitly)
> What else would the frontend involve ?

Some routers have more complex flashing (like telneting to some port
and issuing multiple commands which formats flash, transfers image,
flashes the image). So some way of displaying to the user what is
going on would be necessary. So some read-only terminal display.

> 5. There are also some TODO's commented out in the code that are worth
> some attention.

ap-51 tool is a flash tool I would use as as example, not directly
build on it. Probably rent some code, but refactor/redo it at the same
time, do things more modular and so on.

> 6. There are other things that I haven't properly researched properly
> in our context like SSH.We also need to implement the HTTP protocol
> support for flashing.

Yes.

> Is there a possibility of trying to flash a wrong image that might
> brick the router? If so, should we add any functionality to help avoid
> such mistakes ? Any corrections or improvements would be really
> helpful.If everything works out well, I was planning to make visual
> mock-ups of the application.What do you say?

Yes, yes. Virtual mockups are not necessary at this moment. We also
have the GUI quite ready in this sense (using Qt). This part is done.
What would be necessary first is to make the internal things working.
Then above that GUI (which means both Qt and console/terminal
version).


Mitar