Re: [lwip-users] Router issues with lwip

[Leon Woestenberg]

Hello all,

K.J. Mansley wrote:
> On Tue, 2004-06-22 at 06:20, Martin Glunz wrote:
>
> > "K.J. Mansley" wrote:
> >
> > > > I've done a simple (and obvious) workaround:
> > > That's a rather hacky solution, and I'm not convinced that it is correct
> > > to send a RST with an out-of-window sequence number.  Can you provide a
> >
> > I totally agree that this a quick and dirty hack, but I needed to get
> > the device to work ...
> >
> > OK, here's the tcpdump:
> As I understand there seems to be two problems here:
>
> 1) The missed FIN
>
> 2) The missed RST
>
> With the latter, it seems odd to me that the sequence number of the RST
> is the same as that of the FIN.  As I understand TCP, SYN and FIN
> packets increment the sequence number, so you would expect the RST to
> have (in your trace) a sequence number of 3780613832 rather than
> 3780613831.  Does anyone else have any thoughts on this?  
Yes, SYN and FIN are the two control sequences that get accounted to 
bump the sequence number. I found this second paragraph from RFC793
rather interesting, as it explains how to interpret SYN and FIN in this
regard. At least the fact that the order is important was new to me.

  "Control information is not physically
  carried in the segment data space.  Consequently, we must adopt rules
  for implicitly assigning sequence numbers to control.  The SYN and FIN
  are the only controls requiring this protection, and these controls
  are used only at connection opening and closing."

  "For sequence number
  purposes, the SYN is considered to occur before the first actual data
  octet of the segment in which it occurs, while the FIN is considered
  to occur after the last actual data octet in a segment in which it
  occurs.  The segment length (SEG.LEN) includes both data and sequence
  space occupying controls.  When a SYN is present then SEG.SEQ is the
  sequence number of the SYN."

Regards,

Leon.