Re: RESEND : CR: OVIL-7DPT56 : Helix fails toreconnectto WLAN AP

rajesh.rathinasamynokia.com wrote:
> Jamie,
>   Thanks for clarifying.
> 
> So how can we protect ourselves from old session data
and malicious
> packets. If a malicious RDT packet is pushed in, it
could mess up the
> protocol handling.
> 

Dealing with packets from previous sessions is probably best
handled by
changing the port when starting a new session. Or sanity
checking the
sequence number should work in many cases (though certainly
not a
reliable, foolproof check).

Malicious packets I wouldn't think are much concern, but can
be dealt
with by checking the source.

RDTv4 adds session identifiers, when/if it ever makes its
way into
production!

Thanks,
Jamie

> Thanks,
> Rajesh.
> 
> 
>> -----Original Message-----
>> From: ext Jamie Gordon [mailto:jgordonreal.com]

>> Sent: Thursday, May 01, 2008 12:38 PM
>> To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas)
>> Cc: ehychereal.com; Nadagoudar Ashwinkrishna.1 
>> (EXT-InfoVision-MSW/Dallas); protocol-devhelixcommunity.org
>> Subject: Re: [Protocol-dev] RESEND : CR:
OVIL-7DPT56 : Helix 
>> fails toreconnectto WLAN AP
>>
>> No, with RDTv2/3 there is no means of identifying
packets 
>> belonging to different sessions.
>>
>> rajesh.rathinasamynokia.com wrote:
>>> Hi Eric,
>>>    You are right. We need to add this for
future work. The 
>> current fix 
>>> will also avoid packets coming in thus not
increasing the 
>> load on the 
>>> sockets for the current streaming session.
>>>
>>> By the way, Does RDT packets have SSRC or any
other means of session 
>>> identifier ?
>>>
>>> Thanks,
>>> Rajesh.
>>>
>>>
>>>> -----Original Message-----
>>>> From: protocol-dev-bounceshelixcommunity.org
>>>> [mailto:protocol-dev-bounceshelixcommunity.org] On Behalf Of ext 
>>>> Eric Hyche
>>>> Sent: Thursday, May 01, 2008 8:51 AM
>>>> To: Nadagoudar Ashwinkrishna.1
(EXT-InfoVision-MSW/Dallas); 
>>>> protocol-devhelixcommunity.org
>>>> Subject: RE: [Protocol-dev] RESEND : CR:
OVIL-7DPT56 : Helix fails 
>>>> toreconnectto WLAN AP
>>>>
>>>>
>>>> This change looks good.
>>>>
>>>> However, I see this change as more of a
workaround rather than  a 
>>>> real solution. We should have a way of
detecting datagrams from old 
>>>> sessions and throwing them away at the
transport  layer. However, we 
>>>> can put that down as a to-do item for
future work.
>>>>
>>>> Eric
>>>>
>>>>
=============================================
>>>> Eric Hyche (ehychereal.com)
>>>> Technical Lead
>>>> RealNetworks, Inc.  
>>>>
>>>>> -----Original Message-----
>>>>> From: protocol-dev-bounceshelixcommunity.org
>>>>> [mailto:protocol-dev-bounceshelixcommunity.org] On Behalf Of 
>>>>> ext-ashwinkrishna.1.nadagoudarnokia.com
>>>>> Sent: Thursday, May 01, 2008 9:00 AM
>>>>> To: protocol-devhelixcommunity.org
>>>>> Subject: [Protocol-dev] RESEND : CR:
OVIL-7DPT56 : Helix fails to 
>>>>> reconnectto WLAN AP
>>>>>
>>>>>
>>>>>
>>>>>
	_____________________________________________ 
