From dkelson at gurulabs.com  Mon Nov  3 20:14:03 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Mon, 03 Nov 2008 12:14:03 -0700
Subject: [Udpcast] Spanning Tree/udhcpc failure
Message-ID: <1225739643.3417.19.camel@mentor.gurulabs.com>

Hello,

Can UDPcast be configured to "try harder/longer" to obtain a DHCP lease?
We have spanning tree running on our switches and updcast always fails
to obtain a lease on the first three attempts, then manually telling it
to try again always results in success. This defeats the "preconfigured"
setup.

Looking at the docs for udhcpc, I see:

-T,--timeout=N          Try to get a lease for N seconds (default 3)

Could you bump this up by default to say 10 seconds (or have it tunable
on the cast-o-matic)?

Thanks,
Dax Kelson
Guru Labs

BTW, the mailman page for this list is giving a "500 Internal Server
Error".



From matt.mulsow at gmail.com  Mon Nov  3 22:42:55 2008
From: matt.mulsow at gmail.com (Matt Mulsow)
Date: Mon, 3 Nov 2008 15:42:55 -0600
Subject: [Udpcast] Spanning Tree/udhcpc failure
In-Reply-To: <1225739643.3417.19.camel@mentor.gurulabs.com>
References: <1225739643.3417.19.camel@mentor.gurulabs.com>
Message-ID: <b3a3e4220811031342q64128e84h6bef4e3d54114882@mail.gmail.com>

I have been having the same issue with not receiving a DHCP response in
time. I too, would appreciate it if the default value were raised or made
tunable with cast-o-matic.
Thanks,
Matt Mulsow

On Mon, Nov 3, 2008 at 1:14 PM, Dax Kelson <dkelson at gurulabs.com> wrote:

> Hello,
>
> Can UDPcast be configured to "try harder/longer" to obtain a DHCP lease?
> We have spanning tree running on our switches and updcast always fails
> to obtain a lease on the first three attempts, then manually telling it
> to try again always results in success. This defeats the "preconfigured"
> setup.
>
> Looking at the docs for udhcpc, I see:
>
> -T,--timeout=N          Try to get a lease for N seconds (default 3)
>
> Could you bump this up by default to say 10 seconds (or have it tunable
> on the cast-o-matic)?
>
> Thanks,
> Dax Kelson
> Guru Labs
>
> BTW, the mailman page for this list is giving a "500 Internal Server
> Error".
>
> _______________________________________________
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
> https://lll.lgl.lu/mailman/listinfo/udpcast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.udpcast.linux.lu/pipermail/udpcast/attachments/20081103/4bfe2407/attachment.html>

From stefan.jaeckel at wiwi.uni-halle.de  Tue Nov  4 09:25:50 2008
From: stefan.jaeckel at wiwi.uni-halle.de (Stefan =?iso-8859-1?q?J=E4ckel?=)
Date: Tue, 04 Nov 2008 10:25:50 +0200
Subject: [Udpcast] Spanning Tree/udhcpc failure
In-Reply-To: <1225739643.3417.19.camel@mentor.gurulabs.com>
References: <1225739643.3417.19.camel@mentor.gurulabs.com>
Message-ID: <200811040925.50336.stefan.jaeckel@wiwi.uni-halle.de>

Hi,

Am Montag 03 November 2008 20:14:03 schrieb Dax Kelson:
> Hello,
>
> Can UDPcast be configured to "try harder/longer" to obtain a DHCP lease?
> We have spanning tree running on our switches and updcast always fails
> to obtain a lease on the first three attempts, then manually telling it
> to try again always results in success. This defeats the "preconfigured"
> setup.
>
> Looking at the docs for udhcpc, I see:
>
> -T,--timeout=N          Try to get a lease for N seconds (default 3)
>
> Could you bump this up by default to say 10 seconds (or have it tunable
> on the cast-o-matic)?
I do not think, that the Spanning Tree Protocol is the reason. Maybe 
the "Portfast" setting on the Switch? The Port for the dhcp-connection (at 
boot time, without portfast) is to slow (port on the switch is not up, while 
asking for the lease).
(sorry for my english)

Greatings.

S. Jäckel

