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

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.

As you see, the bytes 08 00 were not incorrect: the Ethernet header
contains 14 bytes: 6 bytes destination MAC, 6 bytes source MAC, and
2 bytes of frame length / payload type. As the length exceeds the
maximum length of 1500 bytes (+ overhead), it is the payload type,
in this case IP.

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

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

Searching the Internet with a couple of the strings in the packet
turned up answers to several of my questions. I was wrong: first,
it's not HTML, it's XML, and second, it appears to be coming from my
TV set! (Okay, the Verizon box on top of it <grin!>)

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.

The organization promoting this XML:

Multimedia Over Coax Alliance (MOCA)
http://mocalliance.org/

and two discussion threads discussing the packets themselves and their uses:

Ethernet VS MoCA (2 pages of discussion)
http://www.dslreports.com/forum/r20560340-Ethernet-VS-MoCA

[net] FiOS tv hardware: Broadcast storms
http://www.dslreports.com/forum/remark,16308944

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:

1) Per "TCP/IP Blueprints", ff.ff.ff.ff is an IPv4 "all IP hosts on
the local subnet". A little later it says "It is possible to have the routerrelay these broadcasts, but this is not recommended."

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. Is Linux making the same assumption, that is, does it consider the packets "martian" on the assumption that all IP broadcast packets are restricted to the local subnet (which it has been told is a 192. subnet)?

If the networks are running on the same LAN (like Linux IP aliases),
there is no relaying. A bridge (data link layer connection) has to
forward the frames.

2) Are there reasons why the Actiontec would want to do this anyway?

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).

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.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi
.

Relevant Pages

  • Re: Help! "Martian" (packet) invasion via FiOS cablemodem
    ... The wording in "TCP/IP Blueprints" suggests that broadcast packet ... interface internal to cable modem, it's a device talking _to_ it. ... from Verizon or the Internet). ... If the packets annoy you, use iptables to quietly drop (all from ...
    (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)
  • 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: Linux als Router
    ... # Enter all trusted network interfaces here. ... # which should be available to the internet and set FW_ROUTE to yes. ... space separated list of ports, ... # Packets to silently reject without log message. ...
    (de.comp.os.unix.linux.misc)
  • Re: Routing and Remote Access NAT - I need to modify TTL
    ... with two interfaces: PUBLIC (internet) and PRIVATE ... use it as a gateway, they can access hosts on the PUBLIC interface, TTL is ... but the replay that comes back to the NAT ... They relay on the fact that client computers accept packets with TTL=0, ...
    (microsoft.public.windows.server.networking)