[Winpcap-users] use of winpcap with PLC net

Guy Harris 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 : 
> http://www.cnel.ufl.edu/~kkale/5718files/projReport.doc 
> <http://www.cnel.ufl.edu/%7Ekkale/5718files/projReport.doc>
>    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
>    bridging.
>    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 
transmitter interference.

	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 mailing list