February 2010 - Udpcast

castomize udpcast iso image
by Gianluigi Autuori 17 Jul '11

17 Jul '11

I want to use Udpcast from iso image in this scenario: - first pc boots from udpcast iso image -second pc boots from ethernet using pxe that sends him udpreceiver How can I do it? thanks

3 2

does sender need to bind a socket to the multicast addr and receiver (portbase) port ?
by Rodriguez Alban 15 Feb '10

15 Feb '10

Hi, We're experiencing a strange behaviour with multicast igmp using udpcast. - sender (quite old 20081213) is running on a Linux SLES 11 64 bit on a VMware ESX guest - receivers (same version) are running on WinPE 2.0 x86 computers. - sender and receivers are on the same vlan This use to work amazingly well until for some reasons (correcting a bug actually), there was a firmware update on a 10GB Dell switch where the blade server is running all the VMware VMs. Now it doesn't work anymore: - the CMD_HELLO part woks as espected, and receivers are given their ID and the multicast data adress to join in. - then when the receiver actually sends CMD_GO, receivers don't even see the transfer has yet begun and sender finally quit after the normal timeout with no answer from participants. It seems clients never receive data sent to the multicast data address. So we made some tests using iperf as a multicast packet generator and rtpqual as a receiver; we could see that rtpqual was able to receive the packets only if we were also running an rtpqual on the machine we were generating the packet with iperf ! Then we made the same test with udp-sender and udp-receiver (2 receivers) and guess what ? it started to work as soon as we started an rtpqual process on the sender side ! we could observe that when rtpqual is not running on the sender machine igmp cuts the tree on the Dell switch and receivers aren't getting the stream anymore. It seems udp-sender should also bind to the multicast data address and portbase. Seen on udpcast source code (socklib.c): /** * Set socket to listen on given multicast address Not 100% clean, it * would be preferable to make a new socket, and not only subscribe it * to the multicast address but also _bind_ to it. Indeed, subscribing * alone is not enough, as we may get traffic destined to multicast * address subscribed to by other apps on the machine. However, for * the moment, we skip this concern, as udpcast's main usage is * software installation, and in that case it runs on an otherwise * quiet system. */ static int mcastListen(int sock, net_if_t *net_if, struct sockaddr_in *addr) { return mcastOp(sock, net_if, getSinAddr(addr), IP_ADD_MEMBERSHIP, "Subscribe to multicast group"); } However mcastListen is called from makeSocket() (socklib.c) which actually binds the socket. Latest version of udpcast (20100130) doesn't seem to bring any change and behaves the same. So, I tried to create an additional socket in startSender() (udps_negociate.c) and bind to RECEIVER_PORT(portBase): mysock = makeSocket(ADDR_TYPE_MCAST, net_config->net_if, net_config->dataMcastAddr, RECEIVER_PORT(net_config->portBase)); But I got the same behaviour :( So I pasted the whole openMC() function from rtpqual.c to socklib.c: #define NOERROR(val,msg) {if (((int)(val)) < 0) {perror(msg);exit(1);}} int openMC(name, port) char *name; int port; { struct sockaddr_in sin; struct ip_mreq mreq; struct hostent *hp; int fd, one=1; bzero(&sin, sizeof(struct sockaddr_in)); if (isdigit(*name)) { sin.sin_addr.s_addr = inet_addr(name); } else if (hp = gethostbyname(name)) { bcopy(hp->h_addr, (char *)&sin.sin_addr, hp->h_length); } else { printf("I Don't understand session name %s\n",name); exit(1); } sin.sin_family = AF_INET; sin.sin_port = port; if (!IN_MULTICAST(ntohl(sin.sin_addr.s_addr))) { printf("%s is not a multicast session\n", name); exit(1); } mreq.imr_multiaddr = sin.sin_addr; mreq.imr_interface.s_addr = INADDR_ANY; NOERROR(fd = socket(AF_INET, SOCK_DGRAM, 0), "socket"); NOERROR(setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one)), "SO_REUSEADDR"); if (bind(fd, (const struct sockaddr *) &sin, sizeof(sin)) == -1) { perror("Using INADDR_ANY because"); sin.sin_addr.s_addr = INADDR_ANY; NOERROR(bind(fd, (const struct sockaddr *) &sin, sizeof(sin)), "bind"); } NOERROR(setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq)), "IP_ADD_MEMBERSHIP"); return(fd); } And called it from the main() function from udp-sender.c myMcastDataAddr is a string copy from the command line argument because net_config structure only stores the sock_addr_in values and so that I can directly use the openMC() function without any modification. /* -- */ printf("addr = %s\n", myMcastDataAddr); printf("port = %d\n", RECEIVER_PORT(net_config.portBase)); printf("openMC()\n"); mysock = openMC(myMcastDataAddr, RECEIVER_PORT(net_config.portBase)); /* -- */ Indeed, it works now, despite this is a really ugly hack! However openMC() seems to do the same as makeSocket do: create the socket, bind to the specified multicast address and port and call a setsockopt for IP_ADD_MEMBERSHIP. So now it works for me, but it would be great if the correct patch (not mine) was integrated to the source code (maybe others would need it). EDIT: it works with makeSocket only if I call htons() to the port number: mysock = makeSocket(ADDR_TYPE_MCAST, net_config->net_if, &net_config->dataMcastAddr, htons(RECEIVER_PORT(net_config->portBase))); Other calls to makeSocket() doesn't use htons to swap the bytes so I initially I wasn't doing either ... thanks Alban -- Alban Rodriguez Centre de Ressources Informatiques Université de La Rochelle http://cri.univ-lr.fr

3 2

Keyboard Problem - DP55KG
by Registrations 10 Feb '10

