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