[pox-dev] Can pox connect or communicate with host?

[Chanthan Hel]

Dear all,
As usual, POX can connect and keep communication with of switch.
In case I want to to connect pox to host by using python socket. Is it
possible??
Moreover, in between POX and host there is one ovs, it still be possible
to connect??
Chanthan

[Shiyao Ma]

I am also in need of that functionality (and that need just came up in mind
last night.)
Here is my tentative thought:
To emulate a real network environment, host shouldn't directly connect to
the controller. The only way is through the edge switch (in a DCN
environment).
If we are using python socket, I think TCP is not a good choice, since
whenever a related packet-in from the switch, the controller should
maintain some state for the hand-shaking of the connection. Thus, we shall
resort to UDP, though it loses some reliability (but as a recuse,
reliability could be done in L5).

Post by Chanthan Hel
Dear all,
As usual, POX can connect and keep communication with of switch.
In case I want to to connect pox to host by using python socket. Is it
possible??
Moreover, in between POX and host there is one ovs, it still be possible
to connect??
Chanthan
--
Mr. Chanthan Hel
Electrical engineering, Faculty of Engineering,
Chulalongkorn University (CU)
*Phone: [phone]*

[Chanthan Hel]

Thx

Post by Shiyao Ma
I am also in need of that functionality (and that need just came up in
mind last night.)
To emulate a real network environment, host shouldn't directly connect to
the controller. The only way is through the edge switch (in a DCN
environment).
If we are using python socket, I think TCP is not a good choice, since
whenever a related packet-in from the switch, the controller should
maintain some state for the hand-shaking of the connection. Thus, we shall
resort to UDP, though it loses some reliability (but as a recuse,
reliability could be done in L5).
2014-04-21 11:19 GMT+08:00 Chanthan Hel <hel.chanthan65 at gmail.com<javascript:_e(%7B%7D,'cvml','hel.chanthan65 at gmail.com');>

Post by Chanthan Hel
Dear all,
As usual, POX can connect and keep communication with of switch.
In case I want to to connect pox to host by using python socket. Is it
possible??
Moreover, in between POX and host there is one ovs, it still be possible
to connect??
Chanthan
--
Mr. Chanthan Hel
Electrical engineering, Faculty of Engineering,
Chulalongkorn University (CU)
*Phone: [phone]*

--
????????????????http://introo.me?

[Chanthan Hel]

Thx

Post by Shiyao Ma
I am also in need of that functionality (and that need just came up in
mind last night.)
To emulate a real network environment, host shouldn't directly connect to
the controller. The only way is through the edge switch (in a DCN
environment).
If we are using python socket, I think TCP is not a good choice, since
whenever a related packet-in from the switch, the controller should
maintain some state for the hand-shaking of the connection. Thus, we shall
resort to UDP, though it loses some reliability (but as a recuse,
reliability could be done in L5).
2014-04-21 11:19 GMT+08:00 Chanthan Hel <hel.chanthan65 at gmail.com<javascript:_e(%7B%7D,'cvml','hel.chanthan65 at gmail.com');>

Post by Chanthan Hel
Dear all,
As usual, POX can connect and keep communication with of switch.
In case I want to to connect pox to host by using python socket. Is it
possible??
Moreover, in between POX and host there is one ovs, it still be possible
to connect??
Chanthan
--
Mr. Chanthan Hel
Electrical engineering, Faculty of Engineering,
Chulalongkorn University (CU)
*Phone: [phone]*

--
????????????????http://introo.me?

[Murphy McCauley]

Whether POX can communicate with your hosts is mostly a function of your network setup. In lots of cases, the network that POX communicates to switches on and the network that the switches control are entirely separate and never actually meet (often these are called the control network and the data network respectivelt). In this case, having POX and a host communicate directly isn't possible. Indirectly, though, there's at least one kind of hacky possibility. Sam Russell did an example of it -- tunneling between the data network and a tap interface on the controller machine over the OpenFlow connection via packet-in and packet-out. (You could also potentially use pcap via pxpcap instead of a tap.) There are issues with this approach, but it may suit some need. You can read his blog post about it here:
http://pieknywidok.blogspot.com/2012/09/tunneling-traffic-through-your-openflow.html

