==================
From: Raimondas Sasnauskas <raimondas.sasnauskas@cs.rwth-aachen.de>
Date: Sun, Sep 20, 2009 at 1:29 PM
Subject: Re: RE: Re: RE: Re: Re: RE: Bug (?) in uip TCP/IP stack: lost SYNACK causes connection reset
OK, here I'm proposing the following patch (see git diff attached).
Again the problem we face here is the subsequent SYN arriving in
UIP_SYN_RCVD state after the SYNACK packet was lost. First, to avoid
other issues, suggest to reset any _active_ connection where a SYN
arrives in a state != UIP_SYN_RCVD.
==================
This is a combination of the patch submitted by Raimondas Sasnauskas and
the patch applied by Oliver Schmidt to Contiki
===================
Original bug report
===================
From: Raimondas Sasnauskas
<raimondas.sasnauskas@cs.rwth-aachen.de>
Subject: Bug (?) in uip TCP/IP stack: lost SYNACK causes
connection reset
Date: 2009-09-02 19:07:51 GMT
Hi all,
I've found the following issue in the TCP (UIP_ACTIVE_OPEN)
connection establishment phase leading to connection failure.
This happens whe the SYNACK packet gets lost during the TCP
3-way handshake.
Client: SYN
Server: SYNACK (this packet gets lost)
Client: SYN (retransmission)
Server: ACK (<-- server thinks it's data?)
Client: RESET (correct, no SYNACK received yet)
Server: ABORT (got reset, aborting connection)
I do not have a patch/workaround yet, but I think that
correctly handling incoming TCP_SYN packets in UIP_SYN_RCVD
state would fix this issue.
http://article.gmane.org/gmane.network.uip.user/1506
Here's the content of the patch (so it can be more easily
discussed if need be). What basically happens is uip_len and
uip_slen never get reset to 0 when calling the poll handler.
Here's an example of how things go wrong:
Let's say you get some new incoming data (uip_newdata()), your
application handler processes the new data and sends something
out (thus setting uip_slen). Back in the main loop again, you
poll a connection. uip_slen is still set from the last send and
if your poll handler doesn't send out something new, uip ends up
just sending out the exact same data on the now polled
connection. In every other applicable case, uip_len and
uip_slen get reset, but for whatever reason this one just got
missed...
http://article.gmane.org/gmane.network.uip.user/1312
I have been working on implementing a port to the atmel
ATMega128 and I have noticed that sending UDP packets does not
work (the transferred data is always 0).
A look into the code reveals that in uip.c, the address of
uip_appdata gets set incorrectly.
Somewhere around line 1159 the code needs to be changed:
--- uip_appdata = &uip_buf[UIP_LLH_LEN + UIP_IPTCPH_LEN];
+++ uip_appdata = &uip_buf[UIP_LLH_LEN + UIP_IPUDPH_LEN];
http://article.gmane.org/gmane.network.uip.user/68
i just saw that the stats taking in uip is missing entries for udp
receive and
transmit.
To fix this insert a UIP_STAT after the udp_found label:
udp_found:
+ UIP_STAT(++uip_stat.udp.recv);
And a UIP_STAT before the goto ip_send_nolen instruction:
+ UIP_STAT(++uip_stat.udp.sent);
goto ip_send_nolen;
The separate dependency generation step from the Lua build system
was not needed, now the dependencies are generated at the same time
as the object files.
The new LCD firmware doesn't need the caller to wait after each command:
it stretches the clock instead. Actually, it works at 68kHz too, but
there is a non-working range from 55 to 66kHz.
We set it to 50000Hz to have reliable operation and allow for clock drift.
We just changed LCD command 0 from a no-op to a speciall-recognized
hardware reset. This is essential because the LCD controller's reset line
is not connected to the AVR32's reset line, so if the AVR32 is reset,
the LCD is left in an unknown, possible unusable, state.
The old slave addresses, F2, F3, F6, F7 are reserved for 10-bit
I2C addressing. This changes them to values that are least likely
to conflist with other devices: 7C-7F are registered to two LCD display
devices.
In integer math, floor() and ceil() give the same value, but
having them included in the integer library as functions that return
their argument allows you more easily to write code that works unchanged
in both integer and floating point versions of Lua.
The code for the bitbanger, taken from wikipedia, in turn taken from
http://www.nctutwt.net/wiki/doku.php?id=wiki:summer2010:i2c
does a STOP condition by raising SCL and immediately raising SDA, but
in the I2C spec, there is a minimum STOP setup time of 4ms between these
transitions (I2C spec, doc UM10204, table 6/figure 27, pp.37-38).
Similarly, a repeated START has a setup time of minimum 4.7us between
SCL going high and SDA going low, which the code did not contain.
This patch inserts these delays to conform better to the I2C spec,
even though all tested devices "seemed to work" without them.
platform_pwm_op( id, op, data ) did four unrelated tasks, switching on the
"op" parameter:
op==PLATFORM_PWM_OP_SET_CLOCK took a frequency and returned a frequency
op==PLATFORM_PWM_OP_GET_CLOCK took nothing returned a frequency
op==PLATFORM_PWM_OP_START and _STOP both took nothing and returned nothing
this patch replaces it with:
clock = platform_pwm_set_clock( id, clock)
clock = platform_pwm_get_clock( id )
platform_pwm_start( id ) and
platform_pwm_stop( id )
with resulting clarity in the documentation and smaller, faster code.
This does not affect the Lau interface.
Previously, you called platform_adc_op(id, OPERATION, u32 arg) to achieve
six unrelated functions with different arg types and return values:
GET_MAXVAL takes nothing and returns an ADC conversion value
SET_SMOOTHING takes a power-of-two filter length and returns nothing
SET_BLOCKING takes a boolean and returns nothing
IS_DONE takes nothing and returns a boolean
SET_TIMER takes a timer ID and returns nothing
SET_CLOCK takes a frequency in Hz and returns a frequency in Hz.
This changes these to six independent functions, each with the right
parameters and return values.
This also makes the documentation more comprehensible, saves 26 bytes of
executable code and should be very slightly faster.
Three modules had a bogus luaopen_disp() function that was never called.
In reality, each platform.c only uses the extern disp_map[] (or str9_pio_map[])
and does the right thing with it in luaopen_platform().
This also removes a bug (AUXLIB_DISP undefined), which prevented avr32
and str9 from compiling when optram=0
Previously, with i2c.write(id, "123"), lua_isnumber would react to the numeric
string and greedily convert it to a single character '{', which made printing
digits to an I2C LCD display almost impossible.
