Udpcast February 2006

udpcast@udpcast.linux.lu

8 participants
14 discussions

Problems with udpcast 20051223
by John Newbigin 13 Feb '06

13 Feb '06

First off I had a compile error: console.c:36: parse error before `*' console_t needs to be defined at the start of prepareConsole. Easy fixed. The real problem I am having is that multicast won't work with more than one client. When I run with only one client it runs OK. If I have more than one the sender prints out Timeout notAnswered=[1] notReady=[1] nrAns=1 nrRead=1 nrPart=2 avg=9198 Timeout notAnswered=[1] notReady=[1] nrAns=1 nrRead=1 nrPart=2 avg=9198 Timeout notAnswered=[1] notReady=[1] nrAns=1 nrRead=1 nrPart=2 avg=9198 and none of the clients work. I have also tested netcast (http://sourceforge.net/projects/netcast) which works with multiple clients so I don't think it is a multicast issue. netcast does not have many features so I would like to use udpcast. I have also got the message Unexpected opcode 0700 and Unexpected opcode 0200 a few times so I wonder if that is related to my problem. Any help would be greatly appreciated. John. -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.ict.swin.edu.au/staff/jnewbigin

2 2

RE: [Udpcast] Info on UDPcast IGMP packets
by Manon Lessard 10 Feb '06

10 Feb '06

-----Message d'origine----- De : Alain Knaff [mailto:alain@knaff.lu] Envoyé : February 10, 2006 4:48 AM À : Manon Lessard Cc : udpcast(a)udpcast.linux.lu Objet : Re: [Udpcast] Info on UDPcast IGMP packets Manon Lessard wrote: > Hi > > > I work for the telecom dept of a large university and we are currently > working with some UDPcast users on a very strange problem. > > It appears they are unable to start a cast on a given group of machines. Where exactly does it fail? Can receivers still correctly register with the sender (Sender displays New connection from 192.168.1.10 (#0) 00000009). Are no multicast packets received at all on receiver, or is there only a very high loss rate? Knowing on exactly when udpcast starts failing may help point to a source of the problem. [...] The stations register with the server. However the cast never starts...or almost never...and if it does...well it will eventually freeze... I doubt the MTU has anything to do with it... > These clients are using a version of UDPcast dating from dec. 04. > Are you aware of anything in UDPcast or any incompatibilities with some > Cisco IOS versions that could cause this problem? I checked with a colleague, and he told me that the Cisco equipment needs to be specifically configured for correctly understanding IGMP (because usually they use a proprietary protocol, CGMP). The equipment needs to be configured to understand IGMP v3 and PIM v2. Symptoms of failure in this area is that receivers can actually register with the server, but transfer will not start (or conversely, transfer will start, but traffic will also be blasted out of those switch ports where no participating receiver is connected. This latter failure mode, where multicast is basically treated as broadcast is much more common that the case that you are observing) We currently support only IGMP v2. V3 is out of the question for the moment. Did Udpcast require v2 at some point because this thing has worked before and isn't working anymore...if they could fix it by reverting to an older version that would make everyone happy. Very happy. I doubt it's the ttl and we do not use storm protection. If nothing else helps, you can try to instruct udp-sender to use broadcast, rather than multicast, by adding the --broadcast flag to its command line (but in that case, traffic will spread over your whole network, not just the machines that are actually participating) I could tell them to do that... and have my L3 switch reach 100% cpu, thus implying that I'd voluntarily cause a network outage on a third of our network. You should mention something about that (ie can make the cpu of the router reach 100%) in your documentation (you might already mention it, I have to say I haven't read it...). The thing is that in campus environments the techs and analysts out in the field are not necessarily well aware of the impact their work might have on the net infrastructure and other users... When they did try the broadcast function they successfully caused an outage and we had to shut them down before they had the chance to cast their image... In any case, thanks for your quick reply... Regards, M

1 0

Info on UDPcast IGMP packets
by Manon Lessard 10 Feb '06

10 Feb '06

Hi I work for the telecom dept of a large university and we are currently working with some UDPcast users on a very strange problem. It appears they are unable to start a cast on a given group of machines. If they use Ghost, they are able send their image fine (using Ghost's multicast). If they use UDPcast, the multicast will start randomly on a couple of machines (when one's lucky) but for 99% of machines it just won't work. Since they are one of the very few if not the only ones having this problem with multicasting, we went ahead and monitored their transactions with ethereal (latest version). The access layer switches which connect our clients' machines and server are Cisco 3500XL. These switches do not have advanced multicast features and need our L3 switch (Cisco 6509 with sup 720) to tell them to open the multicast session. It so appears that the IGMP packets sent by UDPcast differ from Ghost on 2 points: in the header they are using ID field with a value of 0 (1 for Ghost) and the DF bit is set to 1 (0 for Ghost). The IGMP packets sent by Ghost are recognized and the session established. The ones sent by UDPcast are not, and the session is obviously dropped... These clients are using a version of UDPcast dating from dec. 04. Are you aware of anything in UDPcast or any incompatibilities with some Cisco IOS versions that could cause this problem? Regards M. CCNP

2 1

udpcast / broken partitions
by Andreas 02 Feb '06

02 Feb '06

Hi All, We're using udpcast to clone ~400gb partitions from a master to ~10 slaves. Sender: udp-sender --full-duplex --file /dev/sdb --min-wait 15 -max-bitrate 300M --nokbd Client: udp-receiver --file /dev/sdb --nokbd Problem: ~80% of the clones work fine, but ~20% cause problems. We observed the following symptoms: 1. partition broken (mount /dev/foo results in 'unsupported operation') 2. partitions mountable, but lots of directories give 'permission error' when trying to access them. (In fact they are unreadable, changing perms does't help). 3. completely broken: partition is mountable, find / results in kernel panic 'CPU LOCK' ;-) (re-cloning works though, so it's not cpu related) We couldn't trace it back to individual hardware issues. From all 10 hosts, they break randomly. (8 out of 10 are usually fine. But it's not like the first 8, or the 8 in the middle or so. - Sometimes, all 10 are fine.) Misc: - FS: reiser3 - UDPCast: 20050226 - OS: Gentoo 2005.1 - NW: gb switched Really hard to track down for me. What I'd be glad if you could help me with: - diff. options (bitrate changes, etal) - udpcast update (hint to changelog entry about the fix) - misc other hints that might help :-) Thanks a lot for your time, Andreas

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Udpcast February 2006