A more straightforward approach is to actually have the controller machine exist on the data network. This is always the case when doing "in-band control". If your switches are, for example, Open vSwitch, the most straightforward way is using the "local" interface of the OVS instance. This interface is usually down by default, but you can up it. This connects the switch machine's local networking stack (which can obviously reach the controller because this is how the switch reaches the controller!) to the data network. Obviously, you'll need to install appropriate table entries to allow communication between the controller machine (via the local port) and the host (via whatever port it's connected to).

Hope that helps.

-- Murphy

Post by Chanthan Hel
Dear all,
As usual, POX can connect and keep communication with of switch.
In case I want to to connect pox to host by using python socket. Is it possible??
Moreover, in between POX and host there is one ovs, it still be possible to connect??
Chanthan
--
Mr. Chanthan Hel
Electrical engineering, Faculty of Engineering,
Chulalongkorn University (CU)
*Phone: [phone]*

[Chanthan Hel]

Thanks so much for your suggestion .

On Monday, April 21, 2014, Murphy McCauley <murphy.mccauley at gmail.com>

Post by Murphy McCauley
Whether POX can communicate with your hosts is mostly a function of your
network setup. In lots of cases, the network that POX communicates to
switches on and the network that the switches control are entirely separate
and never actually meet (often these are called the control network and the
data network respectivelt). In this case, having POX and a host
communicate directly isn't possible. Indirectly, though, there's at least
one kind of hacky possibility. Sam Russell did an example of it --
tunneling between the data network and a tap interface on the controller
machine over the OpenFlow connection via packet-in and packet-out. (You
could also potentially use pcap via pxpcap instead of a tap.) There are
issues with this approach, but it may suit some need. You can read his
http://pieknywidok.blogspot.com/2012/09/tunneling-traffic-through-your-openflow.html
A more straightforward approach is to actually have the controller machine
exist on the data network. This is always the case when doing "in-band
control". If your switches are, for example, Open vSwitch, the most
straightforward way is using the "local" interface of the OVS instance.
This interface is usually down by default, but you can up it. This
connects the switch machine's local networking stack (which can obviously
reach the controller because this is how the switch reaches the
controller!) to the data network. Obviously, you'll need to install
appropriate table entries to allow communication between the controller
machine (via the local port) and the host (via whatever port it's connected
to).
Hope that helps.
-- Murphy
On Apr 20, 2014, at 8:19 PM, Chanthan Hel <hel.chanthan65 at gmail.com<javascript:;>>

Post by Chanthan Hel
Dear all,
As usual, POX can connect and keep communication with of switch.
In case I want to to connect pox to host by using python socket. Is it

possible??

Post by Chanthan Hel
Moreover, in between POX and host there is one ovs, it still be

possible to connect??

Post by Chanthan Hel
Chanthan
--
Mr. Chanthan Hel
Electrical engineering, Faculty of Engineering,
Chulalongkorn University (CU)
*Phone: [phone]*

[Andrew Ferguson]

Post by Murphy McCauley
A more straightforward approach is to actually have the controller machine exist on the data network. This is always the case when doing "in-band control". If your switches are, for example, Open vSwitch, the most straightforward way is using the "local" interface of the OVS instance. This interface is usually down by default, but you can up it. This connects the switch machine's local networking stack (which can obviously reach the controller because this is how the switch reaches the controller!) to the data network. Obviously, you'll need to install appropriate table entries to allow communication between the controller machine (via the local port) and the host (via whatever port it's connected to).

or you can just add a second interface to your controller, placing it on the data-plane. :-) this keeps the simplicity and isolation of out-of-band networking, while giving our controller and hosts easy communication.

I usually do this by creating a "controller host" in Mininet where I run my controller (in your case, it would be POX). however, I don't put that host in a separate namespace, which means that its loopback interface is in the same namespace as all the switches (and gets used as the "control-plane" in mininet). the regular eth-pair device gets attached to the switch ("data-plane"). see, for example: https://github.com/brownsys/pane-demo-vm/blob/master/demos/PaneDemo.py#L56

in the physical testbed, we just use two NIC cards.


Andrew

[Murphy McCauley]

Good point -- I should have mentioned the two NIC option! I skipped it because I've never found it practical/desirable myself, but it is certainly the simplest conceptually.

-- Murphy

Post by Andrew Ferguson

