[lwip-users] Re: tcp_data packets

[Jonathan Larmour]

I think you could be more helpful in explaining the problem. I couldn't
even interpret your packet trace until I determined that the first two
bytes are some higher layer stuff. People here try to help, we aren't here
to do your work for you.

At this point you haven't said why you would want to "change the sequence
number" - but I believe if that's what you think the answer is, then I
would guess that what you are thinking the problem is is mistaken. By the
way, you do know that TCP sequence/ack numbers are _meant_ to be 32-bits?

I think a) you could do with using some better analysis program on your
host, or by enabling the TCP debug options in LWIP (by doing:
#define TCP_DEBUG DBG_ON
in lwipopts.h).

b) first reading and analysing the output yourself;

c) If that doesn't help, then send it to us, or since it will probably be
quite large, upload it somewhere (e.g. http://pastebin.ca ) and point us at
it. And say what exactly is going wrong and where, rather than what you
think the solution is.

d) answering the questions we've already asked.

Jifl

address@hidden wrote:
> let me to go briefly
>        First for TCP the connect -accept-acknowledge must be done.Client code 
> starts to send connect packet,LWIP code will send Accept packet,I have a 
> doubt about sequence number and acknowledge number calculation in the LWIP 
> code.
>      Each time the value of sequence number for accept packet is 
> 0000196e(relative for 00 00 00 00),is there a possibility to change this 
> number,the packets are below.
> 
> connect packet from client 
> 7E 21 45 00 00 30 6A 79 40 00 80 06 46 EE C0 A8  
>  64 07 C0 A8 64 08 1F 40 1F 40 C0 1F B4 9A 00 00  
>  00 00 70 02 20 00 66 84 00 00 02 04 05 B4 01 01   
>  04 02 13 74 7E                                         
> 
> accept packet from LWIP
> Answer: 1/10/2008 1:38:26 PM.69764 (+0.5469 seconds)
> 
>  7E 21 45 00 00 2C 00 00 40 00 FF 06 32 6B C0 A8  
>  64 08 C0 A8 64 07 1F 40 1F 40 00 00 19 6E C0 1F   
>  B4 9B 60 12 20 00 62 0C 00 00 02 04 05 B4 3E 7D   
>  5E 7E
>                                                       
> acknowledge packet from client 
> Request: 1/10/2008 1:38:26 PM.71364 (+0.0156 seconds)
> 
>  7E 21 45 00 00 28 6A 7A 40 00 80 06 46 F5 C0 A8   
>  64 07 C0 A8 64 08 1F 40 1F 40 C0 1F B4 9B 00 00   
>  19 6F 50 10 22 38 77 91 00 00 1B 37 7E   
> 
> after this packet the LWIP code  will send data packets(size 400)
> and client code will acknowledge by adding size 400 as follows,sample
> 
> data packet
> 7E 21 45 00 01 B8 00 00 40 00 FF 06 30 DF C0 A8   
>  64 08 C0 A8 64 07 1F 40 1F 40 00 00 19 6F C0 1F   
>  B4 9B 50 18 20 00 3D B9 00 00 00 00 00 00 C0 A8   
>  64 08 FF FF FF 00 C0 A8 64 07 10 00 00 00 AE 0F   
>  81 01 
> 
> acknowledge for the above packet
> 
> 00 00 19 6f + 190(400) =00 00 1a ff
> 7E 21 45 00 00 28 6A 7B 40 00 80 06 46 F4 C0 A8   
>  64 07 C0 A8 64 08 1F 40 1F 40 C0 1F B4 9B 00 00   
>  1A FF 50 10 20 A8 77 91 00 00 7A BA 7E    
> 
> like wise this will go for further packets.Is there any possiblity to change 
> initial value for seq and ack number
> 
> 
>          
> 
> Jonathan Larmour wrote:
>> ramash wrote:
>>> Hi all,
>>>     I have been using lwip code to send TCP packets to a client program
>>> through serial port.
>>>     I am facing the problem that sequence number becomes five bytes 
>>>     Initially for TCP packets client send connect packet and server will
>>> send accept packet by taking sequence number as acknowledge number and
>>> acknowledge number as sequence number,and it is follow on all the
>>> packets.
>>>
>>>     First the acknowledge number send by acknowledge packet for accept
>>> packet is 0x0000196f,after the first data packet send (400 bytes size)the
>>> acknowledge number(0x00001964 + 190(400) = 0x00001aff).this will go on
>>> for
>>> further packet,at one iteration the acknowledge number is 0x00007d5d6f.
>>>      Then i solved this problem by masking the 0x7d and made the next
>>> byte
>>> as 0x5d + 0x20.but a five to ten packets after this packet the sequence
>>> number of server(lwip) is junk/garbage value.
>> I'm not quite sure what you're saying here. You're saying the ACK number
>> is
>> 0x00007d5d6f - the non-zero bytes are only three bytes, so do you mean
>> that
>> the ACK field in the TCP header has increased by a further byte, which is
>> zero?
>>
>> No-one else has seen this for sure. What version of lwIP are you using and
>> where did you get it from?
>>
>> Jifl
>> -- 
>> eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
>> Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
>> Registered in England and Wales: Reg No 4422071.
>> ------["Si fractum non sit, noli id reficere"]------       Opinions==mine
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>>
> Quoted from: 
> http://www.nabble.com/tcp_data-packets-tp14710185p14713019.html
> 
> 


-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine