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
-----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
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
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