Post by Murphy McCauley
A more straightforward approach is to actually have the controller machine exist on the data network. This is always the case when doing "in-band control". If your switches are, for example, Open vSwitch, the most straightforward way is using the "local" interface of the OVS instance. This interface is usually down by default, but you can up it. This connects the switch machine's local networking stack (which can obviously reach the controller because this is how the switch reaches the controller!) to the data network. Obviously, you'll need to install appropriate table entries to allow communication between the controller machine (via the local port) and the host (via whatever port it's connected to).

or you can just add a second interface to your controller, placing it on the data-plane. :-) this keeps the simplicity and isolation of out-of-band networking, while giving our controller and hosts easy communication.
I usually do this by creating a "controller host" in Mininet where I run my controller (in your case, it would be POX). however, I don't put that host in a separate namespace, which means that its loopback interface is in the same namespace as all the switches (and gets used as the "control-plane" in mininet). the regular eth-pair device gets attached to the switch ("data-plane"). see, for example: https://github.com/brownsys/pane-demo-vm/blob/master/demos/PaneDemo.py#L56
in the physical testbed, we just use two NIC cards.
Andrew

[Shiyao Ma]

I should have waited till I found this reply instead of rushing through my
packet-in based ugly method. :)

I am a bit confused about how the switch/interfaces are connected
internally.

If I do a `sudo ifconfig -a`. I could see some switches (those defined in
mininet.topo) and their interfaces.
By setting `innamespace=Flalse`, I do see panebrain-eth0. But how does it
connect to the bridge(switch) defined in mininet.topo?
I'd like learn more about the underlying mechanism.

Thanks.

Post by Murphy McCauley
Good point -- I should have mentioned the two NIC option! I skipped it
because I've never found it practical/desirable myself, but it is certainly
the simplest conceptually.
-- Murphy

On Apr 21, 2014, at 3:50 PM, Murphy McCauley <murphy.mccauley at gmail.com>

Post by Murphy McCauley
A more straightforward approach is to actually have the controller

machine exist on the data network. This is always the case when doing
"in-band control". If your switches are, for example, Open vSwitch, the
most straightforward way is using the "local" interface of the OVS
instance. This interface is usually down by default, but you can up it.
This connects the switch machine's local networking stack (which can
obviously reach the controller because this is how the switch reaches the
controller!) to the data network. Obviously, you'll need to install
appropriate table entries to allow communication between the controller
machine (via the local port) and the host (via whatever port it's connected
to).

or you can just add a second interface to your controller, placing it on

the data-plane. :-) this keeps the simplicity and isolation of out-of-band
networking, while giving our controller and hosts easy communication.

I usually do this by creating a "controller host" in Mininet where I run

my controller (in your case, it would be POX). however, I don't put that
host in a separate namespace, which means that its loopback interface is in
the same namespace as all the switches (and gets used as the
"control-plane" in mininet). the regular eth-pair device gets attached to
https://github.com/brownsys/pane-demo-vm/blob/master/demos/PaneDemo.py#L56

in the physical testbed, we just use two NIC cards.
Andrew

[Shiyao Ma]

Post by Shiyao Ma

Post by Murphy McCauley

Post by Andrew Ferguson
however, I don't put that host in a separate namespace, which means that

its loopback interface is in the same namespace as all the switches (and
gets used as the "control-plane" in mininet). the regular eth-pair device
gets attached to the switch ("data-plane").

Actually the loopback interface of those switches and the panebrain and the
real machine refer to the *same* thing, right?

Post by Shiyao Ma
I should have waited till I found this reply instead of rushing through my
packet-in based ugly method. :)
I am a bit confused about how the switch/interfaces are connected
internally.
If I do a `sudo ifconfig -a`. I could see some switches (those defined in
mininet.topo) and their interfaces.
By setting `innamespace=Flalse`, I do see panebrain-eth0. But how does it
connect to the bridge(switch) defined in mininet.topo?
I'd like learn more about the underlying mechanism.
Thanks.
Good point -- I should have mentioned the two NIC option! I skipped it

Post by Murphy McCauley
because I've never found it practical/desirable myself, but it is certainly
the simplest conceptually.
-- Murphy

Post by Andrew Ferguson
On Apr 21, 2014, at 3:50 PM, Murphy McCauley <murphy.mccauley at gmail.com>

Post by Murphy McCauley
A more straightforward approach is to actually have the controller

