Re: Help! "Martian" (packet) invasion via FiOS cablemodem

Tauno,

Thanks again for your patience.

On Mon, 13 Oct 2008 17:05:46 GMT, Tauno Voipio <tauno.voipio@xxxxxxxxxxxxx> wrote:
Frnak McKenney wrote:
On Sun, 12 Oct 2008 21:02:28 -0500, Frnak McKenney <frnak@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Great. Now I'm talking to myself. <grin!>

And now I'm answering?! Ack!

So what - we all get old, and I'm listening ...

--big--snip--
-------- reformatted for legibility ------
manticore:~ # tcpdump -c 1 -vvv -e -XX ip broadcast
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture
size 96 bytes
21:34:13.575389 00:1a:66:0f:24:7e (oui Unknown) > Broadcast,
ethertype IPv4 (0x0800), length 643: (tos 0x0, ttl 64, id 14690,
offset 0, flags [none], proto: UDP (17), length: 629)
169.254.1.147.21302 > 255.255.255.255.21302: UDP, length 601

0x0000: ffff ffff ffff 001a 660f 247e 0800 4500 ........f.$~..E.
0x0010: 0275 3962 0000 4011 9385 a9fe 0193 ffff .u9b..@.........
0x0020: ffff 5336 5336 0261 1362 3c48 6d61 4e65 ..S6S6.a.b<HmaNe
0x0030: 7443 6f6e 6669 673e 0a20 203c 4d73 6746 tConfig>...<MsgF
0x0040: 6d74 5265 763e 323c 2f4d 7367 466d 7452 mtRev>2</MsgFmtR
0x0050: 6576 3e0a 2020 3c4d 7367 436f 6e74 5265 ev>...<MsgContRe

This is a message fragment, it's the header of a valid broadcast
UDP datagram to the local network.
--snip--

Thank you for the details.

The wording in "TCP/IP Blueprints" suggests that broadcast packet
handling is a grey area where things allowble are not always
recommended.

On the one hand we have a cable modem that feels that an FF.FF.FF.FF
broadcast packet from a device whose IP address is 169.254.a.b
should be sent to every physically connected connected device.

On the other hand, we have openSuSE Linux 10.2 complaining that it
is receiving a broadcast from a 169.254 device via an interface
configured as 192.168.x.y

Left hand, meet right hand. Please. <grin?>

For further analysis, pass the snap length parameter (-s) to tcpdump,
so that the captures are not truncated.

Noted.

For easier decoding, I strongly recommend Wireshark. It can be used
also to analyse packets captured with the tcpdump -w option.

Also noted.

--snip--
The mysterious "IP-STB" item listed by the router is a not an
interface internal to cable modem, it's a device talking _to_ it.
In fact, it's... (wait for it!)... my Verizon FiOS Set Top Box.
Yup, appliances talking to each other.

Gack. Next thing you know, my humidifier will be waking me up in
the middle of the night wanting a drink of water. <grin?>

Yep - and it seems that Verizon is running two local networks
on the same physical medium. This is not strictly prohibited,
but not recommended, either. They probably count on an easy
way of connecting to an unconfigured Windows box, go figure.
--snip--
So what I'm seeing appears to be a valid packet from a real device,
not something mysterious coming in through the fiber link (e.g.
from Verizon or the Internet).

See above. Not neat, but barely legal.

Which leaves me with two questions:
--snip--

(Three, but who's counting? <grin!>)

3) It appears that the STB uses the cable modem to communicate with
the Internet. If I unplug the coax link between the FiOS
interface box and the cable modem I lose my Internet link, true,
but within a day or three I notice that the STB program guide
isn't getting updated as well.

How do I block these broadcasts from my local LAN without also
blocking the IP-STB device's access to the Internet, and
without worrying that the next MOCA device I connect (e.g. a
DVR) will generate a new set of Martian Visitations??

The short advice is: don't, the Verizon kludge stops working.

