Re: Kannel & blocking connect again.

Hi, Stipe.

Stipe Tolj wrote:

> Hi Vjacheslav,
> 
> 
>>I want to discuss serious problem in Kannel WAP gateway.
>>It is about blocking connect(). Now any malicious user can
>>hang up kannel. It is too simple to do.
>>Anyone can send request from WAP phone to host which is configured
>>to drop SYN packets.
>>
>>For example: after simple command (for 10.10.10.10 owners)
>>iptables -A INPUT -p tcp -d 10.10.10.10 --destination-port 8081 --syn -j DROP
>>any request to http:/10.10.10.10:8081/ will block kannel totally
>>(couse http.c blocks in connect()) and other requests will be timed out.
>>
> 
> I did get the point, but I still didn't get the scenario that would
> cause Kannel to blocks it's operations.


I didn't get what scenario you mean. So:

Scenario 1 (how to reproduce)
As I said it is very easy to reproduce if you have access to any web server
with public address (you can test it with private web server if wapgw has
access to it, of course).
Fisrt of all configure some port to DROP (not REJECT!) incoming SYN packets
(or all packets).
Then take 2 phones or phone&fakewap. Make request to configured port from first
device. Kannel will block for 1-2 minutes. If you immediatly send request from 
another device you will get timeout error.


Scenario 2 (kannel process description)
1. http library get request from queue pending_requests
2. make connect to host
3. send request (nonblock realized by qwpoll and fdset)
4. create callback for reply
5. go to step 1.

Take step 2:
2.1 connect() send SYN to host
2.2 Wait for ACK (blocking till some minutes if no ACK or RST)
2.3 And handshaking and return connected socket or error.

So if we block at 2.2 then all requests in pending_request queue will be lost
due timeout for session machine.

> 
> I derived the gwlib/http.c and some other changes to gwlib/conn.c,
> socket.c and fdset.c from Netifos version to the patch attached.
> 
> Can you please apply the patch against Kannel current cvs tree and try
> the test scenario you described. Does it fix the problem?


Is this patch was tested by someone? With this patch even working
request doesn't work:

2002-11-11 11:15:43 [6] DEBUG: WTP: Created WTPRespMachine 0x80e0c78 (2)
2002-11-11 11:15:43 [6] DEBUG: WTP: resp_machine 2, state LISTEN, event RcvInvoke.
2002-11-11 11:15:43 [6] DEBUG: WTP 2: New state INVOKE_RESP_WAIT
2002-11-11 11:15:43 [1] DEBUG: WSP: Created WSPMachine 0x41b01240
2002-11-11 11:15:43 [6] DEBUG: WTP: Created WTPRespMachine 0x80e1c48 (3)
2002-11-11 11:15:43 [1] DEBUG: WSP: machine 0x41b01240, state NULL_SESSION, 
event TR-Invoke.i
nd
2002-11-11 11:15:43 [6] DEBUG: WTP: resp_machine 3, state LISTEN, event RcvInvoke.
2002-11-11 11:15:43 [1] DEBUG: WSP: decoding headers:
2002-11-11 11:15:43 [6] DEBUG: WTP 3: New state INVOKE_RESP_WAIT
2002-11-11 11:15:43 [1] DEBUG: Octet string at 0x80e1c30:
2002-11-11 11:15:43 [6] DEBUG: WTP: resp_machine 2, state INVOKE_RESP_WAIT, 
event TR-Invoke.r
es.
2002-11-11 11:15:43 [1] DEBUG:   len:  94
2002-11-11 11:15:43 [6] DEBUG: WTP 2: New state RESULT_WAIT
2002-11-11 11:15:43 [1] DEBUG:   size: 95
2002-11-11 11:15:43 [1] DEBUG:   immutable: 0
2002-11-11 11:15:43 [1] DEBUG:   data: 80 94 80 95 80 a1 80 98   ........
2002-11-11 11:15:43 [1] DEBUG:   data: 80 9d 80 83 80 87 80 86   ........
2002-11-11 11:15:43 [1] DEBUG:   data: 80 61 70 70 6c 69 63 61   .applica
2002-11-11 11:15:43 [1] DEBUG:   data: 74 69 6f 6e 2f 78 2d 4e   tion/x-N
2002-11-11 11:15:43 [1] DEBUG:   data: 6f 6b 69 61 47 61 6d 65   okiaGame
2002-11-11 11:15:43 [1] DEBUG:   data: 44 61 74 61 00 83 99 81   Data....
2002-11-11 11:15:43 [1] DEBUG:   data: 84 81 02 ea 51 81 04 02   ....Q...
2002-11-11 11:15:43 [1] DEBUG:   data: 03 e8 3d a9 4e 6f 6b 69   ..=.Noki
2002-11-11 11:15:43 [1] DEBUG:   data: 61 36 33 31 30 2f 31 2e   a6310/1.
2002-11-11 11:15:43 [1] DEBUG:   data: 30 20 28 30 34 2e 31 30   0 (04.10
2002-11-11 11:15:43 [1] DEBUG:   data: 29 00 58 2d 57 41 50 2e   ).X-WAP.
2002-11-11 11:15:43 [1] DEBUG:   data: 54 4f 44 00 01 00         TOD...
2002-11-11 11:15:43 [1] DEBUG: Octet string dump ends.
2002-11-11 11:15:43 [1] DEBUG: WSP: decoded headers:
2002-11-11 11:15:43 [1] DEBUG: Accept: application/vnd.wap.wmlc
2002-11-11 11:15:43 [1] DEBUG: Accept: application/vnd.wap.wmlscriptc
2002-11-11 11:15:43 [1] DEBUG: Accept: image/vnd.wap.wbmp
2002-11-11 11:15:43 [1] DEBUG: Accept: application/vnd.wap.wtls-ca-certificate
2002-11-11 11:15:43 [1] DEBUG: Accept: image/gif
2002-11-11 11:15:43 [1] DEBUG: Accept: text/plain
2002-11-11 11:15:43 [1] DEBUG: Accept: text/x-vCard
2002-11-11 11:15:43 [1] DEBUG: Accept: text/x-vCalendar
2002-11-11 11:15:43 [1] DEBUG: Accept: application/x-NokiaGameData
2002-11-11 11:15:43 [1] DEBUG: Accept-Language: en
2002-11-11 11:15:43 [1] DEBUG: Accept-Charset: iso-8859-1
2002-11-11 11:15:43 [1] DEBUG: Accept-Charset: utf-8; q=0.8
2002-11-11 11:15:43 [1] DEBUG: Accept-Charset: iso-10646-ucs-2; q=0.6
2002-11-11 11:15:43 [1] DEBUG: User-Agent: Nokia6310/1.0 (04.10)
2002-11-11 11:15:43 [1] DEBUG: X-WAP.TOD: ^A
2002-11-11 11:15:43 [1] DEBUG: WSP: End of decoded headers.
2002-11-11 11:15:43 [1] DEBUG: WSP 1: New state CONNECTING
2002-11-11 11:15:43 [1] DEBUG: WSP: machine 0x41b01240, state CONNECTING, event 
TR-Invoke.ind
2002-11-11 11:15:43 [1] DEBUG: WSP: method 3, state NULL_METHOD, event TR-Invoke.ind
2002-11-11 11:15:43 [1] DEBUG: WSP 1/3: New method state HOLDING
2002-11-11 11:15:43 [1] DEBUG: WSP 1: New state CONNECTING
2002-11-11 11:15:43 [1] DEBUG: WSP: machine 0x41b01240, state CONNECTING, event 
S-Connect.res
2002-11-11 11:15:43 [1] DEBUG: WSP: method 3, state HOLDING, event Release
2002-11-11 11:15:43 [6] DEBUG: WTP: resp_machine 2, state RESULT_WAIT, event 
TR-Result.req.
2002-11-11 11:15:43 [6] DEBUG: WTP 2: New state RESULT_RESP_WAIT
2002-11-11 11:15:43 [1] DEBUG: WSP 1/3: New method state REQUESTING
2002-11-11 11:15:43 [1] DEBUG: WSP 1: New state CONNECTING_2
2002-11-11 11:15:43 [1] DEBUG: WSP: machine 0x41b01240, state CONNECTING_2, 
event S-MethodInv
oke.res
2002-11-11 11:15:43 [1] DEBUG: WSP: method 3, state REQUESTING, event 
S-MethodInvoke.res
2002-11-11 11:15:43 [1] DEBUG: WSP 1/3: New method state PROCESSING
2002-11-11 11:15:43 [1] DEBUG: WSP 1: New state CONNECTING_2
2002-11-11 11:15:43 [6] DEBUG: WTP: resp_machine 3, state INVOKE_RESP_WAIT, 
event TR-Invoke.r
es.
2002-11-11 11:15:43 [6] DEBUG: WTP 3: New state RESULT_WAIT
2002-11-11 11:15:43 [10] DEBUG: HTTP: Opening connection to `www.lmt.lv:80'.
2002-11-11 11:15:44 [6] DEBUG: WTP: resp_machine 2, state RESULT_RESP_WAIT, 
event RcvAck.
2002-11-11 11:15:44 [6] DEBUG: WTP 2: New state LISTEN
2002-11-11 11:15:44 [1] DEBUG: WSP: machine 0x41b01240, state CONNECTING_2, 
event TR-Result.c
nf
2002-11-11 11:15:44 [6] DEBUG: WTP: Destroying WTPRespMachine 0x80e0c78 (2)
2002-11-11 11:15:44 [1] DEBUG: WSP 1: New state CONNECTED
2002-11-11 11:15:47 [4] DEBUG: Timeout-A elapsed.
2002-11-11 11:15:47 [6] DEBUG: WTP: resp_machine 3, state RESULT_WAIT, event 
Timeout-A.
2002-11-11 11:15:47 [6] DEBUG: WTP 3: New state RESULT_WAIT
2002-11-11 11:15:51 [4] DEBUG: Timeout-A elapsed.
2002-11-11 11:15:51 [6] DEBUG: WTP: resp_machine 3, state RESULT_WAIT, event 
Timeout-A.
2002-11-11 11:15:51 [6] DEBUG: WTP 3: New state RESULT_WAIT
2002-11-11 11:15:55 [4] DEBUG: Timeout-A elapsed.
2002-11-11 11:15:55 [6] DEBUG: WTP: resp_machine 3, state RESULT_WAIT, event 
Timeout-A.
2002-11-11 11:15:55 [6] DEBUG: WTP 3: New state RESULT_WAIT
2002-11-11 11:15:59 [4] DEBUG: Timeout-A elapsed.
2002-11-11 11:15:59 [6] DEBUG: WTP: resp_machine 3, state RESULT_WAIT, event 
Timeout-A.
2002-11-11 11:15:59 [6] DEBUG: WTP 3: New state RESULT_WAIT
2002-11-11 11:16:03 [4] DEBUG: Timeout-A elapsed.
2002-11-11 11:16:03 [6] DEBUG: WTP: resp_machine 3, state RESULT_WAIT, event 
Timeout-A.
2002-11-11 11:16:03 [6] DEBUG: WTP 3: New state RESULT_WAIT
2002-11-11 11:16:07 [4] DEBUG: Timeout-A elapsed.
2002-11-11 11:16:07 [6] DEBUG: WTP: resp_machine 3, state RESULT_WAIT, event 
Timeout-A.
2002-11-11 11:16:07 [6] DEBUG: WTP 3: New state RESULT_WAIT
2002-11-11 11:16:11 [4] DEBUG: Timeout-A elapsed.
2002-11-11 11:16:11 [6] DEBUG: WTP: resp_machine 3, state RESULT_WAIT, event 
Timeout-A.
2002-11-11 11:16:11 [6] DEBUG: WTP 3: New state LISTEN
2002-11-11 11:16:11 [6] DEBUG: WTP: Destroying WTPRespMachine 0x80e1c48 (3)
2002-11-11 11:16:11 [1] DEBUG: WSP: machine 0x41b01240, state CONNECTED, event 
TR-Abort.ind
2002-11-11 11:16:11 [1] DEBUG: WSP: method 3, state PROCESSING, event TR-Abort.ind
2002-11-11 11:16:11 [1] DEBUG: WSP 1/3: New method state NULL_METHOD
2002-11-11 11:16:11 [1] DEBUG: Destroying WSPMethodMachine 3
2002-11-11 11:16:11 [1] DEBUG: WSP 1: New state CONNECTED
2002-11-11 11:16:12 [6] DEBUG: WTP: Created WTPRespMachine 0x80e1de0 (4)
2002-11-11 11:16:12 [6] DEBUG: WTP: resp_machine 4, state LISTEN, event RcvInvoke.
2002-11-11 11:16:12 [6] DEBUG: WTP 4: New state LISTEN
2002-11-11 11:16:12 [1] DEBUG: WSP: machine 0x41b01240, state CONNECTED, event 
TR-Invoke.ind
2002-11-11 11:16:12 [6] DEBUG: WTP: Destroying WTPRespMachine 0x80e1de0 (4)
2002-11-11 11:16:12 [1] DEBUG: WSP 1: New state NULL_SESSION
2002-11-11 11:16:12 [1] DEBUG: Destroying WSPMachine 0x41b01240


> 
> BTW, the patch is only a first scratch. We need to *cleanly* derive
> the non-blocking from Netikos version.
> 


BTW, I have patch that solve problem of blocking connect, but it is not
so complex as introduced by Netikos - it doesn't handle maximum number of
open connections to the server and don't use getaddrinfo for resolving.

> Stipe
> 
> [email protected]
> -------------------------------------------------------------------
>


-- 
Vjacheslav Chekushin                                mailto:[email protected]
Latvian Mobile Phone Company                        http://www.lmt.lv