With integrated ALi/ULi M5261 ethernet controller using tulip driver,
autonegotation doesn't work and card is forced to 10 Mbps half-duplex mode.
I found two problems with tulip driver regarding ULi5261.
1. In tulip_up() media selection does not work properly. No media from
EEPROM media list is set as default in ULi's EEPROM. In such case tulip
driver searches for first non-fullduplex media.
I have no idea why the search is not performed for MII capable media first.
Maybe because of problems with some other cards?
EEPROM media list is reported to be as follows:
tulip0: EEPROM default media type Autosense.
tulip0: MII interface PHY 1, setup/reset sequences 0/2 long, capabilities 00 01.
tulip0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
tulip0: Index #1 - Media 10baseT (#0) described by a <unknown> (128) block.
tulip0: Index #2 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
tulip0: Index #3 - Media 10base2 (#1) described by a 21140 non-MII (0) block.
tulip0: Index #4 - Media 10baseT-FDX (#4) described by a 21140 non-MII (0) block.
tulip0: Index #5 - Media 100baseTx-FDX (#5) described by a 21140 non-MII (0) block.
I added code that performs search for MII capable media in case of ULi5261
card. Shouldn't it be performed generally?
2. PHY chip DM9161E used on my M5261 seems to claim (in BMCR register) that
autonegotiation is enabled after initialization, but it needs to set
BMCR_ANRESTART for autonegotiation to work. Without forcing of restart of
autonegotiation, MII_LPA returns always 0.
Is there any way to detect that DM9161E is used? It may be used with another
ethernet cards (and there may be another PHY used in M5261 as well), so
restarting autonegotiation in case of ULi5261 doesn't seem to be
a solution.
The only way I see is to always restart autonegotiation in tulip_find_mii().
It probably has the side-effect that other cards with autonegotiation
enabled by default will perform autonegotiation twice.
Thanks for your suggestions.
--- linux-2.6.12-rc3/drivers/net/tulip/media.c
+++ linux-2.6.12-rc3-patched/drivers/net/tulip/media.c
@@ -517,10 +517,11 @@ void __devinit tulip_find_mii (struct ne
/* Enable autonegotiation: some boards default to off. */
if (tp->default_port == 0) {
new_bmcr = mii_reg0 | BMCR_ANENABLE;
- if (new_bmcr != mii_reg0) {
- new_bmcr |= BMCR_ANRESTART;
- ane_switch = 1;
- }
+ /* DM9161E PHY seems to need to restart
+ * autonegotiation even if it defaults to enabled.
+ */
+ new_bmcr |= BMCR_ANRESTART;
+ ane_switch = 1;
}
/* ...or disable nway, if forcing media */
else {
--- linux-2.6.12-rc3/drivers/net/tulip/tulip_core.c
+++ linux-2.6.12-rc3-patched/drivers/net/tulip/tulip_core.c
@@ -383,6 +383,11 @@ static void tulip_up(struct net_device *
goto media_picked;
}
}
+ if (tp->chip_id == ULI526X) {
+ for (i = tp->mtable->leafcount - 1; i >= 0; i--)
+ if (tulip_media_cap[tp->mtable->mleaf[i].media] & MediaIsMII)
+ goto media_picked;
+ }
/* Start sensing first non-full-duplex media. */
for (i = tp->mtable->leafcount - 1;
(tulip_media_cap[tp->mtable->mleaf[i].media] & MediaAlwaysFD) && i > 0; i--)
--
Jiri Benc
SUSE Labs
Hi!
Recently I had similar problems as you described below, that's how I
found your email. (My exact problem is that there's no link when I plug
in a cable, reloading the driver a few times usually helps.)
The problem is, that since you made the patch, the uli526x driver has
been split out from the tulip driver.
Do you know anything about the current state of the uli526x driver
regarding the problems you tried patch?
Thanks in advance,
Balazs Pozsar
On Wed, Apr 27, 2005 at 12:49:11PM +0200, Jiri Benc wrote:
> With integrated ALi/ULi M5261 ethernet controller using tulip driver,
> autonegotation doesn't work and card is forced to 10 Mbps half-duplex mode.
>
> I found two problems with tulip driver regarding ULi5261.
>
> 1. In tulip_up() media selection does not work properly. No media from
> EEPROM media list is set as default in ULi's EEPROM. In such case tulip
> driver searches for first non-fullduplex media.
>
> I have no idea why the search is not performed for MII capable media first.
> Maybe because of problems with some other cards?
>
> EEPROM media list is reported to be as follows:
>
> tulip0: EEPROM default media type Autosense.
> tulip0: MII interface PHY 1, setup/reset sequences 0/2 long, capabilities 00 01.
> tulip0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
> tulip0: Index #1 - Media 10baseT (#0) described by a <unknown> (128) block.
> tulip0: Index #2 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
> tulip0: Index #3 - Media 10base2 (#1) described by a 21140 non-MII (0) block.
> tulip0: Index #4 - Media 10baseT-FDX (#4) described by a 21140 non-MII (0) block.
> tulip0: Index #5 - Media 100baseTx-FDX (#5) described by a 21140 non-MII (0) block.
>
> I added code that performs search for MII capable media in case of ULi5261
> card. Shouldn't it be performed generally?
>
> 2. PHY chip DM9161E used on my M5261 seems to claim (in BMCR register) that
> autonegotiation is enabled after initialization, but it needs to set
> BMCR_ANRESTART for autonegotiation to work. Without forcing of restart of
> autonegotiation, MII_LPA returns always 0.
>
> Is there any way to detect that DM9161E is used? It may be used with another
> ethernet cards (and there may be another PHY used in M5261 as well), so
> restarting autonegotiation in case of ULi5261 doesn't seem to be
> a solution.
>
> The only way I see is to always restart autonegotiation in tulip_find_mii().
> It probably has the side-effect that other cards with autonegotiation
> enabled by default will perform autonegotiation twice.
>
> Thanks for your suggestions.
>
>
> --- linux-2.6.12-rc3/drivers/net/tulip/media.c
> +++ linux-2.6.12-rc3-patched/drivers/net/tulip/media.c
> @@ -517,10 +517,11 @@ void __devinit tulip_find_mii (struct ne
> /* Enable autonegotiation: some boards default to off. */
> if (tp->default_port == 0) {
> new_bmcr = mii_reg0 | BMCR_ANENABLE;
> - if (new_bmcr != mii_reg0) {
> - new_bmcr |= BMCR_ANRESTART;
> - ane_switch = 1;
> - }
> + /* DM9161E PHY seems to need to restart
> + * autonegotiation even if it defaults to enabled.
> + */
> + new_bmcr |= BMCR_ANRESTART;
> + ane_switch = 1;
> }
> /* ...or disable nway, if forcing media */
> else {
> --- linux-2.6.12-rc3/drivers/net/tulip/tulip_core.c
> +++ linux-2.6.12-rc3-patched/drivers/net/tulip/tulip_core.c
> @@ -383,6 +383,11 @@ static void tulip_up(struct net_device *
> goto media_picked;
> }
> }
> + if (tp->chip_id == ULI526X) {
> + for (i = tp->mtable->leafcount - 1; i >= 0; i--)
> + if (tulip_media_cap[tp->mtable->mleaf[i].media] & MediaIsMII)
> + goto media_picked;
> + }
> /* Start sensing first non-full-duplex media. */
> for (i = tp->mtable->leafcount - 1;
> (tulip_media_cap[tp->mtable->mleaf[i].media] & MediaAlwaysFD) && i > 0; i--)
>
>
> --
> Jiri Benc
> SUSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
pozsy
On Tue, 15 Aug 2006 11:25:52 +0200, Pozsar Balazs wrote:
> Recently I had similar problems as you described below, that's how I
> found your email. (My exact problem is that there's no link when I plug
> in a cable, reloading the driver a few times usually helps.)
> The problem is, that since you made the patch, the uli526x driver has
> been split out from the tulip driver.
> Do you know anything about the current state of the uli526x driver
> regarding the problems you tried patch?
I use the card with new (split out) uli526x driver with no problem. Your
problems are probably unrelated.
Jiri
--
Jiri Benc
SUSE Labs
On Wed, Aug 16, 2006 at 07:11:39PM +0200, Jiri Benc wrote:
> On Tue, 15 Aug 2006 11:25:52 +0200, Pozsar Balazs wrote:
> > Recently I had similar problems as you described below, that's how I
> > found your email. (My exact problem is that there's no link when I plug
> > in a cable, reloading the driver a few times usually helps.)
> > The problem is, that since you made the patch, the uli526x driver has
> > been split out from the tulip driver.
> > Do you know anything about the current state of the uli526x driver
> > regarding the problems you tried patch?
>
> I use the card with new (split out) uli526x driver with no problem. Your
> problems are probably unrelated.
So, just to make it clear: if you boot without cable plugged in, let
the driver load, and then plug the cable in, do you have link?
For me, it does not have link until I rmmod the module.
Do you have any idea what the problem could be, or could I send you any
info that would help debug it?
Thanks,
--
pozsy
Am Mittwoch 16 August 2006 19:43 schrieb Pozsar Balazs:
> On Wed, Aug 16, 2006 at 07:11:39PM +0200, Jiri Benc wrote:
> > On Tue, 15 Aug 2006 11:25:52 +0200, Pozsar Balazs wrote:
> > > Recently I had similar problems as you described below, that's how I
> > > found your email. (My exact problem is that there's no link when I plug
> > > in a cable, reloading the driver a few times usually helps.)
> > > The problem is, that since you made the patch, the uli526x driver has
> > > been split out from the tulip driver.
> > > Do you know anything about the current state of the uli526x driver
> > > regarding the problems you tried patch?
> >
> > I use the card with new (split out) uli526x driver with no problem. Your
> > problems are probably unrelated.
>
> So, just to make it clear: if you boot without cable plugged in, let
> the driver load, and then plug the cable in, do you have link?
> For me, it does not have link until I rmmod the module.
Same here.
> Do you have any idea what the problem could be, or could I send you any
> info that would help debug it?
I actually played a bit with the code and what fails is uli526x_sense_speed
in that way that phy_mode & 024 is 0 (and stays 0). But I don't understand
why...
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Wed, Aug 16, 2006 at 08:02:02PM +0200, Prakash Punnoor wrote:
> Am Mittwoch 16 August 2006 19:43 schrieb Pozsar Balazs:
> > On Wed, Aug 16, 2006 at 07:11:39PM +0200, Jiri Benc wrote:
> > > On Tue, 15 Aug 2006 11:25:52 +0200, Pozsar Balazs wrote:
> > > > Recently I had similar problems as you described below, that's how I
> > > > found your email. (My exact problem is that there's no link when I plug
> > > > in a cable, reloading the driver a few times usually helps.)
> > > > The problem is, that since you made the patch, the uli526x driver has
> > > > been split out from the tulip driver.
> > > > Do you know anything about the current state of the uli526x driver
> > > > regarding the problems you tried patch?
> > >
> > > I use the card with new (split out) uli526x driver with no problem. Your
> > > problems are probably unrelated.
> >
> > So, just to make it clear: if you boot without cable plugged in, let
> > the driver load, and then plug the cable in, do you have link?
> > For me, it does not have link until I rmmod the module.
>
> Same here.
The most weird thing is that, when I _rmmod_ the module, the link leds
will show a link, _before_ I even re-modprobe it! So somehow the removal
(or even an unbind via the sysfs interface) "resets" it.
> > Do you have any idea what the problem could be, or could I send you any
> > info that would help debug it?
>
> I actually played a bit with the code and what fails is uli526x_sense_speed
> in that way that phy_mode & 024 is 0 (and stays 0). But I don't understand
> why...
I made the same discovery. According to mii.h bit 0x20 would mean
"Auto-negotiation complete" and bit 0x04 would mean "Link status".
--
pozsy
On Wed, Aug 16, 2006 at 09:53:45PM +0200, Pozsar Balazs wrote:
> On Wed, Aug 16, 2006 at 08:02:02PM +0200, Prakash Punnoor wrote:
> > Am Mittwoch 16 August 2006 19:43 schrieb Pozsar Balazs:
> >
> > > So, just to make it clear: if you boot without cable plugged in, let
> > > the driver load, and then plug the cable in, do you have link?
> > > For me, it does not have link until I rmmod the module.
> >
> > Same here.
>
> The most weird thing is that, when I _rmmod_ the module, the link leds
> will show a link, _before_ I even re-modprobe it! So somehow the removal
> (or even an unbind via the sysfs interface) "resets" it.
Hey folks,
Added to my to-do list. Let me know if you figure out anything else.
-VAL
On Fri, Aug 18, 2006 at 05:16:41PM -0700, Valerie Henson wrote:
> On Wed, Aug 16, 2006 at 09:53:45PM +0200, Pozsar Balazs wrote:
> > On Wed, Aug 16, 2006 at 08:02:02PM +0200, Prakash Punnoor wrote:
> > > Am Mittwoch 16 August 2006 19:43 schrieb Pozsar Balazs:
> > >
> > > > So, just to make it clear: if you boot without cable plugged in, let
> > > > the driver load, and then plug the cable in, do you have link?
> > > > For me, it does not have link until I rmmod the module.
> > >
> > > Same here.
> >
> > The most weird thing is that, when I _rmmod_ the module, the link leds
> > will show a link, _before_ I even re-modprobe it! So somehow the removal
> > (or even an unbind via the sysfs interface) "resets" it.
>
> Hey folks,
>
> Added to my to-do list. Let me know if you figure out anything else.
Actually, I managed to fix it, here's the patch:
Signed-off-by: Pozsar Balazs <[email protected]>
--- a/drivers/net/tulip/uli526x.c 2006-07-15 21:00:43.000000000 +0200
+++ a/drivers/net/tulip/uli526x.c 2006-08-18 15:41:00.000000000 +0200
@@ -515,7 +515,8 @@
phy_reg_reset = phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id);
phy_reg_reset = (phy_reg_reset | 0x8000);
phy_write(db->ioaddr, db->phy_addr, 0, phy_reg_reset, db->chip_id);
- udelay(500);
+ while (phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id) & 0x8000)
+ udelay(500);
/* Process Phyxcer Media Mode */
uli526x_set_phyxcer(db);
--
pozsy
Pozsar Balazs wrote:
> --- a/drivers/net/tulip/uli526x.c 2006-07-15 21:00:43.000000000 +0200
> +++ a/drivers/net/tulip/uli526x.c 2006-08-18 15:41:00.000000000 +0200
> @@ -515,7 +515,8 @@
> phy_reg_reset = phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id);
> phy_reg_reset = (phy_reg_reset | 0x8000);
> phy_write(db->ioaddr, db->phy_addr, 0, phy_reg_reset, db->chip_id);
> - udelay(500);
> + while (phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id) & 0x8000)
> + udelay(500);
You never want an infinite loop in a driver. If, for example, the
hardware is wedged or removed, registers will return all 1's, leading
this loop to never end.
Jeff
On Sat, Aug 19, 2006 at 10:36:17AM -0400, Jeff Garzik wrote:
> Pozsar Balazs wrote:
> >--- a/drivers/net/tulip/uli526x.c 2006-07-15 21:00:43.000000000 +0200
> >+++ a/drivers/net/tulip/uli526x.c 2006-08-18 15:41:00.000000000 +0200
> >@@ -515,7 +515,8 @@
> > phy_reg_reset = phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id);
> > phy_reg_reset = (phy_reg_reset | 0x8000);
> > phy_write(db->ioaddr, db->phy_addr, 0, phy_reg_reset, db->chip_id);
> >- udelay(500);
> >+ while (phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id) & 0x8000)
> >+ udelay(500);
>
> You never want an infinite loop in a driver. If, for example, the
> hardware is wedged or removed, registers will return all 1's, leading
> this loop to never end.
Does this seem better?
Signed-off-by: Pozsar Balazs <[email protected]>
Fix uli526x initialization
--- a/drivers/net/tulip/uli526x.c 2006-08-21 10:57:43.000000000 +0200
+++ a/drivers/net/tulip/uli526x.c 2006-08-21 11:01:37.000000000 +0200
@@ -486,6 +486,7 @@
u8 phy_tmp;
u16 phy_value;
u16 phy_reg_reset;
+ int resetwait = 10;
ULI526X_DBUG(0, "uli526x_init()", 0);
@@ -515,7 +516,11 @@
phy_reg_reset = phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id);
phy_reg_reset = (phy_reg_reset | 0x8000);
phy_write(db->ioaddr, db->phy_addr, 0, phy_reg_reset, db->chip_id);
- udelay(500);
+ while (resetwait-- > 0) {
+ if (!(phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id) & 0x8000))
+ break;
+ udelay(500);
+ }
/* Process Phyxcer Media Mode */
uli526x_set_phyxcer(db);
--
pozsy
Hi Pozsar,
On Mon, Aug 21, 2006 at 11:03:51AM +0200, Pozsar Balazs wrote:
>
> Does this seem better?
>
> Signed-off-by: Pozsar Balazs <[email protected]>
>
> Fix uli526x initialization
>
>
> --- a/drivers/net/tulip/uli526x.c 2006-08-21 10:57:43.000000000 +0200
> +++ a/drivers/net/tulip/uli526x.c 2006-08-21 11:01:37.000000000 +0200
> @@ -486,6 +486,7 @@
> u8 phy_tmp;
> u16 phy_value;
> u16 phy_reg_reset;
> + int resetwait = 10;
>
> ULI526X_DBUG(0, "uli526x_init()", 0);
>
> @@ -515,7 +516,11 @@
> phy_reg_reset = phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id);
> phy_reg_reset = (phy_reg_reset | 0x8000);
> phy_write(db->ioaddr, db->phy_addr, 0, phy_reg_reset, db->chip_id);
> - udelay(500);
> + while (resetwait-- > 0) {
> + if (!(phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id) & 0x8000))
> + break;
> + udelay(500);
> + }
>
> /* Process Phyxcer Media Mode */
> uli526x_set_phyxcer(db);
Thanks for writing up this patch. udelay(500) seems a touch
heavyweight, however. Would you mind experimenting a bit to see what
the delay typically ends up being? Just add a KERN_DEBUG message
printing out resetwait and then fiddle with the udelay granularity.
-VAL
On Tue, Aug 22, 2006 at 11:28:21PM -0700, Valerie Henson wrote:
> Hi Pozsar,
>
> On Mon, Aug 21, 2006 at 11:03:51AM +0200, Pozsar Balazs wrote:
> >
> > Does this seem better?
> >
> > Signed-off-by: Pozsar Balazs <[email protected]>
> >
> > Fix uli526x initialization
> >
> >
> > --- a/drivers/net/tulip/uli526x.c 2006-08-21 10:57:43.000000000 +0200
> > +++ a/drivers/net/tulip/uli526x.c 2006-08-21 11:01:37.000000000 +0200
> > @@ -486,6 +486,7 @@
> > u8 phy_tmp;
> > u16 phy_value;
> > u16 phy_reg_reset;
> > + int resetwait = 10;
> >
> > ULI526X_DBUG(0, "uli526x_init()", 0);
> >
> > @@ -515,7 +516,11 @@
> > phy_reg_reset = phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id);
> > phy_reg_reset = (phy_reg_reset | 0x8000);
> > phy_write(db->ioaddr, db->phy_addr, 0, phy_reg_reset, db->chip_id);
> > - udelay(500);
> > + while (resetwait-- > 0) {
> > + if (!(phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id) & 0x8000))
> > + break;
> > + udelay(500);
> > + }
> >
> > /* Process Phyxcer Media Mode */
> > uli526x_set_phyxcer(db);
>
> Thanks for writing up this patch. udelay(500) seems a touch
> heavyweight, however.
I don't really understand, 500 microsec is really not that much time...
> Would you mind experimenting a bit to see what
> the delay typically ends up being? Just add a KERN_DEBUG message
> printing out resetwait and then fiddle with the udelay granularity.
The funny thing is that it seems the _first_ phy_read call always
returns only when the 0x8000 bit is gone (I got this while loop from the
xircom_tulip driver).
I didn't have time yet to test how long it takes without the phy_read to
make it work (ie if we would only raise udelay(500) to some bigger
value).
--
pozsy
On Wed, Aug 23, 2006 at 11:19:19AM +0200, Pozsar Balazs wrote:
>
> The funny thing is that it seems the _first_ phy_read call always
> returns only when the 0x8000 bit is gone (I got this while loop from the
> xircom_tulip driver).
That's pretty much the answer I was suspecting. Sounds like the read
is doing some sort of flush. Unfortunately I can't find any docs, so
I'd rather keep things as close to the old code as possible to avoid
breaking other cards. Does something like this also work?
udelay(500); /* Paranoia - phy_read() may be sufficient */
if (phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id) & 0x8000)
printk("some useful error message");
-VAL
Hi.
On Wed, 2006-08-23 at 09:56 -0700, Valerie Henson wrote:
> On Wed, Aug 23, 2006 at 11:19:19AM +0200, Pozsar Balazs wrote:
> >
> > The funny thing is that it seems the _first_ phy_read call always
> > returns only when the 0x8000 bit is gone (I got this while loop from the
> > xircom_tulip driver).
>
> That's pretty much the answer I was suspecting. Sounds like the read
> is doing some sort of flush. Unfortunately I can't find any docs, so
> I'd rather keep things as close to the old code as possible to avoid
> breaking other cards. Does something like this also work?
>
> udelay(500); /* Paranoia - phy_read() may be sufficient */
> if (phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id) & 0x8000)
> printk("some useful error message");
>
I got docs from uli earlier in the year, I just never got around to
using them to the extent I intended, and then I switched to working
wirelessly most of the time. I didn't have to sign an NDA to get the
PDF, so it should be okay for me to distribute it, right? If that's the
case, then assuming LKML won't take a PDF, I'll reply again after giving
people time to tell me I'm wrong, removing LKML and giving everyone
directly emailed a copy (it's not huge).
Regards,
Nigel
Hi everyone.
I looked again at the PDF before sending it, and it does say
"Preliminary, Confidential, Proprietary" in the header. I therefore also
checked again all the email I received from Peer, and he made no mention
of it having that status. I thought I'd mention that though: someone
might see that too and have concerns.
To help clarify before I send it, I've added Peer to the ccs now so that
he can at least have the opportunity to have input.
Peer: I don't know if you'll have seen the rest of the conversation, so
let me fill you in: I never got the opportunity to finish the work on
adding power management support, and other people are doing work on the
driver now. Is it alright for me to forward the PDF datasheet you gave
to me?)
Regards,
Nigel
Am Samstag 19 August 2006 02:16 schrieb Valerie Henson:
> Hey folks,
>
> Added to my to-do list. Let me know if you figure out anything else.
As it comes back to my mind: Last time I tested dhcpcd doesn't work. dhclient
does, but takes a lot of time. (The dhcp server is debian based.) Other cards
don't have a problem. They get their ip assigned fast and with either dhcpocd
or dhclient.
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Wed, Aug 23, 2006 at 06:59:32PM +0200, Prakash Punnoor wrote:
> Am Samstag 19 August 2006 02:16 schrieb Valerie Henson:
> > Hey folks,
> >
> > Added to my to-do list. Let me know if you figure out anything else.
>
> As it comes back to my mind: Last time I tested dhcpcd doesn't work. dhclient
> does, but takes a lot of time. (The dhcp server is debian based.) Other cards
> don't have a problem. They get their ip assigned fast and with either dhcpocd
> or dhclient.
Tcpdump on client and server, please?
-VAL
Am Donnerstag 24 August 2006 19:23 schrieb Valerie Henson:
> On Wed, Aug 23, 2006 at 06:59:32PM +0200, Prakash Punnoor wrote:
> > Am Samstag 19 August 2006 02:16 schrieb Valerie Henson:
> > > Hey folks,
> > >
> > > Added to my to-do list. Let me know if you figure out anything else.
> >
> > As it comes back to my mind: Last time I tested dhcpcd doesn't work.
> > dhclient does, but takes a lot of time. (The dhcp server is debian
> > based.) Other cards don't have a problem. They get their ip assigned fast
> > and with either dhcpocd or dhclient.
>
> Tcpdump on client and server, please?
Hi, I couldn't try earlier. Since I noticed the server generates a very big
log in short time, so I think the irrelevant infos should be filtered out -
it is simply to big to post. As I never used tcpdump, could you give me an
example how to accomplish this?
Thx,
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V