Next-in-Thread Next Message

Sad transmit but not receive with 3c574 and 3c589 cards 

Forum: 3Com PCMCIA Ethernet Adapter Issues
Date: 2000, Apr 28
From: <richard.polton@bigfoot.com>

Hi,

I have been having an ongoing discussion with Andrew Morton over
this
problem (emails attached). The gist of it is as follows:

using the 3Com 574 and 589 cards, the network is unreachable here
at
work.
tcpdump -i <interface> shows that we can transmit but not receive
messages.
This would appear to be related to the router used here at work (a
Cisco
router) as I do not experience any problems at home using a simple
Intel
hub.

Unfortunately, Andrew lost me completely when he started talking
about
the 'spanning tree'.

My problem does appear to exhibit certain similarities to some
previous messages in the forum, but I have yet to see a soluton which helps me.

All and any help would be appreciated.

Richard

-------- Original Message --------
Subject: Re: Possible problem with network layer
Date: Tue, 25 Apr 2000 22:46:51 +1000
From: Andrew Morton <andrewm@uow.edu.au>
To: Richard.Polton@msdw.com
References: <38FEB548.50DFE28B@msdw.com>
<38FEE19A.7D0E5B9C@asiapacificm01.nt.com>
<38FEE350.3E5E86E2@msdw.com>
<38FEE76D.9C44EEE9@asiapacificm01.nt.com>
<38FEFD72.CB25BAC3@msdw.com>
<38FF0EAC.4A31F96D@asiapacificm01.nt.com>
<38FF2299.4B6B3904@msdw.com>
<38FFA727.E7C1F659@uow.edu.au> <39057949.D77BEC10@msdw.com>

hmmm...

One person told me this:

  On a side note, adding HAS_NWAY seems to share a problem with the
  Cisco 6509 switch.  Specifically, you need to change the spanning
  tree parameter for the port the machine is plugged into to
'portfast'
  mode.  Otherwise, the negotiation fails.  This has been an issue
  we've noticed for a while but haven't had the time to track down.

You may also like to try David Hinds' latest drivers from
http://pcmcia.sourceforge.org

There are some useful diagnostic tools (mii-diag) at
http://www.scyld.com/diag/ - this will tell you things about your
interface transceiver.

Unfortunately there doesn't seem to be a diagnostic program for the
actual 574/589 chips. 

Really, I'm the wrong person to be asking about this.  I think
David
Hinds is the 574/589 guy.

