tcpdump to watch *other* machines

I'm trying to watch http traffic initiated from machine A on a LAN from
machine B on same LAN, a linux box. This is mostly for convenience so I
don't need to install extra stuff on machine A. This is a simple home
LAN, not a business. I tried,

tcpdump 'dst port 80'

and

tcpdump 'tcp port 80'

and in either case only saw traffic where the linux machine was involved.

So I thought, duh, maybe it's because I have a switch and not a hub, since
the purpose of a switch is to *not* send packets not involving a machine
down *all* the wires like a hub does, right? Is that the only problem?
This is something tcpdump is supposed to be able to do, right? (I.e.
assuming a simple, cheap hub or old-fashioned coax ethernet "backbone"
type connections.)

wlcna wrote:
>
> I'm trying to watch http traffic initiated from machine A on a LAN from
> machine B on same LAN, a linux box. This is mostly for convenience so I
> don't need to install extra stuff on machine A. This is a simple home
> LAN, not a business. I tried,
>
> tcpdump 'dst port 80'
>
> and
>
> tcpdump 'tcp port 80'
>
> and in either case only saw traffic where the linux machine was involved.
>
> So I thought, duh, maybe it's because I have a switch and not a hub, since
> the purpose of a switch is to *not* send packets not involving a machine
> down *all* the wires like a hub does, right? Is that the only problem?
> This is something tcpdump is supposed to be able to do, right? (I.e.
> assuming a simple, cheap hub or old-fashioned coax ethernet "backbone"
> type connections.)

Yes, that is the problem, the switch doesn't send non broadcast packets
from machine A which are not destined for machine B to machine B.
There's nothing tcpdump can do about it when the packets don't even
appear on the interface.

If you used a hub instead it would indeed work as you expect.

You can get switches which will replicate traffic on one port onto
another for this purpose. But these tend to be the very expensive
"managed" variety, not the cheapo dumb ones people usually use on home
networks.

If you have a normal basic cheap switch then you have to run tcpdump on
one of the machines involved in the connection to see the packets.

If I'm interested in what a machine on the LAN is sending to the
Internet then I'll run tcpdump on the router, as all the external
traffic obviously has to pass through it. I don't really care about what
machines on the LAN are sending to each other.

Regards, Ian

"Ian Northeast" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "dst port 80" will, unsurprisingly, capture all packets sent to port 80.
> So it will match all requests sent by a web browser but not the
> responses. "port 80" alone will match all HTTP traffic on port 80 - it
> is of course possible to use HTTP without using port 80.
>

A sanity check, since it's my first time using it. I like that command!
Thanks very much again.

"wlcna" <(E-Mail Removed)> writes:

]I'm trying to watch http traffic initiated from machine A on a LAN from
]machine B on same LAN, a linux box. This is mostly for convenience so I
]don't need to install extra stuff on machine A. This is a simple home
]LAN, not a business. I tried,

]tcpdump 'dst port 80'

]and

]tcpdump 'tcp port 80'

man tcpdump
Look at the host option.


]and in either case only saw traffic where the linux machine was involved.

]So I thought, duh, maybe it's because I have a switch and not a hub, since
]the purpose of a switch is to *not* send packets not involving a machine
]down *all* the wires like a hub does, right? Is that the only problem?

Seems to be one problem.

]This is something tcpdump is supposed to be able to do, right? (I.e.

I do it all the time.


]assuming a simple, cheap hub or old-fashioned coax ethernet "backbone"
]type connections.)

Juha Laiho wrote:
>
> Ian Northeast <(E-Mail Removed)> said:

> >Yes, that is the problem, the switch doesn't send non broadcast packets
> >from machine A which are not destined for machine B to machine B.
> ...
> >If you used a hub instead it would indeed work as you expect.
>
> Of course, assuming that this is the OP's private home LAN (as he
> did say in the original posting), it should be possible to "collapse"
> the switch into a hub with certain attacks. After this, the snooping
> should succeed just fine (supposing that the switch collapses in
> a predictable manner, instead of crashing completely).

A bit of a drastic method of traffic snooping on the part of the
legitimate network administrator don't you think?

I'm not sure exactly what the OP is trying to do but I would be
surprised if there wasn't a better way to achieve it than that.

I once needed to capture all LAN traffic to and from a couple of
machines without using them, as I couldn't trust what they were
reporting themselves. The problem turned out to be dodgy daughter boards
that the NICs were plugged into. On this occasion I removed the problem
machines from the switch and put a hub in, and attached a sniffer to the
hub. Performance wasn't an issue as they weren't working properly in the
first place.

Regards, Ian