Closed FelixSchladt closed 1 year ago
Looks like a regression I've introduced in 4b9a16764. It looks like the check should have been inverted, like in pico_ipv4_process_in() (same commit).
My understanding is, if the header len is 40, this means no options are present, therefore there are no options to parse.
TCP Header with no option is 20B. A few options are commonly added all the time (timestamp+windows scaling) making a typical header around 40B.
Fixing...
@FelixSchladt thanks for reporting this. please check if #20 solves the issue for you. I will merge in if confirmed.
@danielinux Thanks you so much for the quick fix and maintenance.
I tested it and it solves the Issue.
TCP Header with no option is 20B. A few options are commonly added all the time (timestamp+windows scaling) making a typical header around 40B.
I honestly didnt know that, so thanks for clarification 👍🏼
Thanks for confirming! I'll merge in #20
Hi All,
I am currently trying to port from the original PicoTCP to PicoTCP-NG and ecountered an issue. As I was not yet able to find the source of the bug, I am kindly asking for your help/advice.
During the Handshake process, the following check in
module/pico_tcp.c: tcp_parse_options
fails:I added some logging to the function and the output is as follows: (I cutted some output)
This log repeats till the test ist shutdown.
As the above check returns with
-1
the frame is discarded and a handshake is never completed.My understanding is, if the header len is 40, this means no options are present, therefore there are no options to parse. Would it maybe correct if the return value of the check is instead 0? (in this case its working correct in my test)
I am not sure I 100% understand whats happening here, so I would be very glad if someone had some answers for me.
Kind Regards, Felix