apexys / avr-uip Goto Github PK

Hi, i am looking for simple tcp/ip client implementation. There are a lot of 
webservers and not less webclients but simple tcp/ip client, which can connect 
to tcp/ip server and comunicate. Is it possible to implement it to avr-uip?

Thanks a lot.

The default r152 network.c function network_read() does not check the buffer 
overflow, so if packet larger than UIP_BUFSIZE is sent to device, it will 
overwrite the device memory.

The simple (perhaps not too elegant) fix can be as following:

unsigned int
network_read(void) {
    uint16_t len, totallen;
    char dummy[1];
    int i;

    len = ksz8851BeginPacketRetrieve();
    totallen = len;

    if (len == 0) {
        return 0;
    }

    // Avoid SCADA attack - do not overflow
    if (len > UIP_BUFSIZE)
        len = UIP_BUFSIZE;

    ksz8851RetrievePacketData((uint8_t *)uip_buf, len);

    // fetch reminder of the data to prevent stalling
    for (i=len; i<totallen; i++)
        ksz8851RetrievePacketData((uint8_t *)dummy, 1);

    ksz8851EndPacketRetrieve();

    return len;
}

What steps will reproduce the problem?
1. use an existing project, tuxgraphics will do
2. create a subfolder for the project.
mkdir -p projects/TuxGraphics/test
3. put a source file into it and include this source file into the makefile:
$(NAME)_SOURCES = main.c clock-arch.c test/test.c

What is the expected output? What do you see instead?
expected output would be that it compiles flawlessly. but make produces an 
error:
Assembler messages:
Fatal error: can't create obj/test/test.o: No such file or directory

What version of the product are you using? On what operating system?
current svn. ubuntu 10.04.1 lts

Please provide any additional information below.
A Workaround is to create these folder per hand like:
cd projects/TuxGraphics
make
# error here
mkdir -p obj/test
make
# builds fine

What steps will reproduce the problem?
1. Create a program with webclient
2. Check your memory usage
3. Recoil in horror

Created a web client that uses PROGMEM.  See attached.

Halfmoon project MAC appears to hand even with full duplex form time to time.
So, this is a different issue or the chip really isn't in full duplex mode.

Error of definition between .c and header for timer32_set:
 * void timer32_set(struct timer32 *t, clock_time_t interval) in .h
 * void timer32_set(struct timer32 *t, clock_time32_t interval) in .c (good)

clock_time32() is not define (need a new file clock32.h ? add it in 
clock-arch.h ?)

timer_expired return an int, timer32_expired a bool:
 * consistency error
 * stdbool.h is not include in timer32.c

and last but not least the type of clock_time_t is defined in clock-arch.h and 
can be easily defined as a uint32_t, don't know if really necessary to do a 
"timer32" library.

It is mentioned in net_conf.c some place, that network_set_MAC() does not work 
properly, while, in fact, seems to behave properly. 

The bug why network_get_MAC() reports the mac address wrong is, that the last 
read does not store the value to temp variable.

... 
    /* Read QMU MAC address (high) */
    temp = ksz8851_regrd(REG_MAC_ADDR_45);
    ^^^^^^^^ missing
    macaddr[1] = temp & 0xff;
    macaddr[0] = temp >>  8;
}

The EEPROM-less configuration therefore seems to work.

...

Line no 59.
"if(c == '.' || c == 0) {"

'0' should be a Null char(string termination)
"if(c == '.' || c == '\0') {"

What steps will reproduce the problem?
Problem may occur randomly depending on firmware code with low probability. No 
steps to reproduce. 

What is the expected output? What do you see instead?
When using uip_send_P if data has the same address in PROGMEM as uip_sappdata 
in SRAM, data from SRAM will be sent instead of data from PROGMEM.

What version of the product are you using? On what operating system?
SVN trunk rev.243

Please provide any additional information below.
Patch to resolve this issue attached.

What steps will reproduce the problem?
1. build the firmware 
2. start wireshark
3. load a http page lots of times and check the logs.  After a while you will 
see

1801    924.830456  192.168.2.110   192.168.2.107   TCP http > 59410 [ACK] Seq=1 
Ack=394 Win=546 Len=0