>
> Thanks,
> Dax Kelson
> Guru Labs
>
> BTW, the mailman page for this list is giving a "500 Internal Server
> Error".
>
> _______________________________________________
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
> https://lll.lgl.lu/mailman/listinfo/udpcast




From dkelson at gurulabs.com  Tue Nov  4 16:19:05 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Tue, 4 Nov 2008 08:19:05 -0700
Subject: [Udpcast] Spanning Tree/udhcpc failure
Message-ID: <20081104151914.20FEB1D4D9B@mail.gurulabs.com>

The portfast setting tunes Spanning Tree timers on Cisco switches. 

Without portfast you get the standard (slow) timers.

Not all switches are Cisco, not all switches have a portfast like setting, not all environments have policies that allow changing the spanning tree timers.


-----Original Message-----
From: Stefan Jäckel <stefan.jaeckel at wiwi.uni-halle.de>
Sent: Tuesday, November 04, 2008 1:25 AM
To: udpcast at udpcast.linux.lu
Subject: Re: [Udpcast] Spanning Tree/udhcpc failure

Hi,

Am Montag 03 November 2008 20:14:03 schrieb Dax Kelson:
> Hello,
>
> Can UDPcast be configured to "try harder/longer" to obtain a DHCP lease?
> We have spanning tree running on our switches and updcast always fails
> to obtain a lease on the first three attempts, then manually telling it
> to try again always results in success. This defeats the "preconfigured"
> setup.
>
> Looking at the docs for udhcpc, I see:
>
> -T,--timeout=N          Try to get a lease for N seconds (default 3)
>
> Could you bump this up by default to say 10 seconds (or have it tunable
> on the cast-o-matic)?
I do not think, that the Spanning Tree Protocol is the reason. Maybe 
the "Portfast" setting on the Switch? The Port for the dhcp-connection (at 
boot time, without portfast) is to slow (port on the switch is not up, while 
asking for the lease).
(sorry for my english)

Greatings.

S. Jäckel

>
> Thanks,
> Dax Kelson
> Guru Labs
>
> BTW, the mailman page for this list is giving a "500 Internal Server
> Error".
>
> _______________________________________________
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
> https://lll.lgl.lu/mailman/listinfo/udpcast


_______________________________________________
Udpcast mailing list
Udpcast at udpcast.linux.lu
https://lll.lgl.lu/mailman/listinfo/udpcast



From kyle at kylecordes.com  Tue Nov  4 20:08:45 2008
From: kyle at kylecordes.com (Kyle Cordes)
Date: Tue, 04 Nov 2008 13:08:45 -0600
Subject: [Udpcast] More on the corrupt file problem
In-Reply-To: <490A1676.2010108@knaff.lu>
References: <490A0B5B.2020903@kylecordes.com> <490A1676.2010108@knaff.lu>
Message-ID: <49109DBD.30506@kylecordes.com>

Alain Knaff wrote:

> 
> The strange thing is, we do use udpcast for duplicating entire disks,
> most of which are larger than 50GB by now, and we never did notice any
> ill effect. A large piece of data missing in the middle would have been
> pretty obvious, but we've never have seen any of this so far.


Alain,

By any chance do you typically use it like so on your large files?

udp-receiver | some-process    ?

Contrary to my earlier findings, in ongoing testing I have found that if 
I used it like this:


udp-receiver --file foo

I sometimes get bad results; and things like this:

udp-receiver --pipe "lzop -d" --file foo

also sometimes get bad results.

but I noticed that my real scripts do this:

udp-receiver | lzop -d | pg_restore

and I tested like this:

udp-receiver | lzop -d >foo

... and I get correct results. To 5 or 6 receivers. Every night.

Also, I found that having lzop (or other common compression tool) in the 
  loop acts as a guard against data integrity problems - if udp-receiver 
skip or damages data, it would fail lzop's checksums and make the whole 
process fail.

Thus, it looks like there is some issue that comes in to play with 
--file, but not when simply letting the data fall out on stdout.

I'm sitting the issue down for the moment, but later I may beat on it a 
little more to try to track down the specifics of the failure.

I also think that perhaps the "--pipe" and "--file" features are 
unnecessary; that udp-receiver would be better by being simpler, and 
simply assume that the user will redirect the output where they need it.