The complaining about Martians is correct, as Linux is not expecting
any traffic from the link local net on the LAN interface.

If the packets annoy you, use iptables to quietly drop (all from
the 169.254 network).

I decided not to take this path because I don't really want the
packets to be ignored. If another mysteriously appears (a new
refrigerator, perhaps?) I'd like to know about it.

Another method would be to configure an alias (e.g.
169.254.42.42/16) on the Ethernet interface, so that the Martians
start to be plain known neighbors to your box. Strictly taken,
this is not correct (see the RFC), as it is not allowed to
statically configure a zeroconf address.

Ah. I'll have to research "zeroconf"; it's not in my book's index
(but the WinNT CD is still there! <grin>).

I took your second suggestion, and it appears to have fixed the
problem without obviously creating any new ones: no new "martian"
messages have been logged in the forty minutes I've been composing
this followup. Please feel free to ignore the following, but I
wanted to describe the process for the next Verizon customer running
Linux who worries about invading "martians".

I added an interface alias named 'ethstb' (not very original, I
admit) using YaST as follows:

- Start YaST and enter root password in response to the prompt.
- Select Network_Devices.
- Select Network_Card
- At least in openSuSE 10.2, "Network Manager" does not support
aliases, so make sure this option is selected:
(*) Traditional method using ifup
- Select the adapter which is connected to the cable modem.
- [Edit]
- [Advanced]->[Additional_addresses]
- Alias name: ethstb
IP Address: 169.254.1.100 (e.g. not the IP-STB address)
Netmask: 255.255.0.0
- You're done. [OK] [OK] [Next] [Finish] to save your changes and
restart your reconfigured network.
- Check /var/log/messages to see if any more "martians" are
reported.

Again, my thanks to everyone who contributed.


Frank
--
It is one of the most beautiful compensations of life,
that no man can sincerely try to help another without
helping himself. -- Ralph Waldo Emerson
--
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

.

Relevant Pages

  • Re: [Full-disclosure] Strange interactions between tunnelling and SMB under the proprietary Micr
    ... I was routing internal networks on Internet towards a probe that was also receiving Intranet routers anti-spoofing realtime logs. ... When the probe was receiving a packet from outside targetting an internal @IP broadcast, I was correlating with antispoof logs of packets coming from an @IP compatible with this external broadcast towards the broadcast of the source @IP of the packet received from the outside and gotcha. ...
    (Full-Disclosure)
  • Re: Help! "Martian" (packet) invasion via FiOS cablemodem
    ... the bytes 08 00 were not incorrect: the Ethernet header ... also to analyse packets captured with the tcpdump -w option. ... from Verizon or the Internet). ... My LAN is 192.x.y.z and the packet is from 169.a.b.c, so passing the broadcast along doesn't _sound_ right. ...
    (comp.os.linux.networking)
  • Re: [Full-disclosure] Strange interactions between tunnelling and SMB under the proprietary Micr
    ... I was routing internal networks on Internet towards a probe that was also receiving Intranet routers anti-spoofing realtime logs. ... When the probe was receiving a packet from outside targetting an internal @IP broadcast, I was correlating with antispoof logs of packets coming from an @IP compatible with this external broadcast towards the broadcast of the source @IP of the packet received from the outside and gotcha. ...
    (Full-Disclosure)
  • can someone critique my pf.conf file
    ... i'd like to allow for access via SSH and allow access for outside systems to ... ids_int = "hme1" # IDS sensor interface ... in/out and packets passed/blocked ... ### pass tcp, udp, and icmp out on the external (Internet) interface. ...
    (comp.security.firewalls)
  • RE: where should I start? help!
    ... The exernal router serial interface status as follows: ... 16859032 packets input, 2850828712 bytes, 0 no ... >> but the internet speed is very slow. ... >> Evaluating SSL VPNs' Consider NEOTERIS, ...
    (Security-Basics)