> I could fix this issue there by checking the protocol too. Then
> there is no need to touch LwIP. Thank you for this idea :)
Thank the guys at DEC and Bell Labs who invented the packet filtering
firewall in the late 80's.
___
lwip-users mailing
>> Did you check that with a known-good application ?
> *Not yet.*
Well..., you should. Did I say 'should' ? You _must_
>> What version of lwIP are you using ?
> *We used lwip 1.4.1 and also
> source from git.savannah.gnu.org (commit #70f3e5e). In both versions
> the problem exists.*
I would sa
> So, summarizing, that RST was leaking your filter, one that was filtering out
> all other RSTs sent as response on unused TCP ports:
We are filtering only incoming packets. LwIP does not see these packets at all.
The port check does not currently check protocol, so the SYN passes the check
wh
> Well, thanks for not saying this earlyier ;-) Of course, if you almost
> randomly filter out packets, you can't expect us to explain the observed
> behaviour.
My apologies.
> Before implementing such a change, you should obviously know very well what
> you are doing (e.g.: UDP has really and
So, summarizing, that RST was leaking your filter, one that was
filtering out all other RSTs sent as response on unused TCP ports:
You Your port lwip
TCP SYN on port x -->--> let me see
silence block! <-- RST
TCP SYN on port A -
twagner wrote:
> The HardFault happens in the function tcp_output at the line
> "if (TCP_SEQ_LT(ntohl(seg->tcphdr->seqno), ntohl(useg->tcphdr->seqno))) {"
> after 10 - 20 minuts.
> [..]
I could suggest, you probably did not obey lwIP's threading/multitasking
requirements, but most obviously, you
Esa Hill wrote:
> I already studied it a bit, but I wasn't sure where I could get information
> that we are handling a UDP socket there.
> Or could I assume that it's not a TCP socket and therefore skip the RST?
I totally don't get that question.
> I forgot to say that we have a list of open por
Thank you for this information. We will implement an option for this if the
certification lab elevates this issue.
I already studied it a bit, but I wasn't sure where I could get information
that we are handling a UDP socket there. Or could I assume that it's not a TCP
socket and therefore skip
Esa Hill wrote:
> When nmap scan is executed against our device (LwIP 1.4.1), it responds with
> RST for SYN even
> when the socket/port is listening only UDP “connections”.
>
> Is this correct behavior (does some RFC say something about this?) or should
> it just drop silently
> the SYN packet
The HardFault happens in the function tcp_output at the line
"if (TCP_SEQ_LT(ntohl(seg->tcphdr->seqno), ntohl(useg->tcphdr->seqno))) {"
after 10 - 20 minuts.
The processor wants to load "seg->tcphdr->seqno" and "useg->tcphdr->seqno"
but one pointer is not valid and the processor crashes at the addr
10 matches
Mail list logo