-- 
Kyle Cordes
http://kylecordes.com



From alain at knaff.lu  Tue Nov  4 23:09:01 2008
From: alain at knaff.lu (Alain Knaff)
Date: Tue, 04 Nov 2008 23:09:01 +0100
Subject: [Udpcast] More on the corrupt file problem
In-Reply-To: <49109DBD.30506@kylecordes.com>
References: <490A0B5B.2020903@kylecordes.com> <490A1676.2010108@knaff.lu>
	<49109DBD.30506@kylecordes.com>
Message-ID: <4910C7FD.1020303@knaff.lu>

Kyle Cordes wrote:
> Alain Knaff wrote:
> 
>> The strange thing is, we do use udpcast for duplicating entire disks,
>> most of which are larger than 50GB by now, and we never did notice any
>> ill effect. A large piece of data missing in the middle would have been
>> pretty obvious, but we've never have seen any of this so far.
> 
> 
> Alain,
> 
> By any chance do you typically use it like so on your large files?
> 
> udp-receiver | some-process    ?
> 
> Contrary to my earlier findings, in ongoing testing I have found that if 
> I used it like this:
> 
> 
> udp-receiver --file foo
> 
> I sometimes get bad results; and things like this:
> 
> udp-receiver --pipe "lzop -d" --file foo
> 
> also sometimes get bad results.
> 
> but I noticed that my real scripts do this:
> 
> udp-receiver | lzop -d | pg_restore
> 
> and I tested like this:
> 
> udp-receiver | lzop -d >foo
> 
> ... and I get correct results. To 5 or 6 receivers. Every night.
> 
> Also, I found that having lzop (or other common compression tool) in the 
>   loop acts as a guard against data integrity problems - if udp-receiver 
> skip or damages data, it would fail lzop's checksums and make the whole 
> process fail.
> 
> Thus, it looks like there is some issue that comes in to play with 
> --file, but not when simply letting the data fall out on stdout.
> 
> I'm sitting the issue down for the moment, but later I may beat on it a 
> little more to try to track down the specifics of the failure.
> 
> I also think that perhaps the "--pipe" and "--file" features are 
> unnecessary; that udp-receiver would be better by being simpler, and 
> simply assume that the user will redirect the output where they need it.
> 

I have a suspicion that there may be a bug in some versions of the Linux
kernel as far as seek is concerned, that seek is not thread-safe.

Udpcast uses lseek(fd, 0, SEEK_CUR) to read the current file position
for statistics printing. Theoretically, this should not be harmful, as
it should have no influence of file position. But I've got the suspicion
that what this really does it read the file position, do some stuff, and
then _write_back_ that same position: leading to corruption if ever a
read or write in a different thread happened in between (file position
will be reset to just before the read).

Could you try out whether you still get the problem if you comment out
the contents of the printFilePosition function in statistics.c  ?

What if you replace that contents with:

static void printFilePosition(int fd) {
    if(fd != -1) {
	int fd2 = dup(fd);
	if(fd2 != -1) {
#ifdef HAVE_LSEEK64
	    loff_t offset = lseek64(fd2, 0, SEEK_CUR);
	    if(offset != -1)
		printLongNum(offset);
#else
	    off_t offset = lseek(fd2, 0, SEEK_CUR);
	    if(offset != -1)
		fprintf(stderr, "%10d", offset);
#endif
	    close(fd2);
	}
    }
}

(Trying to read the position from a _copy_ of the file descriptor)

Regards,

Alain


From kyle at kylecordes.com  Wed Nov  5 03:52:17 2008
From: kyle at kylecordes.com (Kyle Cordes)
Date: Tue, 04 Nov 2008 20:52:17 -0600
Subject: [Udpcast] More on the corrupt file problem
In-Reply-To: <4910C7FD.1020303@knaff.lu>
References: <490A0B5B.2020903@kylecordes.com> <490A1676.2010108@knaff.lu>
	<49109DBD.30506@kylecordes.com> <4910C7FD.1020303@knaff.lu>
Message-ID: <49110A61.2010802@kylecordes.com>

Alain Knaff wrote:

> I have a suspicion that there may be a bug in some versions of the Linux
> kernel as far as seek is concerned, that seek is not thread-safe.
> 
> Udpcast uses lseek(fd, 0, SEEK_CUR) to read the current file position

I will perform the test you describe.


-- 
Kyle Cordes
http://kylecordes.com


From alain at knaff.lu  Wed Nov  5 16:24:09 2008
From: alain at knaff.lu (Alain Knaff)
Date: Wed, 05 Nov 2008 16:24:09 +0100
Subject: [Udpcast] More on the corrupt file problem
In-Reply-To: <49109DBD.30506@kylecordes.com>
References: <490A0B5B.2020903@kylecordes.com> <490A1676.2010108@knaff.lu>
	<49109DBD.30506@kylecordes.com>
Message-ID: <4911BA99.6000902@knaff.lu>

Kyle Cordes wrote:
> Contrary to my earlier findings, in ongoing testing I have found that if 
> I used it like this:
> 
> 
> udp-receiver --file foo
> 
> I sometimes get bad results; and things like this:
> 
> udp-receiver --pipe "lzop -d" --file foo
> 
> also sometimes get bad results.

Is this also the case if you use the --pipe option with _both_ udp-receiver
and udp-sender? It could well be that synchronization between write and
lseek works correctly if both are performed by 2 different processes (which
is the case when using --pipe, but you'll have to use it on both ends,
because both udp-receiver and udp-sender use the same kind of code for
"uncompressed" printout).

If so, I'll disable the "decompressed" file position printout for the case
without pipe, as in that case it doesn't make sense anyways...

> but I noticed that my real scripts do this:
> 
> udp-receiver | lzop -d | pg_restore
> 
> and I tested like this:
> 
> udp-receiver | lzop -d >foo
> 
> ... and I get correct results. To 5 or 6 receivers. Every night.

Yes, in that case, udp-receiver will write to a pipe, which is not
seekable, and which does is not affected by the bug.

> Also, I found that having lzop (or other common compression tool) in the 
>   loop acts as a guard against data integrity problems - if udp-receiver 
> skip or damages data, it would fail lzop's checksums and make the whole 
> process fail.

exactly. However, if the bug still exists even with the --pipe option, it
would unfortunately affect the data _before_ it is compressed by lzop (or
_after_ it has been decompressed by lzop -d), so that would not help here...

Regards,

Alain



From Antuori.Gianluigi.Wintime at ansaldobreda.it  Fri Nov  7 09:57:56 2008
From: Antuori.Gianluigi.Wintime at ansaldobreda.it (Autuori Gianluigi)
Date: Fri, 7 Nov 2008 09:57:56 +0100
Subject: [Udpcast] disk device problem
Message-ID: <A691B9541CD614449A7702B21C5BBD5903D889A5@abnaex01.ab.ansaldobreda.it>

Hello Alain,

I need to use udpcast and I use cast-o-matic, the web-based udpcast
configurator to make it.

I attach log files about my hw and sw configuration made with slax
6.0.7.

I choose:

- etherboot image

- e100: Intel(R) PRO/100 Network

The pc boots from etherboot and receives image of udpcast, but I can't
find any disk device on my pc.

Otherwise Slax finds hda and Gentoo finds sda1.

What is wrong?

Thanks

Gianluigi

 


--------------------------------------------------------------------------------
Questo messaggio e-mail e ogni documento ad esso eventualmente allegato puo' avere carattere riservato ed essere tutelato da segreto. Esso,comunque, e'
ad esclusivo utilizzo del destinatario in indirizzo. Qualora non foste il destinatario del messaggio vi preghiamo di volerci avvertire immediatamente per e-mail o telefono e di cancellare il presente messaggio e ogni eventuale allegato dal vostro sistema. E' vietata la duplicazione o l'utilizzo per qualunque fine del messaggio e di ogni allegato, nonche' la loro divulgazione, distribuzione o inoltro a terzi senza l'espressa autorizzazione del mittente. In ragione del mezzo di trasmissione utilizzato, il mittente non assume alcuna responsabilita' sulla segretezza/riservatezza delle informazioni contenute nel messaggio e nei relativi allegati. 

