[Winpcap-users] use of winpcap with PLC net
jlpamart at yahoo.fr
Tue Jan 29 16:32:24 GMT 2008
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 :
>> 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 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
> *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.
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
More information about the Winpcap-users