[Winpcap-users] use of winpcap with PLC net

[Jean-Luc Pamart]

Thank you for your answers.

I try to capture some traffic from a PLC/USB node at the very beginning 
of the power on of another PLC/USB device.
Like usual I see brodcast traffic, traffic from ant to my node but *in 
unicast, nothing concerning the other station*.

I am now sure that the PLC/brigdes can't be listen with winpcap. I think 
also that it's the case of all the sniffers acting at Ethernet level.
HOMEPLUG uses different channels and "private channels" for unicast traffic.

2 conséquences :

1/ HOMEPLUG nets are well protected (and even with the default HomePlug 
key your neighbour can't see all the traffic)
2/ it would be very expensive to listen HOMEPLUG nets (perhaps CIA could !)

Guy Harris a écrit :
> 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 bridge.
>
> 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
>
>     http://www.commsdesign.com/main/2000/12/0012feat5.htm
>
> 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.
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>