This e-mail and any file transmitted with it may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. If you are not the intended recipient of this e-mail, please do not read it, notify us immediately by e-mail or by telephone and then delete this message and any file attached from your system. You should not copy or use it for any purpose, disclose the contents of the same to any other person or forward it without express permission.
Considering the means of transmission, we do not undertake any liability with respect to the secrecy and confidentiality of the information contained in this e-mail and its attachments.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.udpcast.linux.lu/pipermail/udpcast/attachments/20081107/bc9de500/attachment.html>

From alain at knaff.lu  Fri Nov  7 16:17:11 2008
From: alain at knaff.lu (Alain Knaff)
Date: Fri, 07 Nov 2008 16:17:11 +0100
Subject: [Udpcast] disk device problem
In-Reply-To: <A691B9541CD614449A7702B21C5BBD5903D889A5@abnaex01.ab.ansaldobreda.it>
References: <A691B9541CD614449A7702B21C5BBD5903D889A5@abnaex01.ab.ansaldobreda.it>
Message-ID: <49145BF7.9000906@knaff.lu>

Autuori Gianluigi wrote:
> Hello Alain,
> 
> I need to use udpcast and I use cast-o-matic, the web-based udpcast
> configurator to make it.
> 
> I attach log files about my hw and sw configuration made with slax
> 6.0.7.

Somehow they didn't make it...

> I choose:
> 
> - etherboot image
> 
> - e100: Intel(R) PRO/100 Network
> 
> The pc boots from etherboot and receives image of udpcast, but I can't
> find any disk device on my pc.

Probably a non-standard or too recent SATA controller...


> Otherwise Slax finds hda and Gentoo finds sda1.

Check in gentoo (with lsmod) which module supplies sda1 functionality.

> 
> What is wrong?
> 
> Thanks
> 
> Gianluigi

Regards,

Alain


From stephane.boireau at free.fr  Fri Nov 14 11:22:27 2008
From: stephane.boireau at free.fr (Stephane Boireau)
Date: Fri, 14 Nov 2008 11:22:27 +0100
Subject: [Udpcast] Udpcast et Macintosh?
Message-ID: <200811141122.27281.stephane.boireau@free.fr>

Hi,

Someone asked me if udcast is ok to clone MacIntosh...
... does anybody know?

No such computer at home or work to try myself...


Regards.
-- 
Stephane Boireau.


From alain at knaff.lu  Mon Nov 17 20:50:20 2008
From: alain at knaff.lu (Alain Knaff)
Date: Mon, 17 Nov 2008 20:50:20 +0100
Subject: [Udpcast] More on the corrupt file problem
In-Reply-To: <49110A61.2010802@kylecordes.com>
References: <490A0B5B.2020903@kylecordes.com>
	<490A1676.2010108@knaff.lu>	<49109DBD.30506@kylecordes.com>
	<4910C7FD.1020303@knaff.lu> <49110A61.2010802@kylecordes.com>
Message-ID: <4921CAFC.3020605@knaff.lu>

I've just released udpcast 20081116, which has a work-around for that
llseek bug in the kernel. The bug has also been reported to the kernel
mailinglist and will (hopefully) be fixed in one of the next kernels...

Moreover, udpcast now has a new --stat-period flag, which allows to
specify how often statistics are refreshed (expressed in milliseconds,
default is half a second)

Regards,

Alain



From alain at knaff.lu  Mon Nov 17 20:53:37 2008
From: alain at knaff.lu (Alain Knaff)
Date: Mon, 17 Nov 2008 20:53:37 +0100
Subject: [Udpcast] Spanning Tree/udhcpc failure
In-Reply-To: <1225739643.3417.19.camel@mentor.gurulabs.com>
References: <1225739643.3417.19.camel@mentor.gurulabs.com>
Message-ID: <4921CBC1.6020406@knaff.lu>

Dax Kelson wrote:
> -T,--timeout=N          Try to get a lease for N seconds (default 3)
> 
> Could you bump this up by default to say 10 seconds (or have it tunable
> on the cast-o-matic)?

I've now bumped it to 11 seconds (in order to take some slack...), and
noticed that it actually retries 3 times (giving 33 seconds for the
switch to react)

Alain