10 Feb '10

Hello Everyone, Sorry if this message is redundant. I am new to this list. UDPcast seems to not recognize my keyboard. In fact, I am having trouble with it recognizing my installed hard drive since it doesn't find any disk parameters I give it.. I have tried everything and I've come to the conclusion that maybe there is no support for my board at this point. I am using the Intel DP55KG motherboard. Does anyone know if this board is supported and if so, do you have a work around for this problem? Any help would be much appreciated. Payam

1 0

fogservice takes to long
by Dieter Kroemer 10 Feb '10

10 Feb '10

Hi, I configured my fog-config-file, that the service inspects al 30 seconds, if there is a new snapin - sometime it works good, but sometimes it takes more than 6 minutes, untill the service recognizes, that there is an new snapin. Does anybody knows, why the service is sometimes so slow? Kind regards Dieter

2 1

get snapin without fog-service
by Dieter Kroemer 10 Feb '10

10 Feb '10

Hi, is there a possibility, that a client gets a snapin after reboot (e.g. with a batch-file in the autostart-folder), without using the fogservice? Kind regards Dieter

1 0

Re: [Udpcast] does sender need to bind a socket to the multicast addr and receiver (portbase) port ?
by Alban Rodriguez 09 Feb '10

09 Feb '10

Le 9 févr. 10 à 16:19, udpcast-request(a)udpcast.linux.lu a écrit : > > Date: Tue, 9 Feb 2010 16:19:44 +0100 > From: Jens Breuer <breuer.jens(a)googlemail.com> > To: udpcast(a)udpcast.linux.lu > Subject: Re: [Udpcast] does sender need to bind a socket to the > multicast addr and receiver (portbase) port ? > Message-ID: > <76ce20421002090719j1b354fay54a779bdccf9f0cf(a)mail.gmail.com> > Content-Type: text/plain; charset=windows-1252 > > Hello Rodriguez > > You really should try with the most recent version of udpcast to check > whether this problem has already been solved over the past 2 years. > > Additionally, I would recommend to triple-check the switch' > configuration. From my experience in 99 out of 100 cases there is a > network misconfiguration when experiencing problems with udpcast. > > Just my 0,5?. > > Kind regards > Jens Hi Jens, Thanks for your answer; as I wrote, latest version (20100130) does the same. This is why I had to look at the code and make this dirty hack. I'm pretty sure the Dell switch is culprit, but the multicast configuration looks good, and with the modified version of the sender multicast and igmp work as expected. Do you think it is acceptable for the sender to query the multicast data group itself as the general rule or could it bring some more problems ? ( the later case would require my patching of the code with each new release ...). Maybe Alain is the only one who can state here ... thanks Alban -- Alban Rodriguez Centre de Ressources Informatiques Université de La Rochelle http://cri.univ-lr.fr

1 0

New project using udpcast
by Markovic´ Srdjan 08 Feb '10

08 Feb '10

Hi Everyone, we are developing a new multicast network installation system for linux and maybe other OSs that is using udpcast for transmission. This is our school examination project, so please do not send us patches or suggestions. After the examination, it will be developed as a normal OSS-project. If you like, you can follow us on twitter (http://twitter.com/mulin_project) or join us on Sourceforge (http://sourceforge.net/projects/mulin) Thanks for your support. - - Markovic Srdjan, 5AHELI Netzwerksupport HTBLuVA Mödling Tel: +43 2236 408 281 (Mo: 8:00 - 15:00) -x- routed via XWall 3.43 - HTBLuVA Moedling, Austria -x-

1 0

Optimum setting for zero packet loss
by Markus 07 Feb '10

07 Feb '10

Hi Everyone, I have a requirement to send large tar packets in half duplex (one way only communication). I'm trying to determine what is the best values and to use in udp-sender and udp-receiver. My setup is, one server connected to another across a single 1Gb fibre link (no return path). The tar packets are sometimes very large, in the Gb's and I can't have any loss. My first setting were:- On the sending server:- udp-sender --async --log /tmp/log --fec 8x6/64 --max-bitrate 100m --autostart 1 --mcast-data-addr 224.2.2.2 --interface eth0 -f /root/send`date +%y%m%d%H%M`.tar There is a crontab to run this udp-sender line every 10 minutes to keep sending new packets. On the receiving server:- udp-receiver --interface eth0 --file /root/send`date +%y%m%d%H%M`.tar There is a crontab to run a script checking if udp-receiver is running and if not restarts it so it's ready for the next packet. I initially started the -max-bitrate at 1000m and it actually successfully got a tar packet across but after repetitive testing found it was dropping packets halfway through the transfer. So I continued to decrease the -max-bitrate. It got progressively better until I got to a bitrate of 100m. Then I found that the receiving server would start to receive the packet then dropped it straight away leaving a 0 byte size packet or occasionally a very small file (e.g 8Mb), which from observation I found it was dropping it almost instantly. I currently have a test running over the weekend with a couple of changed settings in the udp-sender:- udp-sender --async --log /tmp/log --fec 8x8/128 --max-bitrate 100m --autostart 3 --mcast-data-addr 224.2.2.2 --interface eth0 -f /root/send`date +%y%m%d%H%M`.tar I increased the fec in hope that it would improve the transfer speed and increased the autostart hoping it would help in not dropping out at the beginning of a reception. Could you please let me know your thoughts? Also if there are any things you think I should add or change in the udp-sender or udp-receiver to improve the reliability and transfer speed. For my requirements I really need to have a fasted transfer rate (and thought I'd get better than 100Mb on a 1Gb link) and I certainly can't go any slowed. I also require a zero loss performance. Thanks, Markus

1 0