mirror of
https://github.com/uhi22/pyPLC.git
synced 2024-11-20 01:13:58 +00:00
docu: EvseMode details
This commit is contained in:
uhi22
parent
a04069be89
commit
939613d255
8 changed files with 288 additions and 24 deletions
132
doc/EvseMode.md
Normal file
132
doc/EvseMode.md
Normal file
|
|
@ -0,0 +1,132 @@
|
|||
# EvseMode
|
||||
|
||||
This document describes how to use the pyPlc project as a charging station. The possible use cases are to really charge a car via CCS (which requires a lot of additional power-electric hardware), or to investigate whether it is possible to draw energy out of the cars CCS port.
|
||||
|
||||
Discussion here: https://openinverter.org/forum/viewtopic.php?t=3551
|
||||
|
||||
## Hardware
|
||||
|
||||
To convince the car, that a CCS charger is connected, several preconditions need to be fulfilled:
|
||||
* PP resistor: Between the ProximityPilot and PE (Ground) we must connect 1.5kOhms resistor.
|
||||
* CP signalling: The ControlPilot needs to be pulled to 12V over 1kOhms. If the car pulls the CP down to 9V, we must provide a PWM with 1kHz, 5% width, plus and minus 12V amplitude via 1kOhm resistor. Basically the CP signalling is the same as in a standard AC wallbox, the only difference is the fix 5% PWM ratio. As wallbox controller I used an arduino, similar to https://www.instructables.com/Arduino-EV-J1772-Charging-Station with the software https://github.com/uhi22/WallboxArduino, and the poti on left border to select 5% PWM.
|
||||
* Homeplug communication: The car wants to establish high-level communication on the CP line, using the HomePlug standard. We connect a modified homeplug modem between the CP and PE, with coupling network e.g. 150 ohms and 1nF in series, to not disturb the 1kHz PWM too much. The modification of the modem is shown in [Hardware manual](hardware.md)
|
||||
* On the ethernet port of the HomePlug modem we connect a computer which handles the high level communication. This may be a Windows10 laptop or a Raspberry or similar.
|
||||
* We need a power supply for the HomePlug modem and the Arduino-charging-logic, e.g. an USB power bank.
|
||||
|
||||
## Software
|
||||
|
||||
### Configuring the HomePlug modem as Charging Station
|
||||
|
||||
The homeplug modem needs a special configuration, to support the features which are needed for a charging station. We need to write a special configuration file to it. This is necessary only once, the modem will store the settings non-volatile.
|
||||
Details in readme.md chapter "Configuration of the PLC adaptor"
|
||||
|
||||
### Installing pyPlc and openV2Gx on the computer
|
||||
See [Raspberry installation manual](installation_on_raspberry.md) or
|
||||
[Windows installation manual](installation_on_windows.md)
|
||||
|
||||
## First run into charging loop
|
||||
Notebook is connected via Ethernet cable to the homeplug modem. The homeplug modem and the arduino-charging-logic is supplied by an USB power bank. The PE from the car is connected to ground of the homeplug modem and ground of the arduino-charging-logic. The CP of the vehicle is connected to the hot side of the homeplug modem and the hot side of the arduino-charging-logic. The PP of the car is connected to PE via 1k5 (inside the plug).
|
||||
On the laptop, just run `python pyPlc.py E`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### TPlink TL-PA4010P
|
||||
This adaptor was suggested by https://openinverter.org/forum/viewtopic.php?p=37085#p37085 and there,
|
||||
successfully used to establish a communication to the CCS charger.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Pro:
|
||||
* Can be configured as pev and as EVSE, using two different configuration files (created and patches with github.com/qca/open-plc-utils)
|
||||
* Is able to transmit and receive the SLAC messages, if the special config files are used.
|
||||
|
||||
Contra:
|
||||
* In original parametrization, does not support SLAC (not routed from RF to Ethernet, and not vice versa).
|
||||
* Depending on the configuration, only one direction of the SLAC is routed from RF to Ethernet. Means: Not suitable for sniffing the complete
|
||||
SLAC sequence.
|
||||
|
||||
Power supply: Originally, it has 12V internal supply. There is a DC/DC step down converter included, which supplies the chipset with 3.3V.
|
||||
Works on the original 12V supply line also with 13V/110mA, 10V/120mA, 6V/190mA, and, which reduced RF output power, down to 5V/220mA and even 4V/240mA.
|
||||
Just supplying 5V from an USB power bank at the original 12V line works fine. The only drawback is a slightly reduced transmit power, because
|
||||
the RF transmitter is connected to the 12V, but is is no issue, because it has anyway much too much transmit power for the CCS use case.
|
||||
|
||||
How to modify:
|
||||
- remove the housing
|
||||
- remove the AC power connector parts
|
||||
- connect cables to supply the device. Works with 12V, also works with 5V from an USB power bank.
|
||||
- connect cables and circuit (1nF and 150ohms in series) for connecting to the pilot line.
|
||||
|
||||
## Controller for the PEV
|
||||
|
||||
Besides the homeplug modem, there are additional parts necessary for a vehicle to perform CCS charging. Two of these are: 1. The inlet voltage measurement. 2. The control of CP state and relays.
|
||||
|
||||
### DieterHV
|
||||
|
||||
This is the high-voltage Dieter. It is responsible to measure the CCS inlet voltage. DieterHV is an Arduino Pro Mini, running the software from https://github.com/uhi22/dieter, and DieterHV has a quite simple task: Measure the divided voltage from the CCS inlet, and write the output of the ADC to the serial line, with 19200 Baud. The hardware includes a 5V-to-5V-DCDC converter (e.g. B0505S-1W) and a PC900V optocoupler. In the current version, the ADC0 is the main channel, and the ADC1 gets half of the voltage and may be used for plausibilization. Potential improvement could be, to enable also negative voltage measurement, to be able to detect wrong polarity.
|
||||
|
||||
|
||||
|
||||
|
||||
### DieterLV
|
||||
|
||||
This is the low-voltage Dieter. It controls the ControlPilot state, by switching an additional 1.2kOhm resistor in parallel to the permanently connected 2.7kOhm. Additionally, the DieterLV controls two relays via simple drivers. In the demo, these relays connect the DC from the CCS inlet to a light bulb.
|
||||
Also DieterLV is an Arduino Pro Mini, and it is running the same software as DieterHV. It receives the output control requests via serial line with 19200 Baud, and sets its digital outputs accordingly.
|
||||
|
||||
|
||||
|
||||
### OLED Display
|
||||
|
||||
To show the status, the voltage and the SOC in PEV mode, there is an OLED display connected to the serial line of the USB-to-serial-converter.
|
||||
The display is programmed to receive data via serial line and show three lines. The python script is using the function self.hardwareInterface.showOnDisplay(s, strAuxInfo1, strAuxInfo2)
|
||||
to fill these three lines on the display.
|
||||
|
||||
The display is an ESP32-powered board named "WIFI_KIT-32", available e.g. from
|
||||
https://de.aliexpress.com/item/1005002931025729.html?spm=a2g0o.productlist.main.23.3d607f4fVNGcAr&algo_pvid=338e0303-b3b2-45c7-94b6-4a55bba4009e&algo_exp_id=338e0303-b3b2-45c7-94b6-4a55bba4009e-11&pdp_ext_f=%7B%22sku_id%22%3A%2212000022853967835%22%7D&pdp_npi=3%40dis%21EUR%2113.87%2111.37%21%21%21%21%21%402100b78b16774931785037679d0714%2112000022853967835%21sea%21DE%210&curPageLogUid=TGlYiLzgZW4i
|
||||
|
||||
The arduino sketch is available at https://github.com/uhi22/SerialToOLED
|
||||
|
||||
The connection is simple: The 5V from the USB-to-Serial-converter board are supplying the WIFI_KIT-32, and the TXD of the USB-to-Serial-converter goes via an 1k5 protection resistor to a digital input of the WIFI_KIT_32.
|
||||
|
||||
|
||||
|
||||
|
||||
### USB
|
||||
|
||||
Both, DieterHV and DieterLV communicate with 5V serial line with 19200 Baud. To connect these to the Laptop or Raspberry, we use a cheap USB-to-Serial converter with CP2102, similar to https://www.ebay.de/itm/122447169355?hash=item1c826b874b:g:PKYAAOSwBoVjdS28&amdata=enc%3AAQAHAAAA4IQcw6se5g1eqWsesz2sVJybly8WfWQrHcT%2BKk2kbf3dRjRl5Iimf8p54m2HcnGpjpFaTQqdKE0wrxuPJYLQcmOtofOYlAbClGhlgeIn21NQPaCGzqCSAMAI6yXqfsfCpsBZtJe1%2BfAfIOq1kEPDJBbWD6UFAv6%2FhR%2B6WxeiQKeaVSwc%2BRs87aBn0XbtWmF2p0C9RTURpWQauDpaWLsAthbiVBqBjeNkPQxMSx1AMUa33bO0OZakXjXyHVrGhEXRO7952z1oHjKyl51E0YX7Jqb5hA7GhAs%2BUGvPnBAbjKnH%7Ctkp%3ABFBMipSf-Kdh
|
||||
Its receive path is feed by the DieterHV via optocoupler, and its transmit path is connected to the DieterLV via a protection resistor.
|
||||
On software side, the python module hardwareInterface.py handles the communication with the serial devices.
|
||||
|
||||
## CCS Detector
|
||||
|
||||
In some cases it may help to "hear" the CCS communication, to understand what is going on. For this, a detector receiver can be used,
|
||||
e.g. this one:
|
||||
|
||||
|
||||
By placing the antenna near to the charging cable and just listening, it is possible to differentiate the following cases:
|
||||
* Silence: No communication is going on. No homeplug coordinator is present. No 1kHz PWM is present.
|
||||
* Continuous uniform rattling noise: Homeplug coordinator (charger) is there. Depending on the chargers implementation, this may be quite loud (e.g. Compleo) or less loud (e.g. Alpitronics).
|
||||
* 1kHz tone: The charger provides 1kHz PWM.
|
||||
* Click tones in faster or slower intervals: The communication is ongoing (SLAC, SDP, TCP). Depending on the implementation of the charger and car, this may be very loud (e.g. TPlink modem supplied by 12V) or less loud (some original cars).
|
||||
|
||||
## Electric vehicle simulator
|
||||
|
||||
This device is able to convince an AC charger to deliver power, and also is needed to tell an DC charger, that a car is connected. By closing the "vehicle detected" switch, we pull the CP from 12V to 9V, and the charger will switch to the 5% PWM and starts listening to SLAC parameter request messages. (If DieterLV is controlling the CP, we do not need the EV simulator anymore.)
|
||||
|
||||
|
||||
|
||||
|
||||
## Combination of EV simulator, HomePlug modem and Raspberry
|
||||
|
||||
|
||||
|
||||
## Connecting to a real-world charger
|
||||
|
||||
|
||||
|
||||
BIN
doc/foto_EvseMode_IoniqOutside.png
Normal file
BIN
doc/foto_EvseMode_IoniqOutside.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 679 KiB |
BIN
doc/foto_EvseMode_IoniqTrunk.png
Normal file
BIN
doc/foto_EvseMode_IoniqTrunk.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 958 KiB |
|
|
@ -1,5 +1,7 @@
|
|||
# Installation on Raspberry Pi
|
||||
|
||||
Pitfall: Pcap-ct does not work with Python 3.4. After update to Python 3.8, it works.
|
||||
|
||||
To try out, we use an old raspberry pi (first generation).
|
||||
|
||||
Install an image on a fresh 16GB SD card, using the Raspberry Pi Imager from https://www.raspberrypi.com/software/.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,72 @@
|
|||
# Installation on Windows10
|
||||
|
||||
1. Install python (windows automatically launches the installer if you type „python“ into the search field of the task bar)
|
||||
2. Install Wireshark, this includes the pcap driver, which is necessary for low-level-network-interaction
|
||||
3. Install git (recommended, but not necessary if you get the sources from git on an other way, e.g. via zip download)
|
||||
4. Install mingw32 (if not included in the git installation)
|
||||
|
||||
5. Install python libraries
|
||||
Attention: There are (at least) three different python-libs available for pcap:
|
||||
- Libpcap
|
||||
- Pylibpcap (But: only Python2)
|
||||
- Pypcap (recommented on https://stackoverflow.com/questions/63941109/pcap-open-live-issue)
|
||||
- Pcap-ct (https://pypi.org/project/pcap-ct/)
|
||||
We use the last one.
|
||||
python -m pip install --upgrade pcap-ct
|
||||
This is fighting against the Libpcap-installation, so we need to deinstall the second:
|
||||
python -m pip uninstall libpcap
|
||||
Then again install pcap-ct, and finally add in the libpcap\_platform\__init__py the missing is_osx = False. (Is in the meanwhile fixed in the github repository.)
|
||||
|
||||
6. Clone the two github repositories, and compile the OpenV2Gx EXI decoder/encoder:
|
||||
Create or use a folder, where you want to store the tools, e.g. C:\myprogs\ and open a command prompt there.
|
||||
```
|
||||
git clone http://github.com/uhi22/pyPlc
|
||||
git clone http://github.com/uhi22/OpenV2Gx
|
||||
cd OpenV2Gx\Release
|
||||
mingw32-make all
|
||||
```
|
||||
|
||||
(this may take some minutes)
|
||||
|
||||
Test the EXI decoder/encoder
|
||||
```
|
||||
cd myprogs\OpenV2Gx\Release
|
||||
OpenV2G.exe DD809a0010d0400000c800410c8000
|
||||
OpenV2G.exe EDB_5555aaaa5555aaaa
|
||||
```
|
||||
This should run without error and show the decoded/encoded data in the command window.
|
||||
|
||||
Now we go to the python part.
|
||||
```
|
||||
cd $home/myprogs/pyPlc
|
||||
```
|
||||
|
||||
Check python version
|
||||
|
||||
`python --version`
|
||||
reports e.g. 3.9.2.
|
||||
|
||||
7. Edit the configuration file
|
||||
The file pyPlc.ini can be changed in a way to fit the needs. E.g. the default behavior (PevMode or EvseMode) can be configured,
|
||||
for the case that the pyPlc script is called without command line arguments.
|
||||
|
||||
8. Edit the MAC of the network interface
|
||||
(Not clear, whether this is still needed. Todo: optimize code and description...)
|
||||
Find out the MAC address of the laptops ethernet interface, by running `ipconfig -all` in the command line.
|
||||
Edit the file addressManager.py and write your MAC into the MAC_LAPTOP variable.
|
||||
|
||||
9. Perform a simulated charging session
|
||||
Open two command line windows.
|
||||
In one command line, start the charger (EVSE) in simulation mode: `python pyPlc.py E S`.
|
||||
In the other window, start a car (PEV) in simulation mode: `python pyPlc.py P S`.
|
||||
Each of it should show a window where we can see how the charging works.
|
||||
|
||||
10. Perform a real charging session
|
||||
If you have set the intended mode in the pyPlc.ini, simply call `python pyPlc.py`.
|
||||
|
||||
## Driver for the USB-to-Serial brigde
|
||||
|
||||
(This is optional and only necessary, if devices like Dieter or display is planned to be used on a USB-to-serial converter.)
|
||||
For the USB-to-Serial bridge, which is sold as CP2102, the Windows 10 tries to install the driver when plugged-in. But
|
||||
the device did not work together with the driver which windows found automatically. A root cause may be, that the
|
||||
device is not an original CP2102, but a clone. Finally found a driver on https://www.pololu.com/docs/0J7/all, which works.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@
|
|||
- [x] PevMode: Connect the inlet voltage measurement
|
||||
- [x] PevMode: Connect the control of CP
|
||||
- [x] PevMode: Connect the control of Relay
|
||||
- [ ] docu: add link to evse which provides the 5% PWM)
|
||||
- [x] docu: add link to evse which provides the 5% PWM)
|
||||
- [ ] docu: add hardwareInterface into software architecture puml
|
||||
- [ ] docu: create hardware architecture picture
|
||||
- [x] docu for Dieter (Schematic, concept idea, DieterLV, DieterHV, ...)
|
||||
|
|
|
|||
27
readme.md
27
readme.md
|
|
@ -6,7 +6,7 @@ This project tries to use cheap powerline network adaptors for communication wit
|
|||
There are three different use cases, where this project can be helpful:
|
||||
1. Sniffing the traffic between an CCS charger and a car. For instance to measure which side is the limiting element for reduced charging power.
|
||||
In this project, we call this mode *ListenMode*.
|
||||
2. Building a charger for CCS or for AC with digital communication. We call this *EvseMode*.
|
||||
2. Building a charger for CCS or for AC with digital communication. We call this *EvseMode*. [EvseMode manual](doc/EvseMode.md)
|
||||
3. Building a charging unit for a car which does not support powerline communication. Let's call it *PevMode*.
|
||||
|
||||
## News / Change History / Functional Status
|
||||
|
|
@ -35,6 +35,7 @@ the specification says that a physical measurement shall be done. The Ioniq does
|
|||
reported voltage on the charger. After closing the contacts, there is the accu voltage on the CCS. Not yet
|
||||
tested, whether it is possible to draw some current out of the vehicle.
|
||||
Log here: results/2023-04-16_at_home_Ioniq_in_currentDemandLoop.pcapng
|
||||
Docu here: [EvseMode manual](doc/EvseMode.md)
|
||||
|
||||
### 2023-03-03 v0.6 Tea-Time on Alpitronics charger
|
||||
Made a tea, using the RaspberryPi3 and tpLink modem on Alpitronics hypercharger.
|
||||
|
|
@ -209,27 +210,12 @@ Write the configuration file to the PLC adaptor
|
|||
The open-plc-utils contain the programs evse and pev, which can be used for try-out of the functionality, using two PLC adaptors.
|
||||
|
||||
## Installation / Preconditions on PC side
|
||||
|
||||
### Usage on Windows10
|
||||
|
||||
1. Install python (windows automatically launches the installer if you type „python“ into the search field of the task bar)
|
||||
2. Wireshark is already installed, this includes the pcap driver, which is necessary for low-level-network-interaction
|
||||
|
||||
Attention: There are (at least) three different python-libs available for pcap:
|
||||
- Libpcap
|
||||
- Pylibpcap (But: only Python2)
|
||||
- Pypcap (recommented on https://stackoverflow.com/questions/63941109/pcap-open-live-issue)
|
||||
- Pcap-ct (https://pypi.org/project/pcap-ct/)
|
||||
|
||||
We use the last one.
|
||||
python -m pip install --upgrade pcap-ct
|
||||
This is fighting against the Libpcap-installation, so we need to deinstall the second:
|
||||
python -m pip uninstall libpcap
|
||||
Then again install pcap-ct, and finally add in the libpcap\_platform\__init__py the missing is_osx = False. (Is in the meanwhile fixed in the github repository.)
|
||||
See [Windows installation manual](doc/installation_on_windows.md)
|
||||
|
||||
### Usage on Raspberry
|
||||
Pitfall: Pcap-ct does not work with Python 3.4. After update to Python 3.8, it works.
|
||||
|
||||
See See [Raspberry installation manual](doc/installation_on_raspberry.md)
|
||||
See [Raspberry installation manual](doc/installation_on_raspberry.md)
|
||||
|
||||
### Usage on Microcontrollers
|
||||
This python project is NOT intended for use on microcontrollers like ESP32 or STM32. But there is a variant ported to C for
|
||||
|
|
@ -377,7 +363,8 @@ See [todo.md](doc/todo.md) and [bug_analysis.md](doc/bug_analysis.md)
|
|||
Good question. This depends on how strict the car is. This first hurdle is to convince the car, to close the relay. This is
|
||||
done after a successful PreCharge phase. And it depends on the implementation of the car, whether it needs physically correct
|
||||
voltage on the inlet before closing the relay, or whether it relies on the pretended voltage in the PreChargeResponse message.
|
||||
The Hyundai Ioniq 2016 closes the contactors by just a simulated charging session. Discussion in https://openinverter.org/forum/viewtopic.php?t=3551, pictures here: https://openinverter.org/forum/viewtopic.php?p=55656#p55656
|
||||
With setup from [EvseMode manual](docu/EvseMode.md),
|
||||
the Hyundai Ioniq 2016 closes the contactors by just a simulated charging session. Discussion in https://openinverter.org/forum/viewtopic.php?t=3551, pictures here: https://openinverter.org/forum/viewtopic.php?p=55656#p55656
|
||||
The second hurdle is, that the car may make a plausibilization between the expected current flow (charging) and the actually
|
||||
measured current flow (discharging). The car may stop the complete process, if the deviation is too high or/and too long.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@ MAC_DEVOLO_26 = [0xBC, 0xF2, 0xAF, 0x0B, 0x8E, 0x26 ] # Devolo PLC adaptor
|
|||
MAC_IPv6MCAST1 = [0x33, 0x33, 0x00, 0x00, 0x00, 0x01 ] # IPv6 multicast MAC
|
||||
MAC_RANDCAR = [0x04, 0x65, 0x65, 0x00, 0xaf, 0xfe ] # random hyundai car
|
||||
|
||||
mac_test = [0xb8, 0x27, 0xeb, 0x27, 0x33, 0x50 ]
|
||||
|
||||
class tester():
|
||||
|
||||
|
|
@ -102,6 +103,77 @@ class tester():
|
|||
self.sniffer.sendpacket(bytes(self.mytransmitbuffer))
|
||||
print("transmitted test frame 1")
|
||||
|
||||
def sendTestFrame2(self):
|
||||
self.mytransmitbuffer = bytearray(72)
|
||||
self.cleanTransmitBuffer()
|
||||
# Destination MAC
|
||||
self.fillDestinationMac(MAC_IPv6MCAST1)
|
||||
# Source MAC
|
||||
self.fillSourceMac(mac_test)
|
||||
# Protocol
|
||||
self.mytransmitbuffer[12]=0x86 # IPv6
|
||||
self.mytransmitbuffer[13]=0xdd
|
||||
self.mytransmitbuffer[14]=0x60 #
|
||||
self.mytransmitbuffer[15]=0x00 #
|
||||
self.mytransmitbuffer[16]=0x00 #
|
||||
self.mytransmitbuffer[17]=0x00 #
|
||||
|
||||
self.mytransmitbuffer[18]=0x00 # len 2 bytes
|
||||
self.mytransmitbuffer[19]=0x12 #
|
||||
|
||||
self.mytransmitbuffer[20]=0x11 # next is UDP
|
||||
self.mytransmitbuffer[21]=0x0A # hop limit
|
||||
|
||||
self.mytransmitbuffer[22]=0xfe # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[23]=0x80 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[24]=0x00 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[25]=0x00 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[26]=0x00 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[27]=0x00 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[28]=0x00 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[29]=0x00 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[30]=0x06 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[31]=0x65 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[32]=0x65 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[33]=0xff # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[34]=0xfe # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[35]=0x00 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[36]=0x64 # 22 to 37 ip source address
|
||||
self.mytransmitbuffer[37]=0xc3 # 22 to 37 ip source address
|
||||
|
||||
self.mytransmitbuffer[38]=0xff # 38 to 53 ip destination address
|
||||
self.mytransmitbuffer[39]=0x02 # 38 to 53 ip destination address
|
||||
self.mytransmitbuffer[53]=0x01 # 38 to 53 ip destination address
|
||||
|
||||
self.mytransmitbuffer[54]=0xcc # source port
|
||||
self.mytransmitbuffer[55]=0xab
|
||||
|
||||
self.mytransmitbuffer[56]=0x3b # dest port
|
||||
self.mytransmitbuffer[57]=0x0e
|
||||
|
||||
self.mytransmitbuffer[58]=0x00 # length
|
||||
self.mytransmitbuffer[59]=0x12
|
||||
|
||||
self.mytransmitbuffer[60]= 0x89 # checksum
|
||||
self.mytransmitbuffer[61]= 0x62
|
||||
|
||||
self.mytransmitbuffer[62]= 0x01
|
||||
self.mytransmitbuffer[63]= 0xFE
|
||||
|
||||
self.mytransmitbuffer[64]= 0x90
|
||||
self.mytransmitbuffer[65]= 0x00
|
||||
|
||||
self.mytransmitbuffer[66]= 0x00
|
||||
self.mytransmitbuffer[67]= 0x00
|
||||
self.mytransmitbuffer[68]= 0x00
|
||||
self.mytransmitbuffer[69]= 0x02
|
||||
|
||||
self.mytransmitbuffer[70]= 0x10
|
||||
self.mytransmitbuffer[71]= 0x00
|
||||
|
||||
self.sniffer.sendpacket(bytes(self.mytransmitbuffer))
|
||||
print("transmitted test frame 2")
|
||||
|
||||
|
||||
|
||||
def findEthernetAdaptor(self):
|
||||
|
|
@ -149,7 +221,13 @@ class tester():
|
|||
|
||||
t=tester()
|
||||
print(256 ** 2)
|
||||
for i in range(0, 100):
|
||||
t.sendTestFrame1()
|
||||
time.sleep(0.5)
|
||||
for i in range(0, 1000):
|
||||
t.sendTestFrame2()
|
||||
mac_test[5]+=1
|
||||
if (mac_test[5]>255):
|
||||
mac_test[5]=0
|
||||
mac_test[4]+=1
|
||||
if (mac_test[4]>255):
|
||||
mac_test[4]=0
|
||||
time.sleep(0.01)
|
||||
t.close()
|
||||
|
|
|
|||
Loading…
Reference in a new issue