From owner-freebsd-hackers Fri Oct 20 14:34:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.tellurian.net (gate.tellurian.net [216.182.1.1]) by hub.freebsd.org (Postfix) with ESMTP id 122E237B479; Fri, 20 Oct 2000 14:34:01 -0700 (PDT) Received: from dppl.com (unverified [216.182.27.51]) by gate.tellurian.net (Rockliffe SMTPRA 4.2.4) with ESMTP id ; Fri, 20 Oct 2000 17:34:12 -0400 Message-ID: <39F0B9A6.56FFE589@dppl.com> Date: Fri, 20 Oct 2000 17:31:18 -0400 From: Marko Ruban X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 4.1.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nick Rogness Cc: Marko Ruban , FreeBSD questions , freebsd-hackers@freebsd.org Subject: Re: Routing issue with cable modem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG New issue seems to be at hand... I set the alias for the interface to be the gateway IP (10.17.56.12), and then I was able to add that as my default gateway. Not sure why aliasing wouldn't work with 10.17.56.11 or some other IP in that subnet. I tried to ping the DNS server after that, and watched hundreds of corrupt packets get sent out with no replies. So my new question is, which part of the system actually builds the packets ? Any way to debug or log that process ? Here's an example taken from ethereal output.... (view with proportional font) --------------------------------------------------------- Frame 6 (102 on wire, 102 captured) Arrival Time: Oct 20, 2000 16:42:38.2715 Time delta from previous packet: 0.000071 seconds Frame Number: 6 Packet Length: 102 bytes Capture Length: 102 bytes Ethernet II Destination: 02:00:00:00:52:54 (02:00:00:00:52:54) Source: 05:f4:21:3f:52:54 (05:f4:21:3f:52:54) Type: Unknown (0x05f4) Data (88 bytes) 0 0200 0000 5254 05f4 213f 5254 05f4 213f ....RT..!?RT..!? 10 0800 4500 0054 13fa 0000 fa01 97dc 0a11 ..E..T.......... 20 380c cfac 0309 0800 c1f0 6101 0000 3eae 8.........a...>. 30 f039 b722 0400 0809 0a0b 0c0d 0e0f 1011 .9."............ 40 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 .............. ! 50 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 "#$%&'()*+,-./01 60 3233 3435 3637 234567 --------------------------------------------------------- Why I think this packet is malformed..... First of all, protocol type Unknown (0x05f4) looks definitely bad. Secondly, protocol type looks like part of my NICs MAC address (52:54:05:f4:21:3f according to ifconfig, which translates into hex: 0x5254 05f4 213f). Thirdly, source address decoded by ethereal (and probably by any other packet processor) is wrong (first two bytes are carried over to the other side). Now, keeping all that in mind, lets do a pattern match on the REAL MAC address in hex dump of the packet. HEY, the source address actually starts four bytes later than it should, thus shifting the TRUE protocol type (0x0800 = IP) as well. First six bytes are the destination MAC, then come the EVIL 4 bytes, followed by 6 bytes of source MAC. I don't know what's going on, but looks pretty bad, yet simple on the hex level :) Any ideas ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message