From kyle at kylecordes.com  Tue Nov 18 01:33:34 2008
From: kyle at kylecordes.com (Kyle Cordes)
Date: Mon, 17 Nov 2008 18:33:34 -0600
Subject: [Udpcast] More on the corrupt file problem
In-Reply-To: <4921CAFC.3020605@knaff.lu>
References: <490A0B5B.2020903@kylecordes.com>
	<490A1676.2010108@knaff.lu>	<49109DBD.30506@kylecordes.com>
	<4910C7FD.1020303@knaff.lu> <49110A61.2010802@kylecordes.com>
	<4921CAFC.3020605@knaff.lu>
Message-ID: <49220D5E.70202@kylecordes.com>

Alain Knaff wrote:
> I've just released udpcast 20081116, which has a work-around for that
> llseek bug in the kernel. The bug has also been reported to the kernel
> mailinglist and will (hopefully) be fixed in one of the next kernels...
> 
> Moreover, udpcast now has a new --stat-period flag, which allows to
> specify how often statistics are refreshed (expressed in milliseconds,
> default is half a second)


Excellent, I'm glad to hear this is already taken care of, I'll scratch 
the followup test I had in mind off my list :-)

I wonder who I would need to ask, to get the updated UDPCast in to 
Debian/Ubuntu - the version in there now is from 2004 (!).

-- 
Kyle Cordes
http://kylecordes.com


From alain at knaff.lu  Tue Nov 18 08:25:12 2008
From: alain at knaff.lu (Alain Knaff)
Date: Tue, 18 Nov 2008 08:25:12 +0100
Subject: [Udpcast] More on the corrupt file problem
In-Reply-To: <49220D5E.70202@kylecordes.com>
References: <490A0B5B.2020903@kylecordes.com>
	<490A1676.2010108@knaff.lu>	<49109DBD.30506@kylecordes.com>
	<4910C7FD.1020303@knaff.lu> <49110A61.2010802@kylecordes.com>
	<4921CAFC.3020605@knaff.lu> <49220D5E.70202@kylecordes.com>
Message-ID: <49226DD8.9040605@knaff.lu>

Kyle Cordes wrote:
> I wonder who I would need to ask, to get the updated UDPCast in to
> Debian/Ubuntu - the version in there now is from 2004 (!).
> 

Try Thomas Pospisek (tpo2 at sourcepole.ch) or alternatively download the
.deb directly from udpcast.linux.lu

Regards,

Alain



From freggy at gmail.com  Thu Nov 20 12:54:16 2008
From: freggy at gmail.com (Frederik)
Date: Thu, 20 Nov 2008 12:54:16 +0100
Subject: [Udpcast] Installation of rateGovernor.h
Message-ID: <28d495d10811200354w305198d6u75dc4c9814b49ed2@mail.gmail.com>

udpcast now installs the file /usr/include/rateGovernor.h. What's the
purpose of this file? Can it be used by external programs, so that it
has to be installed?

-- 
Frederik


From alain at knaff.lu  Sun Nov 23 20:23:26 2008
From: alain at knaff.lu (Alain Knaff)
Date: Sun, 23 Nov 2008 20:23:26 +0100
Subject: [Udpcast] Installation of rateGovernor.h
In-Reply-To: <28d495d10811200354w305198d6u75dc4c9814b49ed2@mail.gmail.com>
References: <28d495d10811200354w305198d6u75dc4c9814b49ed2@mail.gmail.com>
Message-ID: <4929ADAE.6090701@knaff.lu>

Frederik wrote:
> udpcast now installs the file /usr/include/rateGovernor.h. What's the
> purpose of this file? Can it be used by external programs, so that it
> has to be installed?
> 

