receive probes

[Michael Tuexen]

> On 23. Jun 2018, at 13:28, George Neville-Neil <gnn at neville-neil.com> wrote:
> 
> 
> 
> On 23 Jun 2018, at 19:17, Michael Tuexen wrote:
> 
>>> On 23. Jun 2018, at 11:21, George Neville-Neil <gnn at neville-neil.com> wrote:
>>> 
>>> 
>>> 
>>> On 19 Jun 2018, at 5:17, Michael Tuexen wrote:
>>> 
>>>> Dear all,
>>>> 
>>>> when should receive probes for the TCP and UDP network provider fire?
>>>> 
>>>> I would expect it to fire whenever a non-malformed packet is received.
>>>> Is that the intention?
>>>> 
>>> 
>>> Of the appropriate type of course, but yes.
>> OK. Let me propose a patch for UDP and TCP and put them on Phabricator...
>> 
> 
> I'm wondering what you're seeing that you think needs patching.
I found two things via testing to understand how things work:

1. The UDP receive provider only fires if udp_append() is called. So it
   does not fire, if a UDP packet is received and there is no endpoint
   handlign the data (in which you send out an ICMP packet indicating
   that the destination is unreachable because the port is unreachable).
   If the semantic is that the provider should fire if a packet is
   received it should fire. If the semantic is that the provider fires
   if data can be delivered to the user, it should not.
   But the TCP provider also fires for packets without user data, I think
   the UDP provider should fire whenever a UDP packet is received.
   There are a couple of error cases:
   * We can't get the IP and UDP header in an mbuf. -> Don't fire.
   * Destination port is 0. -> Don't fire.
   * Length violation -> Don't fire.
   * Checksum error -> Don't fire.
   * In case of multicast and no enp-point point found -> Fire (needs a fix)
   * In case of unicast and no end-point found -> Fire (needs a fix)
   * In case min TTL violated -> Fire (needs a fix) or not Fire?
   * In checksum coverage insufficient -> Don't fire

   While being there, separate out UDP and UDPLite, since they are different
   protocols. So provide a UDPLite provider.

2. This is what I get when setting up and tearing down a TCP connection
   over lookback and using the tcpio.d script:

   0        127.0.0.1:17024 ->        127.0.0.1:1234      38  (SYN)
   3        127.0.0.1:17024 <-        127.0.0.1:1234      38  (SYN|ACK)
   3        127.0.0.1:17024 ->        127.0.0.1:1234      30  (ACK)
   5        127.0.0.1:17024 ->        127.0.0.1:1234      34  (PUSH|ACK)
   0        127.0.0.1:1234  <-        127.0.0.1:17024     34  (PUSH|ACK)
   1        127.0.0.1:1234  ->        127.0.0.1:17024     30  (ACK)
   4        127.0.0.1:17024 <-        127.0.0.1:1234      30  (ACK)
   5        127.0.0.1:17024 ->        127.0.0.1:1234      30  (FIN|ACK)
   1        127.0.0.1:1234  <-        127.0.0.1:17024     30  (FIN|ACK)
   1        127.0.0.1:1234  ->        127.0.0.1:17024     30  (ACK)
   1        127.0.0.1:17024 <-        127.0.0.1:1234      30  (ACK)
   2        127.0.0.1:1234  ->        127.0.0.1:17024     30  (FIN|ACK)
   1        127.0.0.1:17024 <-        127.0.0.1:1234      30  (FIN|ACK)
   1        127.0.0.1:1234  <-        127.0.0.1:17024     30  (ACK)

   The issues I see:
   * The initial SYN is not reported to be received.
   * The SYN|ACK is not show as being sent.
   * The ACK (third message of the handshake) is not reported to be received.
   I guess this is related to the fact that within the TCP syn-cache code no
   providers are triggered.
   * Also the last ACK is not reported to be sent.
   I would expected all of the above segments to be reported as sent and received.

Do you agree with the above expectations on the behaviour?

Best regards
Michael
> 
> Best,.
> George