Perhaps you should pop the question on
linux-laptop@vger.rutgers.edu. 
I'm all idea'd out :-(

- Andrew.



Richard Polton wrote:
> 
> Hello,
> 
> Well, after a pleasant and lengthy weekend off I have discovered
the following
> interesting (at least I thought so ;-) tidbit:
> 
> The network performs with no problems at all with the hub I use
at home. The
> hub at work, which is where the problems are occurring, is a
Cisco router. I suspect
> that this, then, has something to do with it. Any ideas what to
look for beyond this?
> 
> Also, the eepro100 driver does work in this environment as
someone else has this card
> in their linux desktop machine.
> 
> Richard
> 
> Andrew Morton wrote:
> 
> > Richard Polton wrote:
> > >
> > > Hi,
> > >
> > > I would be interested in poking around too, given some
pointers. Of course I
> > > won't discover anything because I don't know anything about
it but it would
> > > be interesting ;-)  Any suggestions?
> >
> > Hi, Richard.  First step is to go to
> >
> > http://support.3com.com/partners/developer/developer_form.html
> >
> > and pull down some documentation.  3c905c is probably the best
one.
> > Also, Don has some description of interface negotiation stuff
at his
> > website http://cesdis.gsfc.nasa.gov/linux/misc/NWay.html (last
entry).
> >
> > It's pretty complex stuff though. I think you need to have been
in the
> > industry for a few years to have a sense of the history of
this.  I find
> > it pretty confusing because the docs tend to refer to past
practices
> > without telling you what they were :-(
> >
> > You need to compare the state mechine implemented by the
*_timer() with
> > appendix B of the 3c905 doc.
> >
> > Don has some diagnostic tools which may help: mii-diag,
pci-config,
> > vortex-diag at 
http://cesdis.gsfc.nasa.gov/linux/diag/#pci-diags .  Not
> > sure if they'll work for the 589 & 574.
> >
> > Good luck...
> >
> > > Please cc to
> > >
> > > galactichq@netscapeonline.co.uk
> > >
> > > as this is a long weekend (four days) in the UK.
> > >
> > > Richard
> > >
> > > Andrew Morton wrote:
> > >
> > > > Thanks, Richard.
> > > >
> > > > Yes, same problem.  I'll spend some (more) time looking
into this, let
> > > > you know..
> > > >
> > > > Richard Polton wrote:
> > > > >
> > > > > I am using net-tools 1.53
> > > > > modules 3c589_cs, 3c574_cs
> > > > >
> > > > > I see the following interesting(?) message when starting
tcpdump for the first
> > > > > time:
> > > > >
> > > > > tcpdump uses obsolete (PF_INET,SOCK_PACKET)
> > > > >
> > > > > What does that mean?
> > > > >
> > > > > Anyway, the tcpdump -i eth1 output is:
> > > > >
> > > > > device eth1 entered promiscuous mode
> > > > > tcpdump: listening on eth1
> > > > > 13:52:00.346638 arp who-has 138.20.230.102 tell
138.20.230.254
> > > > > 13:52:00.759507 0:e0:1e:5a:37:ea > 1:80:c2:0:0:0 802:1d
ui/C len=43
> > > > >                                           0000 0000 0020
0000 10f6 c21c e500 0000
> > > > >                                           0a80 0000 101f
89dc e580 c301 0014 0002
> > > > >                                           000f 0000 0000
0000 0000 00
> > > > > 13:52:00.826555 f159.00:c0:4f:79:f3:47.4000 >
> > > > > 0.ff:ff:ff:ff:ff:ff.452:ipx-sap-nearest-req 4 ''
> > > > > 13:52:00.934137 0:60:b0:5f:14:96 > Broadcast sap e0 ui/C
len=96
> > > > >                                           ffff 0060 0000
0000 0000 ffff ffff ffff
> > > > >                                           0452 0000 0000
0060 b05f 1496 0452 0002
> > > > >                                           030c 3030 3630
4230 3546 3134 3936 3830
> > > > >                                           4354 4e
> > > > > 13:52:01.443138 f159.00:c0:4f:79:f3:47.4000 >
> > > > > 0.ff:ff:ff:ff:ff:ff.452:ipx-sap-nearest-req 4
'OOOOOOOOOOOO49680CTNPI5F1496'
> > > > > 13:52:01.xxxxxx arp who-has 138.20.230.1 tell
138.20.230.201
> > > > >
> > > > > There is more obviously, but it seems that I am
experiencing a similar problem to
> > > > > yourself, namely that I can receive but not transmit.
> > > > >
> > > > > I am using tcpdump --version => tcpdump 3.4 libpcap 0.4
> > > > >
> > > > > I can guess what most of the tcpdump output means, but
any comments on your
> > > > > part for what I should not see, i.e. anything to look
for, would be great.
> > > > >
> > > > > Andrew Morton wrote:
> > > > >
> > > > > > Yes, please let me know what versions of things you
have.
> > > > > >
> > > > > > I goofed in my earlier email.  I look after 3c575_cb.c
(it's now been
> > > > > > folded into 3c59x.c).  3c574_cs and 3c589_cs are
separate drivers.
> > > > > > Neither of these has changed at all since 2.3.99-pre2.
Odd.
> > > > > >
> > > > > > Richard Polton wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I am using both 3Com 3c574 (I think, I'll check
later) and 3Com 3c589 cards.
> > > > > > > I have never tried 2.2.x but, and here is the odd
thing, 3c589 used to work fine
> > > > > > >
> > > > > > > with 2.3.48 and 2.3.99pre2 when the network interface
was initialised
> > > > > > > automatically via dhcpcd. I hope that this sheds some
light on this problem for
> > > > > > > you. I shall check tcpdump later and mail you any
results.
> > > > > > >
> > > > > > > Richard
> > > > > > >
> > > > > > > Andrew Morton wrote:
> > > > > > >
> > > > > > > > Richard,
> > > > > > > >
> > > > > > > > what sort of network card is it?
> > > > > > > >
> > > > > > > > I am experiencing similar problems with a 3com
3c574-based card.  I'm
> > > > > > > > having trouble getting to the bottom of this, and
I'm supposed to be
> > > > > > > > maintaining the (&*^&^ driver!
> > > > > > > >
> > > > > > > > It comes up in a mode where it can receive but not
transmit (run tcpdump
> > > > > > > > -i eth0 to see if you're receiving).
> > > > > > > >
> > > > > > > > I've found that a few
> > > > > > > >
> > > > > > > > /etc/rc.d/init.d/network stop
> > > > > > > > ifdown eth0
> > > > > > > > ifup eth0
> > > > > > > > /etc/rc.d/init.d/network start
> > > > > > > >
> > > > > > > > cycles will wake it up.  It's very odd.
> > > > > > > >
> > > > > > > > Was it different under kernel 2.2?
> > > > > > > >
> > > > > > > > Richard Polton wrote:
> > > > > > > > >
> > > > > > > > > Firstly, I am using 2.3.99pre3 on a 686 laptop.
This week I have been
> > > > > > > > > experiencing strange
> > > > > > > > > problems with the networking layer, namely that I
cannot ping any other
> > > > > > > > > machine on the
> > > > > > > > > same subnet.
> > > > > > > > >
> > > > > > > > > The green light is on on the pcmcia network card
and ping <my ip
> > > > > > > > > address> works fine.
> > > > > > > > > The routing table is set up as follows:
> > > > > > > > >
> > > > > > > > > ifconfig eth0 140.14.100.76 netmask 255.255.255.0
broadcast
> > > > > > > > > 140.14.100.255 up
> > > > > > > > > route add -host 140.14.100.76 eth0
> > > > > > > > > route add -net 140.14.100.0 eth0
> > > > > > > > > route add default gw 140.14.100.1 eth0
> > > > > > > > >
> > > > > > > > > Various permutations of the above have not been
successful.
> > > > > > > > >
> > > > > > > > > When pinging a remote machine, I see 'Destination
host unreachable'
> > > > > > > > > message.
> > > > > > > > >
> > > > > > > > > Note that this used to work beautifully at my
previous office, so I do
> > > > > > > > > not believe
> > > > > > > > > (although it is obviously possible) that the
network card is at fault.
> > > > > > > > > And yes, the network
> > > > > > > > > I am connecting to is fine also, as I have
swapped another machine onto
> > > > > > > > > that patch.
> > > > > > > > >
> > > > > > > > > So, how can I trace everything that goes through
the network layer in
> > > > > > > > > the kernel? I have
> > > > > > > > > tried magic sysrq 9 (I noticed that TCP_DUMP is
defined as 1) and I have
> > > > > > > > > also defined
> > > > > > > > > DEBUG, INET_REFCNT_DEBUG and NET_REFCNT_DEBUG. I
cannot, however, find
> > > > > > > > > any
> > > > > > > > > messages. Additionally, defining DEBUG in
include/linux/autoconf.h
> > > > > > > > > causes the kernel build to fail.
> > > > > > > > > In particular this happens in lib/inflate.c when
Tracecv is expanded as
> > > > > > > > > neither stderr or fprintf are
> > > > > > > > > recognised. I tried redefining fprintf as printk
but it seems that
> > > > > > > > > printk causes link time problems
> > > > > > > > > here so, for this file, I simply resorted to a
local #undef DEBUG.
> > > > > > > > >
> > > > > > > > > Any and all help would be greatly appreciated
and, of course, I can
> > > > > > > > > supply more information
> > > > > > > > > if necessary.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > Richard Polton
> > > > > > > > >
> > > > > > > > > -
> > > > > > > > > To unsubscribe from this list: send the line
"unsubscribe linux-kernel" in
> > > > > > > > > the body of a message to
majordomo@vger.rutgers.edu
> > > > > > > > > Please read the FAQ at http://www.tux.org/lkml/
> >
> > --
> > -akpm-

Next-in-Thread Next Message

Messages Inline: 1 All Outline: 1 2 All

1. None Re: Sad: transmit but not receive with 3c574 and 3c589 cards by David Hinds, 2000, Apr 28

Add Message to: "transmit but not receive with 3c574 and 3c589 cards"

Members Subscribe Admin Mode Show Frames Help for HyperNews at pcmcia-cs.sourceforge.net 1.10