Help! "Martian" (packet) invasion via FiOS cablemodem - Networking

This is a discussion on Help! "Martian" (packet) invasion via FiOS cablemodem - Networking ; You start out with a single computer. You add another, you want them to talk to each other, and before you know it you have a Topsy-LAN connecting Linux, OS/2, and a couple of flavors of MSWinXX. Then you run ...

+ Reply to Thread
Results 1 to 18 of 18

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

  1. Help! "Martian" (packet) invasion via FiOS cablemodem

    You start out with a single computer. You add another, you want
    them to talk to each other, and before you know it you have a
    Topsy-LAN connecting Linux, OS/2, and a couple of flavors of
    MSWinXX. Then you run into a problem, and you have to figure out
    how to make it go away...

    Here are some odd messages that are logged to 'manticore' (openSuSE
    10.2) when it is connected to my Verizon Actiontec M1424 cablemodem
    (wrapped for legible posting):

    Oct 9 16:00:25 manticore kernel: martian source 255.255.255.255
    from 169.254.1.147, on dev eth0
    Oct 9 16:00:25 manticore kernel: ll header:
    ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    Oct 9 16:00:35 manticore kernel: martian source 255.255.255.255
    from 169.254.1.147, on dev eth0
    Oct 9 16:00:35 manticore kernel: ll header:
    ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    Oct 9 16:00:45 manticore kernel: martian source 255.255.255.255
    from 169.254.1.147, on dev eth0
    Oct 9 16:00:45 manticore kernel: ll header:
    ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00

    The Actiontec ports are labelled WAN and LAN1-LAN4. Its 'web-based
    setup program shows the following device:

    IP-STB1 00:1a:66:0f:24:7e:08:00 Coax DHCP Connection=Bridge

    manticore is connected to port 1 of an Encore 8-port/N-way switch.

    If I don't connect the switch to the Actiontec, no (martian) warning
    messages appear.

    With a cable connecting (say) the Encore's #7 port to the
    Actiontec's LAN3 port but with the FiOS coax cable disconnected
    from the Actiontec's Coax port, no messages appear.

    With both links in place, the messages do appear.

    This _seems_ to indicate that the packets are coming through the
    coax cable between the Actiontec and Verizon's FiOS fiber interface
    box. However, I suppose that it's also possible that the packets
    are originating from inside the Actiontec in response to some kind
    of Verizon diagnostic inquiry made every ten seconds.

    But that's all speculation based on minimal knowledge. Can anyone
    shed any light on these packets?

    More important, can anyone suggest any good way to block these from
    coming into my LAN? I'd rather not block them via manticore's
    firewall, since that would leave them still running around the rest
    of my machines.

    The Actiontec offers a number of filtering options. Under Advanced
    Filtering I can apparently add "rules" to block packets categorized
    as "Broadband (Coax)" or simply as "Coax", but it's not clear what
    the difference is.

    Also, if anyone can offer reassurance that blocking these packets
    won't cause other problems (e.g. trigger some sort of Verizon alarm
    condition ) I'd feel a bit better.

    Thanks in advance.


    Frank McKenney
    --
    "We have staked the whole future of American civilization,
    not upon the power of government, far from it. We have staked
    the future of all our political institutions . . . upon the
    capacity of each and all of us to govern ourselves, to control
    ourselves, to sustain ourselves according to the Ten
    Commandments of God." -- James Madison
    --
    Frank McKenney, McKenney Associates
    Richmond, Virginia / (804) 320-4887
    Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

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

    On Oct 9, 2:19 pm, Frnak McKenney
    wrote:
    > You start out with a single computer. You add another, you want
    > them to talk to each other, and before you know it you have a
    > Topsy-LAN connecting Linux, OS/2, and a couple of flavors of
    > MSWinXX. Then you run into a problem, and you have to figure out
    > how to make it go away...
    >
    > Here are some odd messages that are logged to 'manticore' (openSuSE
    > 10.2) when it is connected to my Verizon Actiontec M1424 cablemodem
    > (wrapped for legible posting):
    >
    > Oct 9 16:00:25 manticore kernel: martian source 255.255.255.255
    > [...]


    Didn't bother using Google first? See:



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

    On Thu, 9 Oct 2008 16:48:06 -0700 (PDT), Thad Floryan wrote:
    > On Oct 9, 2:19 pm, Frnak McKenney
    > wrote:
    >> You start out with a single computer. You add another, you want
    >> them to talk to each other, and before you know it you have a
    >> Topsy-LAN connecting Linux, OS/2, and a couple of flavors of
    >> MSWinXX. Then you run into a problem, and you have to figure out
    >> how to make it go away...
    >>
    >> Here are some odd messages that are logged to 'manticore' (openSuSE
    >> 10.2) when it is connected to my Verizon Actiontec M1424 cablemodem
    >> (wrapped for legible posting):
    >>
    >> Oct 9 16:00:25 manticore kernel: martian source 255.255.255.255

    0> from 169.254.1.147, on dev eth0
    0> Oct 9 16:00:25 manticore kernel: ll header:
    0> ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    >> [...]


    >


    Thad,

    Thanks for the reply, and for the pointer. My searches turned up a
    lot of references, but I apparently missed that one.

    The Wikipedia page defines "martian packets" as:

    ...packets with source addresses not routable by some computer on
    a network segment...

    and lists some possible causes:

    Martian packets can arise from network equipment malfunction,
    misconfiguration of a host, or simple coexistence of two logical
    networks on a single physical layer.

    Unfortunately, if Wikipedia's entry offers any concrete advice on
    what do about my specific case of "rouge" packets, I'm
    afraid it's flying right past me.

    Which leaves me stuck with the following questions:

    1) Where do these packets originate (LAN, switch, modem/bridge)?

    2) What is their purpose?

    3) What is the most appropriate way (or, failing that, _any_ way)
    of blocking them from getting out of the Verizon cable
    modem and reaching my switch? and

    4) Are there any consequences if I do?

    It _feels_ like the solution (or at least a solution) will involve
    configuring the Actiontec to block some packets at one or more of
    the interfaces, but I'm a little cautious about doing that blindly.

    Any specific suggestions you (or anyone else) can offer will be
    appreciated.


    Frank
    --
    It is the business of education to implant insight and respon-
    sibility. It must turn irresponsible opinion into responsible
    judgement and lead from chance and arbitrariness to the rational
    lucidity of an intellectual order. -- Mies Van der Rohe
    --
    Frank McKenney, McKenney Associates
    Richmond, Virginia / (804) 320-4887
    Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

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

    Frank McKenney wrote:
    >>> Oct 9 16:00:25 manticore kernel: martian source 255.255.255.255

    > 0> from 169.254.1.147, on dev eth0
    > 0> Oct 9 16:00:25 manticore kernel: ll header:
    > 0> ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    >
    > Which leaves me stuck with the following questions:
    >
    > 1) Where do these packets originate (LAN, switch, modem/bridge)?
    >
    > 2) What is their purpose?
    >
    > 3) What is the most appropriate way (or, failing that, _any_ way)
    > of blocking them from getting out of the Verizon cable
    > modem and reaching my switch? and
    >
    > 4) Are there any consequences if I do?



    Let's split the header:

    ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00

    splits to:

    ff:ff:ff:ff:ff:ff Ethernet broadcast
    00:1a:66:0f:24:7e sender MAC address
    08:00 payload: IP

    I'd like to see what role does the IP address 169.254.1.147 have
    here. It is a link-local (zeroconf) address which should be used
    only when no other means for getting an IP address is available.

    The IP address 255.255.255.255 is a local link broadcast, so it is
    possible that the log message has confused source and destination
    IP addresses. It's perfectly healthy to send an IP packet to an IP
    address 255.255.255.255 and Ethernet address ff:ff:ff:ff:ff:ff.

    If you find the node in the local network having the MAC address
    00:1a:66:0f:24:7e you may get answers to the above questions.

    Another way to get more info is to fire up tcpdump or Wireshark and
    capture the packets in full (instead of abbreviated header info).

    --

    Tauno Voipio
    tauno voipio (at) iki fi

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

    On Thu, 09 Oct 2008 16:19:34 -0500, Frnak McKenney wrote:

    > You start out with a single computer. You add another, you want them to
    > talk to each other, and before you know it you have a Topsy-LAN
    > connecting Linux, OS/2, and a couple of flavors of MSWinXX. Then you
    > run into a problem, and you have to figure out how to make it go away...
    >
    > Here are some odd messages that are logged to 'manticore' (openSuSE
    > 10.2) when it is connected to my Verizon Actiontec M1424 cablemodem
    > (wrapped for legible posting):
    >
    > Oct 9 16:00:25 manticore kernel: martian source 255.255.255.255
    > from 169.254.1.147, on dev eth0
    > Oct 9 16:00:25 manticore kernel: ll header:
    > ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    > Oct 9 16:00:35 manticore kernel: martian source 255.255.255.255
    > from 169.254.1.147, on dev eth0
    > Oct 9 16:00:35 manticore kernel: ll header:
    > ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    > Oct 9 16:00:45 manticore kernel: martian source 255.255.255.255
    > from 169.254.1.147, on dev eth0
    > Oct 9 16:00:45 manticore kernel: ll header:
    > ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    >
    > The Actiontec ports are labelled WAN and LAN1-LAN4. Its 'web-based
    > setup program shows the following device:
    >
    > IP-STB1 00:1a:66:0f:24:7e:08:00 Coax DHCP Connection=Bridge
    >
    > manticore is connected to port 1 of an Encore 8-port/N-way switch.
    >
    > If I don't connect the switch to the Actiontec, no (martian) warning
    > messages appear.
    >
    > With a cable connecting (say) the Encore's #7 port to the Actiontec's
    > LAN3 port but with the FiOS coax cable disconnected from the Actiontec's
    > Coax port, no messages appear.
    >
    > With both links in place, the messages do appear.
    >
    > This _seems_ to indicate that the packets are coming through the coax
    > cable between the Actiontec and Verizon's FiOS fiber interface box.
    > However, I suppose that it's also possible that the packets are
    > originating from inside the Actiontec in response to some kind of
    > Verizon diagnostic inquiry made every ten seconds.
    >
    > But that's all speculation based on minimal knowledge. Can anyone shed
    > any light on these packets?
    >
    > More important, can anyone suggest any good way to block these from
    > coming into my LAN? I'd rather not block them via manticore's firewall,
    > since that would leave them still running around the rest of my
    > machines.
    >
    > The Actiontec offers a number of filtering options. Under Advanced
    > Filtering I can apparently add "rules" to block packets categorized as
    > "Broadband (Coax)" or simply as "Coax", but it's not clear what the
    > difference is.
    >
    > Also, if anyone can offer reassurance that blocking these packets won't
    > cause other problems (e.g. trigger some sort of Verizon alarm condition
    > ) I'd feel a bit better.
    >
    > Thanks in advance.
    >
    >
    > Frank McKenney
    > --
    > "We have staked the whole future of American civilization,
    > not upon the power of government, far from it. We have staked the
    > future of all our political institutions . . . upon the capacity of
    > each and all of us to govern ourselves, to control ourselves, to
    > sustain ourselves according to the Ten Commandments of God." --
    > James Madison


    I don't see mention of a router in your setup, just a switch. Put a router
    between your switch and your modem, I'm pretty sure that will solve your
    problem. In any event you always want a router between your network and a
    modem because it provides a firewall.

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

    On Oct 12, 9:42 am, Tauno Voipio wrote:
    > [...]
    > Let's split the header:
    >
    > ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    >
    > splits to:
    >
    > ff:ff:ff:ff:ff:ff Ethernet broadcast
    > 00:1a:66:0f:24:7e sender MAC address
    > 08:00 payload: IP
    >
    > I'd like to see what role does the IP address 169.254.1.147 have
    > here. It is a link-local (zeroconf) address which should be used
    > only when no other means for getting an IP address is available.
    >
    > The IP address 255.255.255.255 is a local link broadcast, so it is
    > possible that the log message has confused source and destination
    > IP addresses. It's perfectly healthy to send an IP packet to an IP
    > address 255.255.255.255 and Ethernet address ff:ff:ff:ff:ff:ff.
    >
    > If you find the node in the local network having the MAC address
    > 00:1a:66:0f:24:7e you may get answers to the above questions.
    >
    > Another way to get more info is to fire up tcpdump or Wireshark and
    > capture the packets in full (instead of abbreviated header info).


    You beat me to a reply. :-)

    Also, the "169. ..." IP is something I see frequently at client
    sites regarding misconfigured Windows systems. I'll bet that
    matching the MAC address will point to a Windows box as the
    source of the "Martians".

    Often simply doing (in a Command Prompt window) "ipconfig /renew"
    will clear up such problems assuming the TCP/IP setup is otherwise
    correct. If it's a desktop system, using a static IP on the
    WIndows box is often better than using DHCP (as is frequently
    used for laptops).


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

    On Oct 12, 10:17 am, General Schvantzkopf
    wrote:
    > [...]
    > I don't see mention of a router in your setup, just a switch. Put a router
    > between your switch and your modem, I'm pretty sure that will solve your
    > problem. In any event you always want a router between your network and a
    > modem because it provides a firewall.


    Excellent advice.

    I just did the same for one client this past Friday: bought a Linksys
    BEFSR41 version 4 Cable/DSL router for $60 at a local Fry's
    Electronics
    and everything's fine for the client.

    Note the "version 4" of the router; that's a hardware version, not
    firmware.
    Version 4 was needed for its 10/100 WAN interface (a DOCSYS 2.0 cable
    modem
    can provide 30Mbps WAN connectivity); the older versions (version 2 is
    very
    common) have only a 10Mbps WAN interface.

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

    Thad Floryan wrote:
    >
    > Also, the "169. ..." IP is something I see frequently at client
    > sites regarding misconfigured Windows systems. I'll bet that
    > matching the MAC address will point to a Windows box as the
    > source of the "Martians".


    The link local address range is 169.254.0.0/16 (all: 169.254.x.y).

    Their use is specified in RFC 3928.

    --

    Tauno Voipio
    tauno voipio (at) iki fi

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

    On Oct 12, 1:17 pm, Tauno Voipio wrote:
    > Thad Floryan wrote:
    >
    > > Also, the "169. ..." IP is something I see frequently at client
    > > sites regarding misconfigured Windows systems. I'll bet that
    > > matching the MAC address will point to a Windows box as the
    > > source of the "Martians".

    >
    > The link local address range is 169.254.0.0/16 (all: 169.254.x.y).
    >
    > Their use is specified in RFC 3928.


    Very true, and thank you for citing the RFC.

    It's just that I "usually" see the "problem" on Windows boxes, and
    when the OP wrote:

    " You add another, you want them to talk to each other, and
    " before you know it you have a Topsy-LAN connecting Linux,
    " OS/2, and a couple of flavors of MSWinXX. Then you run
    " into a problem, and you have to figure out how to make it
    " go away...

    a misconfigured Windows box was my first thought. Finding the
    system with the specified MAC address is the OP's next step.

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

    Tauno,

    Thanks for assisting.

    On Sun, 12 Oct 2008 16:42:40 GMT, Tauno Voipio wrote:
    > Frank McKenney wrote:
    >>>> Oct 9 16:00:25 manticore kernel: martian source 255.255.255.255

    >> 0> from 169.254.1.147, on dev eth0
    >> 0> Oct 9 16:00:25 manticore kernel: ll header:
    >> 0> ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    >>
    >> Which leaves me stuck with the following questions:
    >>
    >> 1) Where do these packets originate (LAN, switch, modem/bridge)?
    >>
    >> 2) What is their purpose?
    >>
    >> 3) What is the most appropriate way (or, failing that, _any_ way)
    >> of blocking them from getting out of the Verizon cable
    >> modem and reaching my switch? and
    >>
    >> 4) Are there any consequences if I do?

    >
    >
    > Let's split the header:
    >
    > ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    >
    > splits to:
    >
    > ff:ff:ff:ff:ff:ff Ethernet broadcast
    > 00:1a:66:0f:24:7e sender MAC address


    Right. The Verizon cable modem says that belongs to:

    IP-STB1 00:1a:66:0f:24:7e Coax DHCP Connection=Bridge

    (I accidentally added the 08:00 to this address on my initial post.)

    > 08:00 payload: IP
    >
    > I'd like to see what role does the IP address 169.254.1.147 have
    > here. It is a link-local (zeroconf) address which should be used
    > only when no other means for getting an IP address is available.


    But... does the fact that it's coming from the "Coax" interface
    mean that it's originating in from Verizon's FiOS box? Or from the
    FiOS fiber link, that is, from Verizon and/or the Internet?

    CAT5 CAT5 Coax Fiber
    manticore <==> switch <==> Actiontec <==> Verizon <===={ }
    eth0 LAN3 IP-STB1 Fios Box

    > The IP address 255.255.255.255 is a local link broadcast, so it is
    > possible that the log message has confused source and destination
    > IP addresses. It's perfectly healthy to send an IP packet to an IP
    > address 255.255.255.255 and Ethernet address ff:ff:ff:ff:ff:ff.
    >
    > If you find the node in the local network having the MAC address
    > 00:1a:66:0f:24:7e you may get answers to the above questions.


    See above.

    > Another way to get more info is to fire up tcpdump or Wireshark and
    > capture the packets in full (instead of abbreviated header info).


    Glack. I confess I've been hoping for more of a "Verizon Actiontec
    modems exhibit this problem with their default settings; to fix it,
    do XXX, YYY, and ZZZ".

    I'll check to see if tcpdump is installed; I'm fairly sure Wireshark
    isn't, but I can check around for an openSuSE 10.2 copy.

    Thanks.


    Frank
    --
    It does not do to leave a live dragon out of your
    calculations. -- J. R. R. Tolkien
    --
    Frank McKenney, McKenney Associates
    Richmond, Virginia / (804) 320-4887
    Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

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

    Thanks, Thad.

    On Sun, 12 Oct 2008 12:09:38 -0700 (PDT), Thad Floryan wrote:
    > On Oct 12, 9:42 am, Tauno Voipio wrote:
    >> [...]
    >> Let's split the header:
    >>
    >> ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    >>
    >> splits to:
    >>
    >> ff:ff:ff:ff:ff:ff Ethernet broadcast
    >> 00:1a:66:0f:24:7e sender MAC address
    >> 08:00 payload: IP
    >>
    >> I'd like to see what role does the IP address 169.254.1.147 have
    >> here. It is a link-local (zeroconf) address which should be used
    >> only when no other means for getting an IP address is available.
    >>
    >> The IP address 255.255.255.255 is a local link broadcast, so it is
    >> possible that the log message has confused source and destination
    >> IP addresses. It's perfectly healthy to send an IP packet to an IP
    >> address 255.255.255.255 and Ethernet address ff:ff:ff:ff:ff:ff.
    >>
    >> If you find the node in the local network having the MAC address
    >> 00:1a:66:0f:24:7e you may get answers to the above questions.
    >>
    >> Another way to get more info is to fire up tcpdump or Wireshark and
    >> capture the packets in full (instead of abbreviated header info).

    >
    > You beat me to a reply. :-)
    >
    > Also, the "169. ..." IP is something I see frequently at client
    > sites regarding misconfigured Windows systems. I'll bet that
    > matching the MAC address will point to a Windows box as the
    > source of the "Martians".


    Per my reply to Tauno, that's the address of the Coax interface on
    the Verizon cable modem. I won't claim I understand exactly what
    that implies, I just read it from the configuration display.

    > Often simply doing (in a Command Prompt window) "ipconfig /renew"
    > will clear up such problems assuming the TCP/IP setup is otherwise
    > correct. If it's a desktop system, using a static IP on the
    > WIndows box is often better than using DHCP (as is frequently
    > used for laptops).


    manticore uses a static IP address, as does the OS/2 machine and the
    Brother Ethernet-attached printer. The WinXP laptop uses
    wireless/DHCP.

    However, on my last round of testing (a few minutes ago) manticore
    was the only machine on the switch, and the wireless interface on
    the laptop was disconnected. That should have left everything but
    the cable modem, the switch, and manticore out of the picture, but
    manticore continued to receive the "martian" packets.

    Hope this information helps.


    Frank
    --
    Government is the great fiction, through which everybody
    endeavors to live at the expense of everybody else.
    -- Frederic Bastiat, French Economist
    --
    Frank McKenney, McKenney Associates
    Richmond, Virginia / (804) 320-4887
    Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

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

    General,

    Thanks for the contribution. (Loved your invasion. )

    On Sun, 12 Oct 2008 12:17:56 -0500, General Schvantzkopf wrote:
    > On Thu, 09 Oct 2008 16:19:34 -0500, Frnak McKenney wrote:
    >
    >> You start out with a single computer. You add another, you want them to
    >> talk to each other, and before you know it you have a Topsy-LAN
    >> connecting Linux, OS/2, and a couple of flavors of MSWinXX. Then you
    >> run into a problem, and you have to figure out how to make it go away...
    >>
    >> Here are some odd messages that are logged to 'manticore' (openSuSE
    >> 10.2) when it is connected to my Verizon Actiontec M1424 cablemodem
    >> (wrapped for legible posting):
    >>
    >> Oct 9 16:00:25 manticore kernel: martian source 255.255.255.255
    >> from 169.254.1.147, on dev eth0
    >> Oct 9 16:00:25 manticore kernel: ll header:
    >> ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    >> Oct 9 16:00:35 manticore kernel: martian source 255.255.255.255
    >> from 169.254.1.147, on dev eth0
    >> Oct 9 16:00:35 manticore kernel: ll header:
    >> ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    >> Oct 9 16:00:45 manticore kernel: martian source 255.255.255.255
    >> from 169.254.1.147, on dev eth0
    >> Oct 9 16:00:45 manticore kernel: ll header:
    >> ff:ff:ff:ff:ff:ff:00:1a:66:0f:24:7e:08:00
    >>
    >> The Actiontec ports are labelled WAN and LAN1-LAN4. Its 'web-based
    >> setup program shows the following device:
    >>
    >> IP-STB1 00:1a:66:0f:24:7e:08:00 Coax DHCP Connection=Bridge
    >>
    >> manticore is connected to port 1 of an Encore 8-port/N-way switch.
    >>
    >> If I don't connect the switch to the Actiontec, no (martian) warning
    >> messages appear.
    >>
    >> With a cable connecting (say) the Encore's #7 port to the Actiontec's
    >> LAN3 port but with the FiOS coax cable disconnected from the Actiontec's
    >> Coax port, no messages appear.
    >>
    >> With both links in place, the messages do appear.

    --snip--
    > I don't see mention of a router in your setup, just a switch. Put a router
    > between your switch and your modem, I'm pretty sure that will solve your
    > problem. In any event you always want a router between your network and a
    > modem because it provides a firewall.


    The Verizon FiOS cablemodem provides its own firewall. As for
    adding a router, I'd throw one into the mix if I could, but I don't
    have one lying around.


    Frank
    --
    I have self-confidence. You have pride. Everyone else is vain.
    --
    Frank McKenney, McKenney Associates
    Richmond, Virginia / (804) 320-4887
    Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

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

    On Oct 12, 5:03 pm, Frnak McKenney
    wrote:
    > [...]
    > The Verizon FiOS cablemodem provides its own firewall. As for
    > adding a router, I'd throw one into the mix if I could, but I don't
    > have one lying around.


    The $60 router I mentioned in an earlier post in this thread
    can be seen here:



    I bought (at a local Fry's, but their web ordering is excellent)
    and installed one for a client this past Friday.

    Point being: it looks like the "Martians" could be coming from
    your cable link. Without a firewall/router to block them, you'll
    be plagued forever.

    FOr close to a decade I had a 6Mbps Sprint Broadband link to the
    'Net; you can see the Sprint antenna on my tower here:



    The Sprint service was great, static IPs, etc. and was the
    only access to the 'Net (besides dialup) because neither
    DSL nor cable were available in this area until recently.

    I lost that service July 31, 2008, due to FCC reallocation of
    the frequency band, and lucked-out getting a fantastic cable
    deal (averaging 18Mbps). First thing I noticed was the LEDs
    on the cable modem are essentially useless due to all the
    broadband traffic. With my Sprint service, its modem only
    blinked its LEDs for traffic to/from me; not so for cable.

    I have a Sonicwall TZ170 which blocks all other cable traffic
    and, for only $60, the Linksys BEFSR41 would do the same for
    you.

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

    Great. Now I'm talking to myself.

    On Sun, 12 Oct 2008 18:59:02 -0500, Frnak McKenney wrote:
    > On Sun, 12 Oct 2008 16:42:40 GMT, Tauno Voipio wrote:
    >> Another way to get more info is to fire up tcpdump or Wireshark and
    >> capture the packets in full (instead of abbreviated header info).

    --snip--
    > I'll check to see if tcpdump is installed; I'm fairly sure Wireshark
    > isn't, but I can check around for an openSuSE 10.2 copy.


    'tcpdump was already installed; it took a bit of playing around to
    find a set of options that would dump one of the "martian" packets.
    What I'm seeing looks a bit like HTML; who the heck would be
    _broadcasting_ HTML?

    -------- 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 0x0030: 7443 6f6e 6669 673e 0a20 203c 4d73 6746 tConfig>... 0x0040: 6d74 5265 763e 323c 2f4d 7367 466d 7452 mtRev>2 0x0050: 6576 3e0a 2020 3c4d 7367 436f 6e74 5265 ev>...
    1 packets captured
    2 packets received by filter
    0 packets dropped by kernel
    manticore:~ #
    ------------------------------------------

    Does this provide any additional information to anyone?


    Frank
    --
    ˙Absence diminishes small loves and increases great ones, as the
    wind blows out the candle and blows up the bonfire.
    -- Francois de La Rouchefoucauld
    --
    Frank McKenney, McKenney Associates
    Richmond, Virginia / (804) 320-4887
    Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

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

    On Sun, 12 Oct 2008 21:02:28 -0500, Frnak McKenney wrote:
    > Great. Now I'm talking to myself.


    And now I'm answering?! Ack!

    --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 > 0x0030: 7443 6f6e 6669 673e 0a20 203c 4d73 6746 tConfig>... > 0x0040: 6d74 5265 763e 323c 2f4d 7367 466d 7452 mtRev>2 > 0x0050: 6576 3e0a 2020 3c4d 7367 436f 6e74 5265 ev>...

    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 )

    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.

    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/r205...hernet-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).

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

    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??

    I think it's time to do some more research on the cable modem's
    setup program and options.

    Almost there.


    Frank
    --
    "The gods confound the man who first found out how to distinguish
    the hours! Confound him, too, who in this place set up a sundial,
    to cut and hack my day so wretchedly into small pieces!"
    -- Plautus, 200 BCE
    --
    Frank McKenney, McKenney Associates
    Richmond, Virginia / (804) 320-4887
    Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

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

    Frnak McKenney wrote:
    > On Sun, 12 Oct 2008 21:02:28 -0500, Frnak McKenney wrote:
    >> Great. Now I'm talking to myself.

    >
    > 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 >> 0x0030: 7443 6f6e 6669 673e 0a20 203c 4d73 6746 tConfig>... >> 0x0040: 6d74 5265 763e 323c 2f4d 7367 466d 7452 mtRev>2 >> 0x0050: 6576 3e0a 2020 3c4d 7367 436f 6e74 5265 ev>...


    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 )


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


    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/r205...hernet-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

  17. 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 wrote:
    > Frnak McKenney wrote:
    >> On Sun, 12 Oct 2008 21:02:28 -0500, Frnak McKenney wrote:
    >>> Great. Now I'm talking to myself.

    >>
    >> 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 >>> 0x0030: 7443 6f6e 6669 673e 0a20 203c 4d73 6746 tConfig>... >>> 0x0040: 6d74 5265 763e 323c 2f4d 7367 466d 7452 mtRev>2 >>> 0x0050: 6576 3e0a 2020 3c4d 7367 436f 6e74 5265 ev>...

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

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

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

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

    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)


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

    Frnak McKenney wrote:
    > Tauno,
    >
    > Thanks again for your patience.


    Thank you - positive feedback keeps the response
    machinery running.

    Best regards from Helsinki, the birth city of Linux.

    --

    Tauno Voipio
    tauno voipio (at) iki fi