machine exist on the data network. This is always the case when doing
"in-band control". If your switches are, for example, Open vSwitch, the
most straightforward way is using the "local" interface of the OVS
instance. This interface is usually down by default, but you can up it.
This connects the switch machine's local networking stack (which can
obviously reach the controller because this is how the switch reaches the
controller!) to the data network. Obviously, you'll need to install
appropriate table entries to allow communication between the controller
machine (via the local port) and the host (via whatever port it's connected
to).

Post by Andrew Ferguson
or you can just add a second interface to your controller, placing it

on the data-plane. :-) this keeps the simplicity and isolation of
out-of-band networking, while giving our controller and hosts easy
communication.

Post by Andrew Ferguson
I usually do this by creating a "controller host" in Mininet where I

run my controller (in your case, it would be POX). however, I don't put
that host in a separate namespace, which means that its loopback interface
is in the same namespace as all the switches (and gets used as the
"control-plane" in mininet). the regular eth-pair device gets attached to
https://github.com/brownsys/pane-demo-vm/blob/master/demos/PaneDemo.py#L56

Post by Andrew Ferguson
in the physical testbed, we just use two NIC cards.
Andrew

--
????????????????http://introo.me?

[Shiyao Ma]

Post by Shiyao Ma

Post by Murphy McCauley

Post by Andrew Ferguson
however, I don't put that host in a separate namespace, which means that

its loopback interface is in the same namespace as all the switches (and
gets used as the "control-plane" in mininet). the regular eth-pair device
gets attached to the switch ("data-plane").

Actually the loopback interface of those switches and the panebrain and the
real machine refer to the *same* thing, right?

Post by Shiyao Ma
I should have waited till I found this reply instead of rushing through my
packet-in based ugly method. :)
I am a bit confused about how the switch/interfaces are connected
internally.
If I do a `sudo ifconfig -a`. I could see some switches (those defined in
mininet.topo) and their interfaces.
By setting `innamespace=Flalse`, I do see panebrain-eth0. But how does it
connect to the bridge(switch) defined in mininet.topo?
I'd like learn more about the underlying mechanism.
Thanks.
Good point -- I should have mentioned the two NIC option! I skipped it

Post by Murphy McCauley
because I've never found it practical/desirable myself, but it is certainly
the simplest conceptually.
-- Murphy

Post by Andrew Ferguson
On Apr 21, 2014, at 3:50 PM, Murphy McCauley <murphy.mccauley at gmail.com>

Post by Murphy McCauley
A more straightforward approach is to actually have the controller

machine exist on the data network. This is always the case when doing
"in-band control". If your switches are, for example, Open vSwitch, the
most straightforward way is using the "local" interface of the OVS
instance. This interface is usually down by default, but you can up it.
This connects the switch machine's local networking stack (which can
obviously reach the controller because this is how the switch reaches the
controller!) to the data network. Obviously, you'll need to install
appropriate table entries to allow communication between the controller
machine (via the local port) and the host (via whatever port it's connected
to).

Post by Andrew Ferguson
or you can just add a second interface to your controller, placing it

on the data-plane. :-) this keeps the simplicity and isolation of
out-of-band networking, while giving our controller and hosts easy
communication.

Post by Andrew Ferguson
I usually do this by creating a "controller host" in Mininet where I

run my controller (in your case, it would be POX). however, I don't put
that host in a separate namespace, which means that its loopback interface
is in the same namespace as all the switches (and gets used as the
"control-plane" in mininet). the regular eth-pair device gets attached to
https://github.com/brownsys/pane-demo-vm/blob/master/demos/PaneDemo.py#L56

Post by Andrew Ferguson
in the physical testbed, we just use two NIC cards.
Andrew

--
????????????????http://introo.me?

[Shiyao Ma]

I should have waited till I found this reply instead of rushing through my
packet-in based ugly method. :)

I am a bit confused about how the switch/interfaces are connected
internally.

If I do a `sudo ifconfig -a`. I could see some switches (those defined in
mininet.topo) and their interfaces.
By setting `innamespace=Flalse`, I do see panebrain-eth0. But how does it
connect to the bridge(switch) defined in mininet.topo?
I'd like learn more about the underlying mechanism.

Thanks.

Post by Murphy McCauley
Good point -- I should have mentioned the two NIC option! I skipped it
because I've never found it practical/desirable myself, but it is certainly
the simplest conceptually.
-- Murphy

