I need to measure link delay in Ryu controller. I want to send a packet-out message for all switches by the controller and calculate the time between the sent packet-out message and received the packet-in message. I am a beginner in Ryu and don't know how to send a packet with specific EtherType such as 0x8fc to all switches. I have obtained the MAC of all switches and build a packet. how I can send a packet with specific EtherType to all switches? I don't know what is the db parameter for every switch?
def send_packet(self, dp, port, pkt):
ofproto = dp.ofproto
parser = dp.ofproto_parser
pkt.serialize()
data = pkt.data
action = [parser.OFPActionOutput(port=port)]
out = parser.OFPPacketOut(
datapath=dp, buffer_id=ofproto.OFP_NO_BUFFER,
in_port=ofproto.OFPP_CONTROLLER,
actions=action, data=data)
dp.send_msg(out)
def create_packet(self):
i=l=0
for l in range(1,len(self.adjacency)+1):
#print("\n")
for i in self.adjacency[l]:
ethertype = 0x8fc
dst = self.macaddr(i)
src = self.macaddr(l)
e = ethernet.ethernet(dst, src, ethertype)
p = packet.Packet()
p.add_protocol(e)
p.add_protocol(time.time())
p.serialize()
port=self.adjacency[l][i]
send_packet(self, dp **??????** , port, p):
DP is the abbreviation for DataPathID that is kind of Uniq ID for an OpenFlow switch in your network.
According to the OpenFlow specification:
“The datapath_id field uniquely identifies a datapath. The lower 48
bits are intended for the switch MAC address, while the top 16 bits
are up to the implementer. An example use of the top 16 bits would be
a VLAN ID to distinguish multiple virtual switch instances on a single
physical switch.”
If you're using Mininet and for example, you run linear topology:
mn --controller remote --topo linear,3
Your topology will be:
s1 -- s2 -- s3
| | |
h1 h2 h3
DataPathID's will be:
s1: 0x0000000000000001
s2: 0x0000000000000002
s3: 0x0000000000000003
Pay attention that in other testbeds this numbers may be different but they're alway 16 digit hex.
Related
TMP102 chip( http://www.ti.com/lit/ds/symlink/tmp102.pdf ) can have multiple I2c slave addresses. It has an address pin called ADD0(Section 5) which can be used to select multiple addresses(Section 7.3.4). The logic level at that pin can be used to select a particular TMP102 slave device. According to table 4, 4 addresses are possible. I do understand that connecting the pin to high or low voltage will produce two different addresses. But the table mentions that we can use SDA and SCL pins for two different addresses. I am not sure how this works. Can anyone explain how can this be used and how can we use multiple TMP102 devices based on SDA and SCL pins.
The logic level at that pin can be used to select a particular TMP102 slave device
That is not the purpose of ADD0 - it is a configuration pin, not a select pin. It is not used to select the device; I2C addresses are part of the data stream on SDA, there is no "select" pin as there is on SPI for example.
Rather, ADD0 is used to define the address of each device to one of four defined in Table 4. Those addresses being one of 0x48, 0x49, 0x4A or 0x4B depending on connection of ADD0 to GND, V+, SDA or SDL respectively. Like so:
How the device determines the address is not revealed in the datasheet and you don't really need to know, but given:
Public domain image by Marcin Floryan from https://en.wikipedia.org/wiki/I%C2%B2C
at the start condition at the falling edge of SDA the following occurs:
ADDR ADD0 SDA SCL
0x48 0 v 1
0x49 1 v 1
0x4A v v 1
0x4B 1 v 1
Then on the next falling edge SCL
ADDR ADD0 SDA SCL
0x48 0 0 v
0x49 1 0 v
0x4A 0 0 v
0x4B v 0 v
So it is possible with suitable sequential logic to latch the address by the end of the S phase and before B1 which is sufficient because the address match does not occur until B7, and all devices on the bus must listen for the address.
You connect ADD0 to SDA/SCL to get those other addresses. The table shows the address you get based on what ADD0 is connected to.
Do you know how to set up the Spreading Factor to 12 in a Mbed-OS LoRaWAN protocol APIs to connect to a LoRaWAN network using OTAA?
I'm trying to make LoRA node to use Spreading Factor SF12, because the default one is SF7. I know that in the PHY layer we can change Radio configurations. There are several examples to change between the different sub-GHz frequency bands, however, I can't find one on how to change the LoRa modulation SF between 7 and 12 and with a bandwidth of 125 kHz.
I'm using an SX1276 radio at EU 868 MHz config.
In the source code you can find the SF7-12 different configurations, but there is not a clear way to set it up. These configs are the definitions (#define) DR_0, DR_, etc ).
In the configuration file in the Phy part you find some example like this:
"phy": {
"help": "LoRa PHY region. 0 = EU868 (default), 1 = AS923,
2 = AU915, 3 = CN470, 4 = CN779, 5 = EU433,
6 = IN865, 7 = KR920, 8 = US915, 9 = US915_HYBRID",
"value": "0"
},
But there is no examples or description for the Spreading Factor.
I would like to change it via source code, rather than the configuration file.
EDIT 1:
after Jon's answer, I add the following lines, but still not forcing the SF12 Joins.
retcode = lorawan.disable_adaptive_datarate ();
retcode = lorawan.set_datarate (0); // DR_0
Call:
lorawan.set_datarate(0); // SF12 125 KHz
Make sure to:
Disable ADR.
Either use ABP, or call the function above in the JOIN_SUCCESS event handler. This is because join procedure always starts at SF7, and then keeps the data rate on which the join succeeded.
At the interface level DCCP is like TCP: you connect and then send/receive bytes.
I was wondering it's possible to make dccp connections in twisted by just adapting the wrappers for tcp...
According to the sample code (below) what needs to be changed is:
at socket instantiation: use different parameters
before using the socket: set some options
Then everything else would be the same...
Hints: I've spotted addressFamily and socketType in the sources of twisted but I have no idea on how to cleanly set them in the protocol factory. Also the protocol number, the 3rd parameter, here IPPROTO_DCCP, is always keeped to default. I have no clue either on how to access the socket to call setsockopt
import socket
socket.DCCP_SOCKOPT_PACKET_SIZE = 1
socket.DCCP_SOCKOPT_SERVICE = 2
socket.SOCK_DCCP = 6
socket.IPPROTO_DCCP = 33
socket.SOL_DCCP = 269
packet_size = 256
address = (socket.gethostname(),12345)
# Create sockets
server,client = [socket.socket(socket.AF_INET, socket.SOCK_DCCP,
socket.IPPROTO_DCCP) for i in range(2)]
for s in (server,client):
s.setsockopt(socket.SOL_DCCP, socket.DCCP_SOCKOPT_PACKET_SIZE, packet_size)
s.setsockopt(socket.SOL_DCCP, socket.DCCP_SOCKOPT_SERVICE, True)
# Connect sockets
server.bind(address)
server.listen(1)
client.connect(address)
s,a = server.accept()
# Echo
while True:
client.send(raw_input("IN: "))
print "OUT:", s.recv(1024)
More about DCCP:
https://www.sjero.net/research/dccp/
https://wiki.linuxfoundation.org/networking/dccp
TL;DR: dccp is a protocol that provides congestion control (like tcp) without guaranteeing reliability or in-order delivery of data (like udp). The standard linux kernel implements dccp.
I used STM32CubeMX version 4.22 to generate MSC usb device and modified it to have 2 custom bulk interfaces. Interface 0 has 2 BULK endpoints IN and OUT. Interface 1 have two alternate settings. Alt Setting 0 has 0 endpoints and Alt Setting 1 have 2 BULK endpoints IN and OUT.
Endpoints are defined as :
define INTERFACE0_IN_EP 0x81
define INTERFACE0_OUT_EP 0x01
define INTERFACE1_IN_EP 0x82
define INTERFACE1_OUT_EP 0x02
My device enumerates fine and Interface 0 works as expected. Host sends Set Interface 1, Alt Setting 1 request then i activate Interface 1 endpoints (0x82 and 0x02).
Interface 1 is not working as expected, i am sure it has something to do with my FIFO Settings. I get dataOut Call for INTERFACE1_OUT_EP but when i try to write INTERFACE1_IN_EP host only get 3 bytes back while i am writing 24 bytes. Immediately after this transaction i get CLEAR FEATURE request for interface 1 endpoints.
Here is my current FIFO Settings :
HAL_PCDEx_SetRxFiFo(&hpcd_USB_OTG_FS, 0xC0); //80
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 0, 0x40); //EP0
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 1, 0x80); //EP1
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 2, 0x40); //<-- If i don't add this line Host can not get any thing back, After adding this line host only receives 3 bytes on INTERFACE1_IN_EP.
Please help me to configure these FIFO settings properly so that second interface can also work as expected.
There are only 0x140 x 4(=1280bytes) available for USB FIFO in STM32.
But you used 0x180(=c0 + 40 + 80) x 4(=1536bytes).
I'm building an embedded device with a couple of sensors. The device will 'stream' digital data from these sensors over Bluetooth or USB.
Most of the communication will be from the embedded device to the host. The host will infrequently be sending control messages, to control the gain etc.
Since the physical and data link layers are taken care of, I'm looking for a simple message protocol that will make it easy to develop user applications to process/display data on the host computer. Does anyone have any suggestions?
A simple text protocol may be the best for this application.
Use the communication channel as a bi-directional serial pipe.
The device can stream sensor values in ASCII (text) format, separated by commas, with each set separated by the newline character. The rate is preferably set by the host.
For example,
21204,32014 (new line character '\n' - 0x0A) at the end of each line
21203,32014
21202,32011
....
This makes it easier to test, to stream the values to a file, import in to a spreadsheet etc.
Similarly commands to the device too, is best done in text.
SET GAIN_1 2 ( sent by host )
OK ( reply by device )
SET GAIN_2 4 (sent by host )
OK ( reply by device )
SET GAIN_9 2 (sent by host )
ERROR ( reply by device if it does not understand)
SET RATE 500 ( set the sensor dump rate to every 500 ms )
OK