[Winpcap-users] use of winpcap with PLC net
guy at alum.mit.edu
Sat Jan 26 23:04:54 GMT 2008
Jean-Luc Pamart wrote:
> Very important : at the very beginning (when the PLC/ETH bridges are
> powered) they are obliged to pass all the traffic on the PLC "bus ".
> So if winpcap is here => we can see this beginning traffic. Am I right ?
*If* the bridges work that way (i.e., they start up in "pass all
traffic" mode), yes, you would presumably see all traffic on your power
wiring until the bridge "learns" the MAC address of the machine doing
the capturing - and if you run Wireshark on a machine that *never*
transmits any packets on its Ethernet interface (that might be hard to
make happen), the bridge would presumably remain in that mode.
>> That might be worth trying. With a USB adapter, there might be
>> commands for the "Communications and CDC control" USB device class to
>> put the adapter into promiscuous mode, and that might cause the
>> adapter to capture all traffic on your power wires.
> Ok, I'll try that. But I have a doubt : perhaps PLC bridge hasn't the
> capability to pass in promiscuous mode (desperate)
> I hace found this document :
> an extract :
> MAC Level Bridging
> In the HomePlug Network System bridging is
> accomplished by source-aware bridging. There are
> two types of bridging prevalent in networks. One is
> transparent bridging while the other is source – aware
> While both use MAC level addressing, in transparent
> bridging the bridge gradually learns the addresses of
> the various stations and stores them in a forwarding
> table. It usually makes use of a spanning tree
> algorithm to avoid loops. Transparent bridging
> requires “promiscuous” reception of frames by the
> bridge. Powerline, because of its unstable nature
> requires the use of acknowledgements, which
> becomes an issue when combined with “promiscuous
> reception”. As acknowledgements occur while the
> station is considered active on the channel, they are
> required to be given special consideration.
> In source-aware bridging the bridge is addressed as an
> individual address in itself. Its address is mentioned
> directly in the frame header. The bridge proxy is
> obtained at the same time as when the station
> performs the initial channel estimation and obtains
> tone mapping.
I'm not sure what type of bridging they're talking about. They seem to
be talking about bridging between two networks, both of which have
multiple stations on them. A simple bridge to let you plug a computer
with an Ethernet into a HomePlug network has only one station on the
Ethernet, although I guess if you plug that simple bridge into a hub or
into the port on a switch used for forwarding traffic to other switches,
it acts as a full-blown bridge.
It sounds as if the bridges have their own MAC addresses; I presume the
"bridge proxy" works by having the bridges, when they see an ARP request
(or, at least, a broadcast ARP request) on the HomePlug network, forward
the ARP request to the Ethernet, and, if they receive a reply from the
host whose MAC address appears in the reply, replace that MAC address
with their own MAC address, so that other stations on the HomePlug
network will send packets to the bridge's MAC address, and the bridge
will forward those packets to the host that sent the ARP reply to the
With that type of bridge, it might again forward only broadcast and
multicast packets, and unicast packets intended for one of the hosts it
knows about, so you couldn't do promiscuous capture.
Again, that wouldn't apply to a USB adapter, though, as that's not a bridge.
*However*, if I'm correctly interpreting what I read at
there's a problem that might make it impossible to do promiscuous
capture on HomePlug with *any* adapter. That page says
Formed from a series of OFDM symbols, the HomePlug data-bearing packet
consists of a start-of-frame delimiter, a payload, and an end-of-frame
delimiter (see Figure 3). For unicast transmissions, the destination
station responds by transmitting a response delimiter indicating the
status of the reception (ACK, NACK, or FAIL).
The delimiter consists of a preamble sequence followed by a TPC encoded
frame control field. The preamble sequence is chosen to provide good
correlation properties so each receiver can reliably detect the
delimiter, even with substantial interference and a lack of knowledge of
the transfer function that exists between the receiver and the
The frame control contains MAC layer management information (for
example, packet lengths, and response status). The low rate TPC and
interleaving used on the frame control provide good immunity to
frequency selective impairments as well as broadband interference. All
three delimiter types have the same structure, but the data carried in
the delimiter varies depending on the delimiter function.
Unlike the delimiters, the payload portion of the packet is intended
only for the destination receiver. Payload data is carried only on a set
of carriers that have been previously agreed upon by the transmitter and
intended receiver during a channel adaptation procedure.
It sounds as if, even though the power wiring is treated as a shared
bus, so the analog signals for a packet can be seen by all stations on
the power wiring, only a station that knows what carriers are being used
for a particular packet's payload could demodulate those analog signals
and turn them into bits. The intended recipient knows that - but other
stations on the network might not. In theory, it might be possible for
a station to keep track of all sender/recipient pairs by watching the
negotiation traffic that I presume is used on the network (although if
the negotiation takes place before the sniffing station is plugged into
the network, that can't happen), but I suspect the normal bridges *and*
USB adapters you can get don't bother doing that.
I.e., it might be difficult, and maybe impossible, for any station on a
HomePlug network to capture all the traffic on that network.
More information about the Winpcap-users