On Apr 21, 2014, at 3:50 PM, Murphy McCauley <murphy.mccauley at gmail.com>

Post by Murphy McCauley
A more straightforward approach is to actually have the controller

machine exist on the data network. This is always the case when doing
"in-band control". If your switches are, for example, Open vSwitch, the
most straightforward way is using the "local" interface of the OVS
instance. This interface is usually down by default, but you can up it.
This connects the switch machine's local networking stack (which can
obviously reach the controller because this is how the switch reaches the
controller!) to the data network. Obviously, you'll need to install
appropriate table entries to allow communication between the controller
machine (via the local port) and the host (via whatever port it's connected
to).

or you can just add a second interface to your controller, placing it on

the data-plane. :-) this keeps the simplicity and isolation of out-of-band
networking, while giving our controller and hosts easy communication.

I usually do this by creating a "controller host" in Mininet where I run

my controller (in your case, it would be POX). however, I don't put that
host in a separate namespace, which means that its loopback interface is in
the same namespace as all the switches (and gets used as the
"control-plane" in mininet). the regular eth-pair device gets attached to
https://github.com/brownsys/pane-demo-vm/blob/master/demos/PaneDemo.py#L56

in the physical testbed, we just use two NIC cards.
Andrew

[Murphy McCauley]

Good point -- I should have mentioned the two NIC option! I skipped it because I've never found it practical/desirable myself, but it is certainly the simplest conceptually.

-- Murphy

Post by Andrew Ferguson

Post by Murphy McCauley
A more straightforward approach is to actually have the controller machine exist on the data network. This is always the case when doing "in-band control". If your switches are, for example, Open vSwitch, the most straightforward way is using the "local" interface of the OVS instance. This interface is usually down by default, but you can up it. This connects the switch machine's local networking stack (which can obviously reach the controller because this is how the switch reaches the controller!) to the data network. Obviously, you'll need to install appropriate table entries to allow communication between the controller machine (via the local port) and the host (via whatever port it's connected to).

or you can just add a second interface to your controller, placing it on the data-plane. :-) this keeps the simplicity and isolation of out-of-band networking, while giving our controller and hosts easy communication.
I usually do this by creating a "controller host" in Mininet where I run my controller (in your case, it would be POX). however, I don't put that host in a separate namespace, which means that its loopback interface is in the same namespace as all the switches (and gets used as the "control-plane" in mininet). the regular eth-pair device gets attached to the switch ("data-plane"). see, for example: https://github.com/brownsys/pane-demo-vm/blob/master/demos/PaneDemo.py#L56
in the physical testbed, we just use two NIC cards.
Andrew

[Chanthan Hel]

Thanks so much for your suggestion .

On Monday, April 21, 2014, Murphy McCauley <murphy.mccauley at gmail.com>

Post by Murphy McCauley
Whether POX can communicate with your hosts is mostly a function of your
network setup. In lots of cases, the network that POX communicates to
switches on and the network that the switches control are entirely separate
and never actually meet (often these are called the control network and the
data network respectivelt). In this case, having POX and a host
communicate directly isn't possible. Indirectly, though, there's at least
one kind of hacky possibility. Sam Russell did an example of it --
tunneling between the data network and a tap interface on the controller
machine over the OpenFlow connection via packet-in and packet-out. (You
could also potentially use pcap via pxpcap instead of a tap.) There are
issues with this approach, but it may suit some need. You can read his
http://pieknywidok.blogspot.com/2012/09/tunneling-traffic-through-your-openflow.html
A more straightforward approach is to actually have the controller machine
exist on the data network. This is always the case when doing "in-band
control". If your switches are, for example, Open vSwitch, the most
straightforward way is using the "local" interface of the OVS instance.
This interface is usually down by default, but you can up it. This
connects the switch machine's local networking stack (which can obviously
reach the controller because this is how the switch reaches the
controller!) to the data network. Obviously, you'll need to install
appropriate table entries to allow communication between the controller
machine (via the local port) and the host (via whatever port it's connected
to).
Hope that helps.
-- Murphy
On Apr 20, 2014, at 8:19 PM, Chanthan Hel <hel.chanthan65 at gmail.com<javascript:;>>

Post by Chanthan Hel
Dear all,
As usual, POX can connect and keep communication with of switch.
In case I want to to connect pox to host by using python socket. Is it

