Re: Beavis is back and I wanna show him a raw IP dump

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "jb" == Jonathan Q <jq@example.com> writes:

    jb> Exactly what is between you and the router?  Hubs, switches,
    jb> the whole deal.  Feel free to do an ASCII network diagram if
    jb> you're of a mind to :-) What brand of routers, switches, etc.?

Linux <--> 3Com 3c905 or 3c589 <- 10BaseT -> ancient CentreCom hub <-
10Base5 -> CentreCom 440 transceiver <- 10Base5? -> [I don't know]
<--> router (I don't know, probably Cisco, maybe it handles 100BaseT??)

    jb> I also haven't found any docs on specifically what ifconfig is
    jb> referring to in the frames column of the errors section,

According to Donald Becker (3c59x.c to be precise) this is information
read from the card.  sonic.c seems to imply that you can actually read
such broken frames (I haven't looked real close yet at that source),
but 3c59x and 3c589_cs just drop those packets on the floor (which is
why Karpski and Ethereal don't see them).

    jb> so I'm going to hazard a guess that these were malformed or
    jb> incomplete frames that were received (frames being the
    jb> protocol data unit used by ethernet).  I'm supposing there
    jb> isn't a horrendous amount of traffic on your side of the

No.  Certainly not this time of night....

    jb> router link.  I'm wondering if an interface isn't borked
    jb> somewhere.

Yeah, between Beavis's ears, for sure.

Chris's suggestion about duplex mismatch sounds like exactly the kind
of thing that would happen.

    jb> You said UDP doesn't work, but how about ICMP?

I don't know.  I tried ping -l, but even that wasn't enough to get it
to drop ICMPs.  I don't know what's happening with UDP; what I know is
that the Coda file system, which uses UDP a lot (it has its own
methods for achieving reliability) falls on its face about half the time.

    jb>   What does a traceroute from you to the router look like?

traceroute to 130.158.98.254 (130.158.98.254), 30 hops max, 38 byte packets
 1  router-97.sk.tsukuba.ac.jp (130.158.97.254)  1.441 ms *  1.839 ms

And here's one to another box connected to the same hub as .109:

traceroute to 130.158.98.114 (130.158.98.114), 30 hops max, 38 byte packets
 1  router-97.sk.tsukuba.ac.jp (130.158.97.254)  1.357 ms  1.679 ms  1.367 ms
 2  tleepslib2.sk.tsukuba.ac.jp (130.158.98.114)  3.249 ms  3.417 ms  3.072 ms

(note, for experimental purposes I have my routes set as:

bash-2.04$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.10.254  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
130.158.98.254  0.0.0.0         255.255.255.255 UH    0      0        0 eth0
0.0.0.0         130.158.98.254  0.0.0.0         UG    1      0        0 eth0

the ppp0 iface is actually an ssh tunnel over eth0).

    jb> Any really, really slow hops?

Aside from the second packet invariably disappearing into a black
hole, no.

However, a long series of pings from .109 to .114 via .254 will show
mostly ~3.2ms, then it will bounce up to 20, 50, 150 ms for a packet
or two, then back to ~3.2ms.

    jb> If you know the IP address of the router's exit port,
    jb> traceroute to that, too.  And then something at least one hop
    jb> on the other side of that router.

The router has at least 5 addresses (130.158.{96,97,98,99,101}.254).
I am told that 130.158.97.254 and 130.158.98.254 at least share a
physical interface (ie, are aliases).  I'm sure that's true because I
can "see" other machines on 130.158.97.0, without a gateway, if I set
a route there.  I know that 130.158.99.254 is a separate physical
interface; I can't see those machines.

Traceroutes to all of those addresses have the form of the traceroute
above to 130.158.98.254, right down to all of them thinking they are
130.158.97.254.  The timings are always 1.3ms * 4ms or so.

    jb> Can you post your ifconfig output?

bash-2.04$ /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:10:4B:26:62:FD  
          inet addr:130.158.98.109  Bcast:130.158.98.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:81060 errors:259 dropped:0 overruns:0 frame:226
          TX packets:43951 errors:0 dropped:0 overruns:0 carrier:5
          collisions:1 txqueuelen:100 
          Interrupt:18 Base address:0x1040 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16144  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:192.168.1.3  P-t-P:192.168.10.254  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:26920 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31815 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 


    jb> Also, you mentioned it seems to be hosing packets from time to

These are the frame and other errors; the packets that get through are
fine.

    jb> time, so this is apparently an intermittent problem?  Is there
    jb> any kind of regular pattern to when it does it?

Without a trace, I can't do any pattern identification.  :-(

As I mentioned before, an FTP transfer between two machines with
routes set as above (ie, no route to localnet, all traffic (except to
self) via the gw) will send the error rate to nearly 20% (and the
transfer rate is 10-20 KBps).



-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."