Date: Fri, 20 Oct 2000 18:35:02 -0400 From: Marko Ruban <marko@dppl.com> To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Routing issue with cable modem Message-ID: <39F0C896.30C53A1D@dppl.com>
next in thread | raw e-mail | index | archive | help
Joel said HTML was badly formatted, so I'm resubmitting in plain text.
Thanks :)
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39F0C896.30C53A1D>