I would assume we could check the IP address
and port of the server sending the datagram. If the
server is sending from the same port, then it
doesn't help, but the server is probably dynamically
picking a port, so if the port didn't match with
what we saw in the SETUP response, then we could
throw it away.
Of course, this type of question really isn't my area
of expertise, so I could be way off.
Eric
=============================================
Eric Hyche (ehyche real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: rajesh.rathinasamynokia.com
> [mailto:rajesh.rathinasamynokia.com]
> Sent: Thursday, May 01, 2008 1:49 PM
> To: jgordonreal.com
> Cc: ehychereal.com;
ext-ashwinkrishna.1.nadagoudarnokia.com;
> protocol-devhelixcommunity.org
> Subject: RE: [Protocol-dev] RESEND : CR: OVIL-7DPT56 :
Helix
> fails toreconnectto WLAN AP
>
> 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.
>
> 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
|