possible??

Post by Chanthan Hel
Moreover, in between POX and host there is one ovs, it still be

possible to connect??

Post by Chanthan Hel
Chanthan
--
Mr. Chanthan Hel
Electrical engineering, Faculty of Engineering,
Chulalongkorn University (CU)
*Phone: [phone]*

[Andrew Ferguson]

Post by Murphy McCauley
A more straightforward approach is to actually have the controller machine exist on the data network. This is always the case when doing "in-band control". If your switches are, for example, Open vSwitch, the most straightforward way is using the "local" interface of the OVS instance. This interface is usually down by default, but you can up it. This connects the switch machine's local networking stack (which can obviously reach the controller because this is how the switch reaches the controller!) to the data network. Obviously, you'll need to install appropriate table entries to allow communication between the controller machine (via the local port) and the host (via whatever port it's connected to).

or you can just add a second interface to your controller, placing it on the data-plane. :-) this keeps the simplicity and isolation of out-of-band networking, while giving our controller and hosts easy communication.

I usually do this by creating a "controller host" in Mininet where I run my controller (in your case, it would be POX). however, I don't put that host in a separate namespace, which means that its loopback interface is in the same namespace as all the switches (and gets used as the "control-plane" in mininet). the regular eth-pair device gets attached to the switch ("data-plane"). see, for example: https://github.com/brownsys/pane-demo-vm/blob/master/demos/PaneDemo.py#L56

in the physical testbed, we just use two NIC cards.


Andrew

[Chanthan Hel]

Dear all,
As usual, POX can connect and keep communication with of switch.
In case I want to to connect pox to host by using python socket. Is it
possible??
Moreover, in between POX and host there is one ovs, it still be possible
to connect??
Chanthan

[Shiyao Ma]

I am also in need of that functionality (and that need just came up in mind
last night.)
Here is my tentative thought:
To emulate a real network environment, host shouldn't directly connect to
the controller. The only way is through the edge switch (in a DCN
environment).
If we are using python socket, I think TCP is not a good choice, since
whenever a related packet-in from the switch, the controller should
maintain some state for the hand-shaking of the connection. Thus, we shall
resort to UDP, though it loses some reliability (but as a recuse,
reliability could be done in L5).

Post by Chanthan Hel
Dear all,
As usual, POX can connect and keep communication with of switch.
In case I want to to connect pox to host by using python socket. Is it
possible??
Moreover, in between POX and host there is one ovs, it still be possible
to connect??
Chanthan
--
Mr. Chanthan Hel
Electrical engineering, Faculty of Engineering,
Chulalongkorn University (CU)
*Phone: [phone]*

[Murphy McCauley]

Whether POX can communicate with your hosts is mostly a function of your network setup. In lots of cases, the network that POX communicates to switches on and the network that the switches control are entirely separate and never actually meet (often these are called the control network and the data network respectivelt). In this case, having POX and a host communicate directly isn't possible. Indirectly, though, there's at least one kind of hacky possibility. Sam Russell did an example of it -- tunneling between the data network and a tap interface on the controller machine over the OpenFlow connection via packet-in and packet-out. (You could also potentially use pcap via pxpcap instead of a tap.) There are issues with this approach, but it may suit some need. You can read his blog post about it here:
http://pieknywidok.blogspot.com/2012/09/tunneling-traffic-through-your-openflow.html

A more straightforward approach is to actually have the controller machine exist on the data network. This is always the case when doing "in-band control". If your switches are, for example, Open vSwitch, the most straightforward way is using the "local" interface of the OVS instance. This interface is usually down by default, but you can up it. This connects the switch machine's local networking stack (which can obviously reach the controller because this is how the switch reaches the controller!) to the data network. Obviously, you'll need to install appropriate table entries to allow communication between the controller machine (via the local port) and the host (via whatever port it's connected to).

Hope that helps.

-- Murphy

Post by Chanthan Hel
Dear all,
As usual, POX can connect and keep communication with of switch.
In case I want to to connect pox to host by using python socket. Is it possible??
Moreover, in between POX and host there is one ovs, it still be possible to connect??
Chanthan
--
Mr. Chanthan Hel
Electrical engineering, Faculty of Engineering,
Chulalongkorn University (CU)
*Phone: [phone]*