Subject: Bug in current sdr implementation ?

From: Oliver Brand <[email-masked]>
Date: Fri, 27 Jun 1997 16:27:12 +0200 (MET DST)

Hi MBone folks,

I think there's a bug in the current sdr implementation (v2.3a1)
concerning the parsing of the received SDP protocol entries.

If an announcement is received which does NOT contain either an
owner identifier (o=), a session name (s=), or a session information (i=)
field of the SDP protocol, sdr will crash because of
uninitialized pointers. This happens in the function "parse_entry"
(in sd_listen.c), and the concerning parameters are 
char *session, *desc, *orig, *chan[MAXMEDIA], as far as I understood the
code.

You may say that it should be impossible to generate an announcement with
empty session name and session information fields because sdr does not allow
these fields to be empty. But we indeed receive some SDP packages that 
only contain a v= and an o= field  (whatever the resaon may be),
and every time sdr dumps core ...

Any ideas, hints, comments ?

Oliver

---------------------------------------------------------------------
  Oliver Brand                          [email-masked]
  Department of Computer Science,       http://www.ibr.cs.tu-bs.de/hm/
  TU Braunschweig, Bueltenweg 74/75,    Fon:  +49 531 391 3285
  D-38106 Braunschweig                  Fax:  +49 531 391 5936
---------------------------------------------------------------------

---

From: Andrew Patrick <[email-masked]>
Date: Fri, 27 Jun 1997 11:17:53 -0400

> concerning the parsing of the received SDP protocol entries.
...

I am seeing the same behaviour, with SDR crashing about once every 5
minutes.  This has been happending on and off all week.  It seems to be
worst on SunOS implementations of SDR.  

I have been trying to trace the source of the packets but have not
finished my work.
They may be coming from one site running one SDP announcement software
(not SDR), but I am not sure enough yet to point fingers :-)

-- 
Andrew Patrick, Ph.D.             Communications Research Centre
[email-masked]         Ottawa, CANADA
http://debra.dgbt.doc.ca/~andrew  Phone: +1 613 990-4675 (Voice)

---

From: Andrew Patrick <[email-masked]>
Date: Fri, 27 Jun 1997 11:49:35 -0400

> (not SDR), but I am not sure enough yet to point fingers :-)

OK, the bad SDP packets seem to be coming from the host

ferao.jungle.bt.co.uk

which seems to be running the mAnnouncer software to announce a number 
of MBone sessions.

I have tried to right to [email-masked] but mail is 
not getting through.  Can someone in the UK try to contact 
the owner of this host?

Here is a good packet from that host...