Yes, as described in
http://lll.lgl.lu/pipermail/udpcast/2008-September/000887.html, this is
for use by an external program, a "rate governor" that decides how fast
to send data. This is useful for instance when sending data over
satellite, so that the satelitte interface device ("multiprotocol
encapsulator") can instruct udp-sender to slow down the transmission if
less satellite bandwidth is available.

Regards,

Alain


From dkelson at gurulabs.com  Sun Nov 23 21:32:25 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Sun, 23 Nov 2008 13:32:25 -0700
Subject: [Udpcast] Spanning Tree/udhcpc failure
Message-ID: <20081123203233.89D001DA8C2@mail.gurulabs.com>

I tested this and it works. Thanks! Sorry for the top post.

Dax Kelson
Guru Labs


-----Original Message-----
From: Alain Knaff <alain at knaff.lu>
Sent: Monday, November 17, 2008 12:53 PM
To: Dax Kelson <dkelson at gurulabs.com>
Cc: udpcast at udpcast.linux.lu
Subject: Re: [Udpcast] Spanning Tree/udhcpc failure

Dax Kelson wrote:
> -T,--timeout=N          Try to get a lease for N seconds (default 3)
> 
> Could you bump this up by default to say 10 seconds (or have it tunable
> on the cast-o-matic)?

I've now bumped it to 11 seconds (in order to take some slack...), and
noticed that it actually retries 3 times (giving 33 seconds for the
switch to react)

Alain



From mikes at kuentos.guam.net  Sat Nov 29 07:50:26 2008
From: mikes at kuentos.guam.net (Michael D. Setzer II)
Date: Sat, 29 Nov 2008 16:50:26 +1000
Subject: [Udpcast] Problem with 8139cp and 8139too
Message-ID: <4930E632.19868.91B40B0@mikes.kuentos.guam.net>

I was trying to make an image that would work with all our systems, but have 
run into a problem.

At first I tried building everything, and that seemed to work, but we have a lab 
with most machines have 3com cards, but some have the on board 8139 
cards. The auto script fails with a udpc spript problem. You can press the esc 
key and go back, and it shows the 8139cp and the 8139too. It you select the 
8139too, and click on, it will go thru, and eventually work, but requires enters 
on everything. I don't think we have anything with 8139cp cards, so I went 
back and redid the build, but this time I unchecked the 8139cp. Redid the 
process and got the same results. It doesn't seem to have the 8139cp.ko file, 
but it still seems to try it. 

All the machines had 3com cards, but a couple have failed, so we switched 
those to use the onboard, which seems to be as good.


+----------------------------------------------------------+
  Michael D. Setzer II -  Computer Science Instructor      
  Guam Community College  Computer Center                  
  mailto:mikes at kuentos.guam.net                            
  mailto:msetzerii at gmail.com
  http://www.guam.net/home/mikes
  Guam - Where America's Day Begins                        
+----------------------------------------------------------+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned:  19,471
Processing time:  32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

BOINC at HOME CREDITS
SETI 6,887,276.9695 | EINSTEIN 2,134,564.5709 | ROSETTA 
694,861.8863



From alain at knaff.lu  Sun Nov 30 19:49:56 2008
From: alain at knaff.lu (Alain Knaff)
Date: Sun, 30 Nov 2008 19:49:56 +0100
Subject: [Udpcast] Problem with 8139cp and 8139too
In-Reply-To: <4930E632.19868.91B40B0@mikes.kuentos.guam.net>
References: <4930E632.19868.91B40B0@mikes.kuentos.guam.net>
Message-ID: <4932E054.10707@knaff.lu>

Michael D. Setzer II wrote:
> I was trying to make an image that would work with all our systems, but have 
> run into a problem.
> 
> At first I tried building everything, and that seemed to work, but we have a lab 
> with most machines have 3com cards, but some have the on board 8139 
> cards. The auto script fails with a udpc spript problem. You can press the esc 
> key and go back, and it shows the 8139cp and the 8139too. It you select the 
> 8139too, and click on, it will go thru, and eventually work, but requires enters 
> on everything. I don't think we have anything with 8139cp cards, so I went 
> back and redid the build, but this time I unchecked the 8139cp. Redid the 
> process and got the same results. It doesn't seem to have the 8139cp.ko file, 
> but it still seems to try it. 
> 
> All the machines had 3com cards, but a couple have failed, so we switched 
> those to use the onboard, which seems to be as good.

Yes, by default the Udpcast boot menu includes in its suggestion _all_
drivers that match the current card, even if they are not present on the
boot media. This was intended to make it possible to have modules on a
second disk.

In today's version, I changed it so that all drivers are still listed,
but that those that are present on the media come first. So leaving away
troublesome drivers should work now

Regards,

Alain