>>>>> 	From:   Nadagoudar Ashwinkrishna.1
(EXT-InfoVision-MSW/Dallas)  
>>>>> 	Sent:   Tuesday, April 29, 2008 4:52
PM 
>>>>> 	To:     'protocol-devhelixcommunity.org' 
>>>>> 	Subject:        CR : OVIL-7DPT56 :
Helix fails to 
>>>>> reconnect to WLAN AP
>>>>>
>>>>>
>>>>> 					" Nokia submits this
>>>>> code under the terms of a commercial
contribution agreement with 
>>>>> RealNetworks, and I am authorized to
contribute this code 
>> under said 
>>>>> agreement."
>>>>>
>>>>> 					  
>>>>> 					Modified by:  
>>>>> ext-Ashwinkrishna.1.Nadagoudarnokia.com
>>>>> 					  
>>>>> 					Reviewed by: 
>>>>> 					  
>>>>> 					Date: 04/28/2008
>>>>> 					  
>>>>> 					Project: SymbianMmf
>>>>> 					  
>>>>> 					ErrorId:  OVIL-7DPT56
>>>>> 					  
>>>>> 					Synopsis: Helix fails
>>>>> to reconnect to WLAN AP
>>>>>
>>>>> 					Scenario: 
>>>>> 					Walk out of WLAN
>>>>> coverage while streaming, wait for the
reconnection query. 
>>>> Go back to
>>>>> WLAN coverage area. Select
reconnection. Audio and Video are not 
>>>>> regained but Media player still shows
playback progress.
>>>>>
>>>>> 					Root Cause of the problem: 
>>>>> 					New Helix client is
>>>>> initialized after reconnecting to the
WLAN. But there are network 
>>>>> buffered packets still coming from the
old session along
>>>> with the new
>>>>> packets to the same ip address( of the
>>>>> client) and to the same UDP port.
>>>>>
>>>>> 					So both new and old
>>>>> packets are getting mixed. This is
causing the problem
>>>>>
>>>>> 					Solution: 
>>>>>
>>>>> 					Choose the UDP port
>>>>> dynamically between the specified range
so that after
>>>> reconnecting to
>>>>> the WLAN , server sends all the new
packets to the new port.
>>>>>
>>>>> 					Files Modified: 
>>>>> 					        
>>>>> protocolrtsprtspclnt.cpp
>>>>>
>>>>> 					Files Added: None
>>>>> 					  
>>>>> 					Image Size and Heap Use
>>>>> impact: None
>>>>>
>>>>> 					Module Release testing
>>>>> (STIF) : Done. 
>>>>>
>>>>> 					Test case(s) Added  :  N/A
>>>>> 					  
>>>>> 					Memory leak check
>>>>> performed : yes. No leak. 
>>>>>
>>>>> 					Platforms and Profiles
>>>>> Build Verified:
helix-client-s60-50-mmf-mdf-arm
>>>>>
>>>>> 					Platforms and Profiles
>>>>> Functionality verified: armv5, winscw
>>>>> 					  
>>>>> 					Branch: Head & 210CayS
>>>>>
>>>>>
>>>>> 		Index: rtspclnt.cpp
>>>>> 		
>>>>>
>>
============================================================
======= 
>>>>> 		RCS file:
/cvsroot/protocol/rtsp/rtspclnt.cpp,v 
>>>>> 		retrieving revision 1.182.2.26 
>>>>> 		diff -w -u -b -r1.182.2.26
rtspclnt.cpp 
>>>>> 		--- rtspclnt.cpp        7 Mar 2008
20:23:17 
>>>>> -0000       1.182.2.26 
>>>>> 		+++ rtspclnt.cpp        29 Apr 2008
18:57:37 -0000 
>>>>> 		 -5629,18 +5629,24  
>>>>> 		                     continue; 
>>>>> 		                 }
>>>>> 		  
>>>>> 		-                for (datagramPort =

>>>>> pUDPPort->uFrom; datagramPort <=
pUDPPort->uTo; datagramPort += 2)
>>>>> 		-                { 
>>>>> 		+                                    

>>>>>                 datagramPort = ((
UINT16 )HX_GET_TICKCOUNT() % 
>>>>> (pUDPPort->uTo -
pUDPPort->uFrom)) + pUDPPort->uFrom ;
>>>>>
>>>>> 		  
>>>>> 		                     if (datagramPort
% 2) 
>>>>> 		                     { 
>>>>> 		-                        datagramPort
= 
>>>>> (UINT16)(datagramPort + 1); 
>>>>> 		+                    datagramPort =
(datagramPort + 1); 
>>>>> 		                     }
>>>>> 		  
>>>>> 		+                for (UINT16 temp =
0; temp < 
>>>>> (pUDPPort->uTo - pUDPPort->uFrom)
; temp += 2, datagramPort += 2) 
>>>>> 		+                { 
>>>>> 		                     if
((pUDPPort->uTo -
>>>> datagramPort + 1) < 2)
>>>>> 		                     { 
>>>>> 		-                        break; 
>>>>> 		+                              
datagramPort = 
>>>>> pUDPPort->uFrom ;
>>>>> 		+                               if
(datagramPort % 2) 
>>>>> 		+                               { 
>>>>> 		+                                    

>>>>> datagramPort = (datagramPort + 1); 
>>>>> 		+                               } 
>>>>> 		                     } 
>>>>> 		+ 
>>>>> 		                    
HXLOGL3(HXLOG_RTSP,
>>>>>
"RTSPClientProtocol[%p]::InitSockets(): trying
%lu...", this, 
>>>>> datagramPort);
>>>>> 		                     if (HXR_OK == 
>>>>>
CreateUDPSockets(pStreamInfo->m_streamNumber,
>>>>> pStreamInfo->m_ulAvgBitRate,
datagramPort))
>>>>>
>>>>> 		                     {
>>>>>
>>>>> 					-Ashwin
>>>>>
>>>>>
>>>>
_______________________________________________
>>>> Protocol-dev mailing list
>>>> Protocol-devhelixcommunity.org
>>>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
>>>>
>>>
_______________________________________________
>>> Protocol-dev mailing list
>>> Protocol-devhelixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

Re: RESEND : CR: OVIL-7DPT56 : Helix fails toreconnectto WLAN AP

Thread: Re: RESEND : CR: OVIL-7DPT56 : Helix fails toreconnectto WLAN AP