ETHER:  ----- Ether Header -----
ETHER:  
ETHER:  Packet 9 arrived at 11:35:8.42
ETHER:  Packet size = 586 bytes
ETHER:  Destination = 1:0:5e:2:7f:fe, (multicast)
ETHER:  Source      = 0:0:3b:80:46:f2, 
ETHER:  Ethertype = 0800 (IP)
ETHER:  
IP:   ----- IP Header -----
IP:   
IP:   Version = 4
IP:   Header length = 20 bytes
IP:   Type of service = 0x00
IP:         xxx. .... = 0 (precedence)
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:   Total length = 572 bytes
IP:   Identification = 26157
IP:   Flags = 0x0
IP:         .0.. .... = may fragment
IP:         ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 118 seconds/hops
IP:   Protocol = 17 (UDP)
IP:   Header checksum = 8cc3
IP:   Source address = 132.146.107.45, ferao.jungle.bt.co.uk
IP:   Destination address = 224.2.127.254, SAP.MCAST.NET
IP:   No options
IP:   
UDP:  ----- UDP Header -----
UDP:  
UDP:  Source port = 34562
UDP:  Destination port = 9875 
UDP:  Length = 552 
UDP:  Checksum = 48BC 
UDP:  

	   0: 0100 5e02 7ffe 0000 3b80 46f2 0800 4500    ..^.....;.F...E.
	  16: 023c 662d 0000 7611 8cc3 8492 6b2d e002    .<f-..v.....k-..
	  32: 7ffe 8702 2693 0228 48bc 2000 0000 8492    ....&..(H. .....
	  48: 6b2d 763d 300a 6f3d 616e 6472 6577 2033    k-v=0.o=andrew 3
	  64: 3037 3537 3138 3936 3420 3330 3735 3731    075718964 307571
	  80: 3935 3733 2049 4e20 4950 3420 3134 322e    9573 IN IP4 142.
	  96: 3932 2e33 362e 3431 0a73 3d43 414e 4152    92.36.41.s=CANAR
	 112: 4945 2041 474d 202d 2043 416e 6574 2049    IE AGM - CAnet I
	 128: 4920 4c61 756e 6368 0a69 3d43 616e 6164    I Launch.i=Canad
	 144: 6961 6e20 4e65 7477 6f72 6b20 666f 7220    ian Network for 
	 160: 7468 6520 4164 7661 6e63 656d 656e 7420    the Advancement 
	 176: 6f66 2052 6573 6561 7263 6820 496e 6475    of Research Indu
	 192: 7374 7279 2061 6e64 2045 6475 6361 7469    stry and Educati
	 208: 6f6e 2061 6e6e 6f75 6e63 6573 2074 6865    on announces the
	 224: 206c 6175 6e63 6820 6f66 2043 416e 6574     launch of CAnet
	 240: 2049 4920 2d20 4361 6e61 6461 2773 206e     II - Canada's n
	 256: 6578 7420 6765 6e65 7261 7469 6f6e 2069    ext generation i
	 272: 6e74 6572 6e65 742e 0a75 3d68 7474 703a    nternet..u=http:
	 288: 2f2f 7777 772e 6361 6e61 7269 652e 6361    //www.canarie.ca
	 304: 2f63 320a 653d 4a6f 686e 2043 6f75 6c74    /c2.e=John Coult
	 320: 6572 203c 6a63 6f75 6c74 6572 406f 6e2e    er <jcoulter@on.
	 336: 6265 6c6c 2e63 613e 0a70 3d4a 6f68 6e20    bell.ca>.p=John 
	 352: 436f 756c 7465 7220 202b 3120 3631 3320    Coulter  +1 613 
	 368: 3738 312d 3838 3931 0a63 3d49 4e20 4950    781-8891.c=IN IP
	 384: 3420 3232 342e 322e 3234 312e 3138 352f    4 224.2.241.185/
	 400: 3132 370a 743d 3330 3736 3235 3430 3030    127.t=3076254000
	 416: 2033 3037 3632 3631 3230 300a 613d 746f     3076261200.a=to
	 432: 6f6c 3a43 4454 206d 416e 6e6f 756e 6365    ol:CDT mAnnounce
	 448: 7220 312e 312e 310a 613d 7479 7065 3a62    r 1.1.1.a=type:b
	 464: 726f 6164 6361 7374 0a6d 3d61 7564 696f    roadcast.m=audio
	 480: 2033 3137 3430 2052 5450 2f41 5650 2030     31740 RTP/AVP 0
	 496: 0a63 3d49 4e20 4950 3420 3232 342e 322e    .c=IN IP4 224.2.
	 512: 3234 312e 3138 352f 3132 370a 613d 7074    241.185/127.a=pt
	 528: 696d 653a 3430 0a6d 3d76 6964 656f 2036    ime:40.m=video 6
	 544: 3532 3738 2052 5450 2f41 5650 2033 310a    5278 RTP/AVP 31.
	 560: 633d 494e 2049 5034 2032 3234 2e32 2e32    c=IN IP4 224.2.2
	 576: 3231 2e33 372f 3132 370a                   21.37/127.

and here is a packet that causes SDR to crash...

ETHER:  ----- Ether Header -----
ETHER:  
ETHER:  Packet 10 arrived at 11:35:8.82
ETHER:  Packet size = 54 bytes
ETHER:  Destination = 1:0:5e:2:7f:fe, (multicast)
ETHER:  Source      = 0:0:3b:80:46:f2, 
ETHER:  Ethertype = 0800 (IP)
ETHER:  
IP:   ----- IP Header -----
IP:   
IP:   Version = 4
IP:   Header length = 20 bytes
IP:   Type of service = 0x00
IP:         xxx. .... = 0 (precedence)
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:   Total length = 40 bytes
IP:   Identification = 26158
IP:   Flags = 0x0
IP:         .0.. .... = may fragment
IP:         ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 246 seconds/hops
IP:   Protocol = 17 (UDP)
IP:   Header checksum = 0ed6
IP:   Source address = 132.146.107.45, ferao.jungle.bt.co.uk
IP:   Destination address = 224.2.127.254, SAP.MCAST.NET
IP:   No options
IP:   
UDP:  ----- UDP Header -----
UDP:  
UDP:  Source port = 34562
UDP:  Destination port = 9875 
UDP:  Length = 20 
UDP:  Checksum = 4C68 
UDP:  

	   0: 0100 5e02 7ffe 0000 3b80 46f2 0800 4500    ..^.....;.F...E.
	  16: 0028 662e 0000 f611 0ed6 8492 6b2d e002    .(f.........k-..
	  32: 7ffe 8702 2693 0014 4c68 2000 0000 8492    ....&...Lh .....
	  48: 6b2d 763d 300a                             k-v=0.

---

From: Oliver Brand <[email-masked]>
Date: Fri, 27 Jun 1997 18:05:43 +0200 (MET DST)

Hi !!

> not getting through.  Can someone in the UK try to contact 

It seems not to be a problem with the announcement software only ...
I just discovered several sites that also sent uncomplete announcements
(for example, host "ozon.daimi.aau.dk", session "CPM'97: Combinatorial Pattern Matching" or host "pythia.uoregon.edu", session "UO Presents KWAX Classical Radio").

An interesting aspect is that an uncomplete announcement always follows onto
a correct announcement for the same session...
maybe this is an indicator for network or
routing problems ? (duplicated packages etc)

Oliver

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 27 Jun 1997 10:04:00

>Any ideas, hints, comments ?

You could try using a browser other than "sdr" - i.e., one that doesn't
choke on the bad announcement.  "multikit" (available from
http://www.lvn.com/multikit/) works just fine (although it currently
doesn't let you *make* SDP/SAP announcements; only browse other people's
announcements).

	Ross.

---

From: Oliver Brand <[email-masked]>
Date: Fri, 27 Jun 1997 19:35:01 +0200 (MET DST)

Hi !!

> doesn't let you *make* SDP/SAP announcements; only browse other people's

OK. But it would be nicer to find out what's going on here...
The broken SDP packages seem to come from ferao.jungle.bt.co.uk. 

The curious thing is that this site seems to "mirror" some 
announcement packages ...
An exmination of the SDP announcements that arrive at our site shows that
the site above
frequently repeats some announcements that were originally sent by other sites.

???  Does anyone understand what is happening here ???

Oliver

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 27 Jun 1997 15:13:48 -0400

>???  Does anyone understand what is happening here ???

The SAP header has an "originating source" field to allow for proxy
relays (firewalls) to relay announcements on the other side of
the firewall. They put the originating source IP address in this field
and then re-announce the session using the source IP address of the
proxy relay.

I have seen several announcements come from both the originating source
AND a proxy relay. This makes me think that there are some proxy relays
out there that are re-annoucing sessions back to the global mbone instead
of just on the other side of their firewall.

There were a bunch of duplicate proxy announcements yesterday,
but so far, I don't see any right now.
I'll log the annoucements I receive and respond with addresses of
proxies sending duplicates if anyone is interested.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 30 Jun 1997 11:12:53 -0400

>proxies sending duplicates if anyone is interested.

Over the weekend, two sessions are being announced by both the originator
and a proxy announcer. The session names are below. I would be interested
in knowing what software is running on rot.rvs.uni-hannover.de and
buttle.lcs.mit.edu.

Gala Show to Celebrate the Reunification of Hong Kong with China by Ho
Hong Kong 1997 Handover (Official feed from RTHK)

    originated by mbone1.csc.cuhk.edu.hk (202.45.189.181)
       proxies by rot.rvs.uni-hannover.de (130.75.5.218)

MPoll Demo

    originated by calvin.dgbt.doc.ca (142.92.36.41)
       proxies by buttle.lcs.mit.edu (18.26.0.66)

Thanks,
Tom

---

From: "Lutz Grueneberg, RVS" <[email-masked]>
Date: Mon, 30 Jun 1997 17:40:23 +0200 (MET DST)

Hi,

>        proxies by rot.rvs.uni-hannover.de (130.75.5.218)
This annoucement came from our site. It was produced by a proxy
software currently under development. I just stopped
th process so no further (incorrect) proxy annoucnements shouldn't
occur. 

Sorry,
 Lutz
--
// Lutz Grüneberg                Lehrgebiet Rechnernetze und Verteilte Systeme
//                               Universität Hannover
//                               Schloßwender Str. 5
// [email-masked]     D-30159 Hannover, Germany
// Public PGP-Key available: http://www.rvs.uni-hannover.de/people/gruen.html
//                           http://bs.mit.edu:8001/pks-toplev.html

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 30 Jun 1997 11:47:33 -0400

In message <Pine.GSO.3.95.970630173542.1634B-100000@kauai> you write:
>the process so no further (incorrect) proxy annoucnements shouldn't
>occur. 
>
>Sorry,
> Lutz

Don't be sorry. I don't think it's hurting anything.
I was just wondering if something was misconfigured.

Carry on...  :-)

Tom