1802    924.830480  192.168.2.107   192.168.2.110   TCP [TCP Dup ACK 1800#1] 59410 > 
http [ACK] Seq=394 Ack=547 Win=6552 Len=0

1803    925.035373  192.168.2.107   192.168.2.110   HTTP    [TCP Retransmission] 
Continuation or non-HTTP traffic

1804    925.036834  192.168.2.110   192.168.2.107   TCP [TCP Dup ACK 1801#1] http > 
59410 [ACK] Seq=547 Ack=394 Win=546 Len=0

>>>>>>
Note the "Continuation or non-HTTP traffic" this is because the amount of data 
being sent is larger than one http packet size as I learned from:
http://www.gossamer-threads.com/lists/ethereal/users/68274


When this error occurs the UIP stack dies for a few moments while it figures 
out what to do... :-p  Well I think it's waiting on a timeout and performs a 
cleanup.

Provide a common network settings page.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Implement a basic user auth system

No ssl on the device so a basic auth at start of use.
Then pass the client the auth token.
Somehow include the client ip and perhaps port as part of the client auth toke 
so the token can be checked.
With this add logout and login support.
If auth is on replace index page with login page.
Add simple way to include auth check via compile time flag.

The new drop of the enc28j60 driver from tux graphics ONLY appears to work with 
the Halfmoon_Tech.1284 project.

Need to look into why.

I use atmel128A + ksz8851snl + uip stack.

TCP transport works very well.

Received during the operation is to stop.

I have every 100ms packet size because it is about 400 bytes.

It stops when it receives a packet of 6-8.

How do you solve?

So, the issue is this.

avr-uip is a tiny tiny device.
the web browser talking to it is giant.

The giant shouts so loud that it have to send two IP packets for a single 
sentence.  Chrome and Firefox BOTH do this on my desktop from time to time.  
When requesting a web page.  So, for these requests to work we need to 
re-assemble the IP packets.  The code to do this appears to be broken at this 
time.

So, this bug is to FIX IT!

wget of a page btw does NOT cause an issue.  The web browsers are telling our 
little UIP dev ALL of the things they understand during the http get request.  
It's just too much so it is split into two packets. :-\

Once the UIP stack IP re-assembly code is fixed.  The RAM requirement will 
double for your UIP_CONF_BUFFER_SIZE

If you want to talk with a modern web browser it's going to be a fact of life.

Implement support for ntp.

This is just a note that the resolv app does not clean up old entries.

So, if you post a query and it fails.  The failure will not be cleaned up.  The 
slot in the resolv name list will be held until you reset your board.

This case will happen if you have a network issue while your device is trying 
to resolve a host name.  If your device is powered on and fails the number of 
times you have slot then your device will NEVER resolve the host name as the 
queue will be full.

This is a nasty bug for those who use the resolv app... why is it spelled wrong 
in the tree.. oh well.

The webserver works normal without post / get param support.
when turned on some of the pages which do NOT use param will crash the 
webserver at times

What steps will reproduce the problem?
1. ported code to msp430F2618
2. received arp request when it send out the respond
3. it sends one packet follow by garbage 5 that have packet size of 1369

What is the expected output? What do you see instead?
Expecting only one packet send out and no garbage send by the chip.

What version of the product are you using? On what operating system?
the chip version I think is 0 and operating system is polling mode.

Please provide any additional information below.

this goes with the gzip html format support

The default initialization code for KSZ8851SNL chip checks for the fixed chip 
ID defined by CHIP_ID_8851_16 (0x8870).

This is incorrect, as the CIDER registry defines lower bits [3..1] as revision 
number what may change (It is actually 0x8872 currently).

Please change the init code references to chip ID as following:

...

if ((dev_id & 0xFFF0) == CHIP_ID_8851_16) 

...

Fix attached.

Over time should a resolved host name be timed out so that the host name will 
be looked up again?

I'm thinking along the lines of when a host name is something like

myhost.dyndns.org 

where the IP of the host may change over time. 

The timezone is hard coded.  It should be an option you can set at runtime.

What steps will reproduce the problem?
1.
2.
3.fdf

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

dfdf