seed-labs / seed-emulator Goto Github PK

This is a feature for future implementation

To emulate the network more realistically, we may want to set the bandwidth on network links, especially the BGP router's link to the Internet exchange. We can use the tc command to add delay to those links. This could be an interesting feature to implement in the future (we probably don't need it now).

Not sure whether bandwidth is a criterion when BGP conducts path selection. If so, this could definitely make the emulation more interesting.

Hello,
I want to establish my own network and the number of my AS is more than 253, it occurs error:AssertionError: can't map ASN 255 to IX address. Is there any methods that I can expand the ASN number limitation?
Thanks!

Priority: LOW (I am adding it here now, otherwise I would forget about it).

We can add new APIs to WebService to allow users to add websites to the service. Basically the APIs will add a virtual host file to the web server's configuration folder, and run command to enable the website.

We should have one API for HTTP, another one for HTTPS sites. For HTTPS sites, users will need to provide the server's private key and certificate, or let the container generate the certificate automatically (we do need to provide a root CA as the argument, so all the certificates can be generated from this root CA, which is created by ourselves). I have all the script in the PKI and TLS labs. When we implement these APIs, I will provide all the certificate scripts to save time.

With these new APIs, the current PKI and TLS labs can use this emulator as the basis. The activities can become more interesting.

In the TOR install script, it appears that TOR_VER is referenced but never set.

This does not cause an error as far as I can tell, but it seems like it may have unintended consequences that the Tor version used is not pinned.

If this is intended behavior, please feel free to just close this issue.

As seed-emulator grows, I thought it might be useful to suggest a few PRs for general code improvement and maintenance. I may work slow, but if the seed devs agree that these are good ideas, I am happy to work on these PRs as time allows.

Use standard libraries for logging and inheritance (PR 1)

• Remove use of individually created logging functions in favor of using the logging library
  • Using the logging library will reduce the number of logging functions, which should reduce lines of code in seed-emulator
  • Using a centralized to configure logging for the entire library just once will make it easier to log to a file or stdout. Right now, if you wanted to do that, you'd have to manually change stderr to something else in every individual logging function.
• Use abc python library for inheritance
  • Currently, for methods that subclasses should implement, seed uses NotImplementedErrors. When an unimplemented method is called, the error will be thrown. Instead, using the abc @abstractmethod decorator on abstract function, an error about missing implementations will be thrown as soon as a subclass is instantiated. This will avoid subtle bugs that are currently uncaught, like the Filter class being marked as printable but not actually implementing the print function

    seed-emulator/seedemu/core/Binding.py

    Line 31 in 3749042

    class Filter(Printable):

Use static tools to standardize code formatting and catch type errors (PR 2)

• Add code style linter as GitHub action, with instruction in README for running manually during development
  • There are many options for linters, but I was thinking Black might be a good option
• Add python static type checking as GitHub action, with instruction in README for running manually during development
  • There are probably other tools but I was thinking mypy might be a good option.

Automated Testing & Additional Tests (PR 3)

• Add existing SEED example-based tests as GitHub action
  • I believe these more fall under Integration Tests than Unit Tests, although I think it’s perfectly acceptable to use the unit test library to implement them
  • I haven't thought too much about what additional testing might look like, so I'll leave this open.
• Add unit tests to various classes & add as GitHub action

Document Generation and Hosting (PR 4)

• Create a github action that checks for documentation errors when building with doxygen
• It should be possible to serve the doxygen docs using github pages, with updates automatically on merging PRs into main

When I was developing the Morris Worm lab, I used the emulator to create the emulated Internet, and then release the worm inside the emulator. Based on the experience, the following APIs should be quite useful:

• Docker::createImageFromFolder(imagename, path, baseonly=true/false, softwarelist): Using this API, I can put all the necessary files of an image inside a folder, and then include it in the emulator. What the compiler will do is to simply copy this folder to the output folder, as well as adding it to the docker-compose.yml file. We can specify whether this image is just for base only (let it exit) or not (don't exit). The softwarelist specifies all the software that has already been installed inside the image. This list can help optimization. This image is immutable (the API creates a DockerImage object, but we cannot make any change to this image).

• Docker::createImage(imagename, baseonly): Using this API, we can create an empty image (DockerImage object), and then using the APIs of DockerImage to add content to the image. This allows us to create a docker image programmatically.

• DockerImage APIs: We can have setBase, setShell, appendRunCommand, setCMDentry, installSoftware. These names are just tentative; we should come up with better names.

• Docker::setBaseImageForNodes(nodename, imagename): set the base images for nodes using the name. The name can be a regular expression to match multiple nodes. There should be a default base image for every node (the one used the current implementation should be set as the default).

• Docker:setBaseImageForClass(classname, imagename): set the base images for all the nodes belonging to certain class. We need to add an API Node::setClass(classname) to associate a node with a classname. Introducing the class makes it easier for us to manage nodes. A node can be associated with multiple classes (we may want to have a Node::setPrimaryClass(classname) to set the primary class, because some APIs can only be conducted on one class). Currently, we are using the name convention for that purpose. We can create a few built-in classes, including host, router, internet-exchange, etc. Users can define their own classes.

• Default base image: A few customized base images should be created inside the Docker constructor, using the APIs defined for Docker and DockerImage. These images are the default base for the built-in classes. They can be the same. In the current implementation, the default base image for all nodes is an image called dummies, which has only one line (FROM). We should move the construction of this base into the constructor, and make it more generic, such as adding the software list to this container.

• Note on optimization: each node has a list of software that needs to be installed. When generating the Dockerfile, we need to remove the items that are already included in the base image (each base image has a software list, could be empty). If the node's list becomes empty, i.e., everything is covered by the base, there is no need to include RUN apt-get.

It should be noted that Docker should be just another layer, so the reference across layers should be strictly using names, not the object reference. This layer is only used by the compiler.

It will be better if we can put a capacity limit on hosts (or routers), so the container's usages of the CPU, RAM, or other resources are limited. This is useful for demonstrating denial-of-service attacks. Not sure how to do this in docker, but it should be doable. This could be a set of APIs at the node level (one API for setting each type of resources).

SCION (Scalability, Control, and Isolation On Next-generation networks) is a new secure and reliable inter-domain routing protocol. SCION offers inter-domain path control with explicit trust by grouping ASes in Isolation Domains (ISDs) and embedding the cryptographically secured AS-level path into packet headers.

We at NetSys Lab (Otto-von-Guericke University) are working on implementing support for SCION in the SEED emulator to run experiments comparing SCION and BGP routing in realistic Internet topologies. Currently we are developing a SCION layer similar to the existing eBGP layer here.

Since we would like to contribute our work back to the SEED emulator, we want to make sure to keep you informed on our work and keep it in line with the emulator's overall design.

Currently, the SCION layer API is designed to be used for example in a hybrid BGP and SCION network like this:

from seedemu.core import Emulator
from seedemu.layers import Base, Ebgp, Routing, Scion, PeerRelationship
from seedemu.layers.Scion import LinkType as ScLinkType

# Initialize
emu = Emulator()
base = Base()
routing = Routing()
ebgp = Ebgp()
scion = Scion()

# SCION ISDs
scion.addIsd(1)

# Internet Exchange
base.createInternetExchange(100)

# AS-150
as150 = base.createAutonomousSystem(150)
as150.createNetwork('net0')
as150_router = as150.createRouter('br0')
as150_router.joinNetwork('net0').joinNetwork('ix100')
as150_router.crossConnect(153, 'br0', '10.50.0.2/29')
scion.setAsIsd(150, 1)
scion.setCoreAs(150, True)

# AS-151
as151 = base.createAutonomousSystem(151)
as151.createNetwork('net0')
as151.createRouter('br0').joinNetwork('net0').joinNetwork('ix100')
scion.setAsIsd(151, 1)
scion.setCoreAs(151, True)

# AS-152
as152 = base.createAutonomousSystem(152)
as152.createNetwork('net0')
as152.createRouter('br0').joinNetwork('net0').joinNetwork('ix100')
scion.setAsIsd(152, 1)
scion.setCoreAs(152, True)

# AS-153
as153 = base.createAutonomousSystem(153)
as153.createNetwork('net0')
as153_router = as153.createRouter('br0')
as153_router.joinNetwork('net0')
as153_router.crossConnect(150, 'br0', '10.50.0.3/29')
scion.setAsIsd(153, 1)
scion.setCertIssuer(153, 150)

# BGP Peering
ebgp.addPrivatePeering(100, 150, 151)
ebgp.addPrivatePeering(100, 151, 152)
ebgp.addPrivatePeering(100, 152, 150)
ebgp.addCrossConnectPeering(150, 153, PeerRelationship.Provider)

# SCION Peering
scion.addIxLink(100, 150, 151, ScLinkType.Core)
scion.addIxLink(100, 151, 152, ScLinkType.Core)
scion.addIxLink(100, 152, 150, ScLinkType.Core)
scion.addXcLink(150, 153, ScLinkType.Transit)

We can provide more examples once we have made more progress, but if you have any feedback already please let us know.

Please add a toggle button to the client program so we can hide the log window. I would like have more space to display the network diagram.

Traceback (most recent call last):
File "mini-internet.py", line 4, in
from seedemu.layers import Base, Routing, Ebgp, Ibgp, Ospf, PeerRelationship, Dnssec
File "/home//seed-emulator/seedemu/init.py", line 2, in
from .layers import *
File "/home//seed-emulator/seedemu/layers/init.py", line 6, in
from .Dnssec import Dnssec
File "/home//seed-emulator/seedemu/layers/Dnssec.py", line 4, in
from seedemu.services import DomainNameServer, DomainNameService
File "/home//seed-emulator/seedemu/services/init.py", line 11, in
from .EthereumService import *
File "/home//seed-emulator/seedemu/services/EthereumService/init.py", line 8, in
from .EthUtil import Genesis, AccountStructure, SmartContract, EthAccount
File "/home//seed-emulator/seedemu/services/EthereumService/EthUtil.py", line 8, in
from web3 import Web3
ModuleNotFoundError: No module named 'web3'

Hello,

As part of a Project I am working on with ETH Zurich I am working on some parts of the seed-emulator.

In the project we are interested in the possibility to change link properties such as bandwidth, latency, loss and jitter dynamically while the docker containers are running. We thought about the possibility to add this functionality to the map view of the seedemu-client.

In this issue I wanted to ask whether this is something that you would be interest in adding to map view upstream. Or whether this does not align with what you have in mind with the map view.

The link property controls could be added to the Details pane in the map view.

This functionality could be achieved through executing tc commands in the router containers from the seedemu-client container

The map feature currently offers only quick actions to:

• enable/disable BGP peers
• disconnecting nodes from networks.

The logic of those quick actions are currently implemented by the docker compiler and the client program. Meaning to add new quick actions, one will have to update the client program and the compiler. As most users will probably use the map feature of the seedemu-client to interact with the emulation, we should consider providing an API (probably on the Node class?) to add quick actions to nodes. Layers, services, or emulation developers can then add the quick actions they want directly.

Possible use cases:

• One may be interested in using the emulator for smart contact, but they may not have knowledge on how to operator BGP/OSPF (i.e., work with the BIRD CLI or vtysh), etc. They however may be interested to see how disconnecting major ISPs from networks affect the blockchain. Quick actions will allow them to do that without knowing how to operate the CLI.
• Some services, like botnet and eth, require user interaction after the emulation is started. Providing quick actions allows them to interact without having prior knowledge on how to operate the software (control server and geth in this case).

Problem:
If you are developing software on a modern OS host i.e. ubuntu22/23 you cannot easily deploy it in the simulator (it wont run there because of the outdated libc version)
I find it very tiresome to always have a separate build-container based on ubuntu:20.04 from which i then COPY the binaries into the simulation-node container.

So please update the base-images or provide a choice of base-image (as i see it handsonsecurity/seedemu-multiarch-base is hardcoded now )

https://hub.docker.com/layers/handsonsecurity/seedemu-multiarch-base/buildx-latest/images/sha256-fccea4318ba13775bae754f729b1e66a582361184314808a25d38db43395f382?context=explore

Update:

the Docker compiler class allows to set per node overrides of base images with 'setImageOverride( node:Node, imagename: str)' or 'forceImage(imagename: str)' for all nodes to set a custom image

I'm running ping and set the filter to 'icmp', this does not show any animation like in this demo: https://www.youtube.com/watch?v=lfbO-eHt6qg&t=641s

I am also not sure that the logs are working correctly:

I am on (ARM) Macbook M1 running the 'A00-simple-peering' example.

When running A03-real-world (and other example with WebService), stuck on RUN apt-get update && apt-get install -y --no-install-recommends nginx-light and never exit:

 => => # Unpacking nginx-light (1.18.0-0ubuntu1.4) ...                                                                                                                            
 => => # Setting up nginx-common (1.18.0-0ubuntu1.4) ...                                                                                                                          
 => => # Setting up libnginx-mod-http-echo (1.18.0-0ubuntu1.4) ...                                                                                                                
 => => # Setting up nginx-light (1.18.0-0ubuntu1.4) ...                                                                                                                           
 => => # invoke-rc.d: could not determine current runlevel                                                                                                                        
 => => # invoke-rc.d: policy-rc.d denied execution of start.  

Examples such as A00-simple-peering fail on aarch64 machines, with misleading errors claiming missing Docker credentials. This is due to missing aarch64 variants for the hosted images handsonsecurity/seedemu-base and handsonsecurity/seedemu-router. I was able to get it running by locally building and tagging images from the docker_images folder beforehand (e.g. docker build -t handsonsecurity/seedemu-base .). I think it would be great if you could provide aarch64 images as well and/or include a notice on building images in README.md. Thanks.

The current export policies are as follow: there are two types of routes:

• Type A: routes received from a session with a Peer relationship, routes received from a session with a Provider relationship by the b side of the abRelationship (i.e., the customer), and the routes received from a session with Unfiltered relationship.
• Type B: routes received from a session with a Provider relationship by the a side of the abRelationship (i.e., the provider), and routes originated by the AS itself.

And the export behavior are as follow:

• Provider relationship:
  • a side: both types of routes by export all: export all;
  • b side: only type B routes: static export filter generated during the render stage that looks like this: export where routes ~ [10.x.x.x/24, 10.x.x.x/24, ...].
• Peer relationship:
  • both a and b side: only type B routes: static export filter generated during the render stage that looks like this: export where routes ~ [10.x.x.x/24, 10.x.x.x/24, ...].
• Unfiltered relationship:
  • both a and b side: both types of routes by export all: export all;

The export policy, unless it is export all;, are generated by the EBGP layer at the render stage. This means to add new announcements after the emulator started, one will have to manually update the export filters to ensure the propagation works properly.

Some potential issues are:

• Say AS10 is a tier-2 ISP that depends on another ISP, AS2, to propagate the routes globally. In this case, for the customer of AS10, say AS150, to add new announcements, they will have to update export filters on both AS150 and AS10.
• Say we got two tier-1 ISPs, AS2 and AS3, that do not rely on another ISP to propagate the routes globally. In this case, while the customer of AS3 only needs to change its own filter to have the route available globally via AS3's backbone, the routes won't be sent to AS2, since AS2 and AS3 will have the Peer relationship. This means users single-homed with AS2 won't be able to reach the new prefix announced by AS3 customer, meaning AS3's export filter still needs to be manually changed for the route to propagate properly.

One approach to solve this is to use multiple routing tables in BIRD. We can use separate routing tables for the different types of peers, then import/export routes from/to the corresponding table according to session type. With this approach, we do not need to explicitly generate the export prefix list during rendering and will allow adding new announcements without any filter changes after the emulation started.

This should not affect any API. The only thing changed will be the generated BIRD configuration.

collaborate with Erika Hunhoff

@lschulz ,
Is there a specific python version requirement in SCION?

When I run the ./test/run-tests.py with python3.8.10, it returns errors like below. But it runs well with python3.11.5.

python3 run-tests.py 
Traceback (most recent call last):
  File "run-tests.py", line 5, in <module>
    from scion import ScionBgpMixedTestCase, ScionBwtesterTestCase
  File "/home/won/seed-emulator/test/scion/__init__.py", line 1, in <module>
    from .ScionTestCase import ScionTestCase
  File "/home/won/seed-emulator/test/scion/ScionTestCase.py", line 7, in <module>
    class ScionTestCase(SeedEmuTestCase):
  File "/home/won/seed-emulator/test/scion/ScionTestCase.py", line 37, in ScionTestCase
    ) -> bool | Tuple[bool, List]:
TypeError: unsupported operand type(s) for |: 'type' and '_GenericAlias'

Our current service layer design can only generate one type of server. There is a service that might need multiple types of server to install. Some of them requires mandatory server. (i.e. ChainLinkService)

@kevin-w-du
realistic network simulations require a realistic topology, so most simulators allow to read it from file.
There are various formats output by different topology generators i.e. :

• BRITE
• INET
• CAIDA
• ORBIS

Here is an attempt to support this with SEED as well.

I had this exact same issue as described here ethereum/web3.py#2704

The following comment solved it for me:
ethereum/web3.py#2704 (comment)

This might help other people that are using Python 3.11 and running into this issue.

$ ./blockchain.py
Traceback (most recent call last):
File "./blockchain.py", line 55, in
e1 = blockchain1.createNode("pow-eth1")
File "/home/ht2/seed-emulator-master/seedemu/services/EthereumService/EthereumService.py", line 285, in createNode
return eth.installByBlockchain(vnode, self)
File "/home/ht2/seed-emulator-master/seedemu/services/EthereumService/EthereumService.py", line 519, in installByBlockchain
if vnode in self._pending_targets.keys(): return self._pending_targets[vnode]
AttributeError: 'EthereumService' object has no attribute '_pending_targets'

Do I need to modify 'EthereumService.py'?

For each node, such as Internet Exchange, Network, host, etc. please add a new attribute to these classes, called displayName. This name will only be used in the visualization. Their internal name such as ix100 should not change. When we display a node, if a node's displayName is not empty, we will use this name to display. If it is empty, we will use the node's internal name. This way, we can give each node a meaningful name. For example, we can call an Internet Exchange "Manhattan" to represent the real "Manhattan internet exchange" in the real world.

Originally posted by @kevin-w-du in #24 (comment)

Sometimes, we need to conduct a series of operations on an object. If these operations always return the same node object, we can chain these operations together. This style has been widely used, so I hope to use it as well. See the following example without using the chaining style:

    router = user_as.createRouter('router0')
    router.joinNetwork('net0')
    router.joinNetwork('net1')

The code above can be changed to the following:

   user_as.createRouter('router0').joinNetwork('net0').joinNetwork('net1')

Several DNS-related APIs should return self to allow API chaining. For example, addZone(), setMaster(), addRecord(), etc. Typically, these set-APIs do not return anything. If we let them return self, we can do the following:

xyz.addRecord().addRecord().addRecord()
abc.addZone().setMaster()

When I choose to build the example B00-mini-internet the following command is Ok:

python3 examples/B00-mini-internet/mini-internet.py

A change to client dir and run dcbuild. I got this error:

Step 6/13 : RUN npm install
---> Running in a7256a4a8cb0

npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!
npm WARN [email protected] No repository field.

npm ERR! code EAI_AGAIN
npm ERR! errno EAI_AGAIN
npm ERR! request to https://registry.npmjs.org/acorn/-/acorn-8.0.4.tgz failed, reason: getaddrinfo EAI_AGAIN registry.npmjs.org

$ cat package-lock.json
{
"name": "container-manager-client",
"version": "0.0.1",
"lockfileVersion": 2,
"requires": true,
"packages": {

How can I solve this issue?

A special network, 000_svc will be created by the emulator if an emulation uses services that require real-world network interactions, like routing traffic to real-world or remote network access. This network will appear on the client topology map, which can be confusing. Consider hiding this network from the users unless specified.

We also should create a new tab for client-side settings on the map page. Hiding/showing special service networks like this can be an option. If we were to implement #24, we would also need this options panel to toggle the layers.

When I create a DNS node, but without adding a zone to it, there is a problem: the named server fails to start, because it tries to load the named.conf.zones file, but it does not exist. You can easily solve this problem by creating an empty names.conf.zones file if no zone is added to this DNS node.

I create such an empty node for the purpose of labs, because I want students to add zones to the nameservers.

While working on the SCION layer I noticed that the Docker compiler adds an
extra newline to file contents set with Node.setFile().

The problem is in

I would suggest changing the line to
print(content, end='', file=open(staged_path, 'w'))
to avoid the newline.

Once I am inside a container, I would like to set a customized terminal title. Currently, zsh sets the one using root@<id>, which is not that useful. I had to run "NOPRECMD=1 zsh" to get a new shell, and then type set_title XYZ to change the title. Can we add NOPRECMD=1 to the /root/.bashrc when we start zsh, so we don't need to run this command. I am not sure whether this could cause any issue though.

Priority = LOW

An API to add a list of peers to the Rs will be useful, such as the following

ebgp.addRsPeers(100, [2, 3, 4, 151])

We need to think about how to set the peering relationship when we use this type of peering. When we use the private peering API to peer two ASes, we can set the peering relationship, but when we use this public peering API to peer more than 2 ASes, setting the peering relationship is not easy. Using the "Unfiltered" as the default is not good, because sometimes we have multi-homed stub AS that does not want to become a transit.

I am thinking about adding an attribute to each autonomous system to specify whether it is a "Stub" AS or a "transit" AS. When we peer two ASes, we will use their attributes to decide the peering relationship, unless the relationship is specified in the API.

I am not sure whether this is the best solution. We may need to discuss this before making a design decision.

Hello，when I am compose docker, it stuck at the step6 npm install for a long time and has error, how to solve this problem?

npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!

I am thinking about creating one or several base docker images for the emulator. Each container in the emulator will be built from one of the base images. It can also install additional software on top of the base. We will use this issue to discuss what should be included in the base images, how many should we build, how to name these images, etc. Here are some of the criteria for the design decision:

• The size of each image should be kept to minimum. This means if a software package is large but not commonly used by containers, it should not get into the base image.
• The number of images should not be many, and the way how they are built should consider maximizing the use of cache.

We will create a folder in the root folder to store the source files of these images. I will build the image and then upload it to the Docker Hub (using handsonsecurity account).

Priority: LOW

In many cases, we will deploy an overlay network on top of the emulator (such as DNS infrastructure, Botnet, Darknet, Blockchain). I hope to have an option to only display this overlay network. Here are my thoughts (I am using DNS as an example):

• Initially, everything will be displayed (just like what the current client program does).
• When we click the DNS button, we will change the colors of the nodes in the diagram (the topology of the diagram will not change, the shapes will stay the same, only the color of each node will change).
• We will use one color for each type of the DNS nodes (root, TLD, and domain servers).
• Nodes that do not belong to the DNS infrastructure will be grayed out.

The question is how the client program know which node is DNS node, of what type. Do we need to provide some visualization-related information when building the emulator, so we can help the client program?

It will be great if we can provide the APIs in each class to allow users to enumerate its direct internal elements. I do see some classes already have such APIs, but not all. These APIs will be very helpful for others to build on top of an existing base-layer component.

• For IX: provide getASes()
• For AS: provide getNetworks(): this one already exists. I do see several other useful get APIs in this class.
• For AS: provide getPeers(): get the peering relationship and the location (IX) of the peering.
• For Network: provide getHosts() and getRouters()
• For Router: provide getNetworks(): get the list of the networks it is attached to
• for Hosts: provide getServices(): not sure whether this is doable after the binding. If not, it is better to leave it out.

The issue will be used to track documentation progress.

Developer Guides

• Creating a new layer
  • Integrating with other layers
• Creating a new service
• Creating a new component
• Creating a new remote access provider

Design Documentation

• Core classes
• Layers
• Services
• Components
• Merging
• Remote Access Provider
• Render & Compilation

SEED Emulator Client

• Using the map

Ubuntu 22.04.3 LTS

# cd client/
# docker-compose build && docker-compose up
Building seedemu-client
[+] Building 5.3s (17/17) FINISHED                                                                                                                                                                                                                                                                                          docker:default
 => [internal] load build definition from Dockerfile                                                                                                                                                                                                                                                                                  0.0s
 => => transferring dockerfile: 372B                                                                                                                                                                                                                                                                                                  0.0s
 => [internal] load metadata for docker.io/library/node:14                                                                                                                                                                                                                                                                            5.2s
 => [internal] load .dockerignore                                                                                                                                                                                                                                                                                                     0.0s
 => => transferring context: 2B                                                                                                                                                                                                                                                                                                       0.0s
 => [internal] load build context                                                                                                                                                                                                                                                                                                     0.0s
 => => transferring context: 2.51kB                                                                                                                                                                                                                                                                                                   0.0s
 => [ 1/12] FROM docker.io/library/node:14@sha256:a158d3b9b4e3fa813fa6c8c590b8f0a860e015ad4e59bbce5744d2f6fd8461aa                                                                                                                                                                                                                    0.0s
 => CACHED [ 2/12] COPY start.sh /                                                                                                                                                                                                                                                                                                    0.0s
 => CACHED [ 3/12] WORKDIR /usr/src/app                                                                                                                                                                                                                                                                                               0.0s
 => CACHED [ 4/12] COPY . .                                                                                                                                                                                                                                                                                                           0.0s
 => CACHED [ 5/12] WORKDIR /usr/src/app/frontend                                                                                                                                                                                                                                                                                      0.0s
 => CACHED [ 6/12] RUN npm install                                                                                                                                                                                                                                                                                                    0.0s
 => CACHED [ 7/12] RUN npm install -D webpack-cli                                                                                                                                                                                                                                                                                     0.0s
 => CACHED [ 8/12] RUN ./node_modules/.bin/webpack --mode production                                                                                                                                                                                                                                                                  0.0s
 => CACHED [ 9/12] WORKDIR /usr/src/app/backend                                                                                                                                                                                                                                                                                       0.0s
 => CACHED [10/12] RUN npm install                                                                                                                                                                                                                                                                                                    0.0s
 => CACHED [11/12] RUN npm install -D typescript                                                                                                                                                                                                                                                                                      0.0s
 => CACHED [12/12] RUN ./node_modules/.bin/tsc                                                                                                                                                                                                                                                                                        0.0s
 => exporting to image                                                                                                                                                                                                                                                                                                                0.0s
 => => exporting layers                                                                                                                                                                                                                                                                                                               0.0s
 => => writing image sha256:64cfdfefcf1b7a1614c872231d2c1db92691749569a59861ee8970a6d74a1103                                                                                                                                                                                                                                          0.0s
 => => naming to docker.io/library/client_seedemu-client                                                                                                                                                                                                                                                                              0.0s
Starting seedemu_client ... done
Attaching to seedemu_client
seedemu_client    | /start.sh: 2: cd: can't cd to /usr/src/app/backend
seedemu_client    | /start.sh: 4: /start.sh: Syntax error: end of file unexpected (expecting "done")
seedemu_client exited with code 2

These are the suggestions originally put inside the example-22. I am moving them to here so we don't lose them.

• (Priority: Low): During the binding, use Action.NEW to bind a virtual node to a new physical node, i.e., the node needs to be created.

• (Priority: Low): The way to set the local DNS server is not clear. I hope to be able to do the
  following: the localDNS argument could be an IP address (physical node) or a virtual node name, the overwrite option
  indicates whether to overwrite the existing setting if a node already has set the local DNS:

  • emu.setLocalDNS(localDNS, overwrite=true/false): set the local DNS for the entire emulation. This will be a wrapper of
    the addHook API (we will keep addHook public because it could be quite useful for other scenarios).
  • as.setLocalDNS(): for the entire autonomous system
  • network.setLocalDNS(): for the entire network
  • node.setLocalDNS(): for a node

To save the container image building time, we should think about how to allow the emulator to use pre-built images. This requires some sort of image management systems built into the emulator. Here are some thoughts:

• We will prebuilt some base images and put them on Docker Hub.
• For each container image, we build a class, so we can put the container information in this class, including its base, the packages that are already installed (and their versions). We can also specify potential conflicts if we know any (to prevent newly installed software from causing conflict to the image).
• After a node chooses a container image, it can query the class to figure out whether the software it needs is already installed or not. If not, whether there is any conflict to install the software.

This issue is not essential, so we will take time to think about the design, and implement it when we have time.

I am trying to use Node.setFile() API to copy an executable file to container, but it seems this API can only handle strings, because the file copied into the container is different from the original file. We should support the binary option as well.

When we visualize the packet flow, sometimes things happen too fast, and it is very difficult to see the actual flow. I am thinking about the following recording features:

• A button to start/stop the recording
• When the recording starts, the map will record the list of the nodes that are highlighted (in order), until the stop is pressed
• A button to replay the recorded list. When this button is pressed, the nodes on the recorded list will be highlighted again (in order), but the progress will be delayed a little bit, so we can easily see the progression.

This does not seem to be difficult to implement, what do you think?

Hello! I was working with seedemu and I recently realized that the install commands for BgpLookingGlassService appear to be broken.

It is not used in any of the supported examples so this is probably how it was not noticed before now.

When you try to create an image with this service, the commands below are used to install looking glass:

git clone https://github.com/xddxdd/bird-lg-go /lg
make -C /lg

The make command fails with the following error:

build github.com/xddxdd/bird-lg-go/frontend: cannot load embed: malformed module path "embed": missing dot in first path element

This is not causing me troubles at the moment, but I thought the issue should be clearly documented. I am not actively working to solve this issue.

I would like to help. I'll look at the open issues in SEED labs/simulator and see if I can contribute.

= Emulator: configureing EthereumService...
==== EthereumServiceLayer: eth_state folder "./eth-states" already exist, overriding.
==== EthereumServiceLayer: looking for binding for eth1...
==== EthereumServiceLayer: configuring as151/host_1 as an eth node...
==== EthereumServiceLayer: adding as151/host_1 as consensus-POW bootnode...
==== EthereumServiceLayer: creating eth account...
Traceback (most recent call last):
File "blockchain.py", line 28, in
emu.render()
File "seed-emulator/seedemu/core/Emulator.py", line 363, in render
self.__render(layerName, False, True)
File "seed-emulator/seedemu/core/Emulator.py", line 152, in __render
layer.configure(self)
File "seed-emulator/seedemu/services/EthereumService.py", line 956, in configure
super().configure(emulator)
File "seed-emulator/seedemu/core/Service.py", line 122, in configure
self.__configureServer(server, pnode)
File "seed-emulator/seedemu/core/Service.py", line 92, in __configureServer
self._doConfigure(node, server)
File "seed-emulator/seedemu/services/EthereumService.py", line 940, in _doConfigure
server._createAccounts(self)
File "seed-emulator/seedemu/services/EthereumService.py", line 796, in _createAccounts
account = EthAccount(alloc_balance=balance,password=password, keyfilePath=keyfilePath)
File "seed-emulator/seedemu/services/EthereumService.py", line 251, in init
from eth_account import Account
ModuleNotFoundError: No module named 'eth_account'

The current design of the reality layer does not fit into the layered design and needs to be reworked. It is more like a utility class. Some of its API take an AS instance from another layer, some return an AS instance. It does not seem to fit the layered design.

The reality layer has initially been making changes as the emulation renders. However, changes introduced when ew "decouple" the references between layers have made it impossible to do it the old way and therefore this un-layered design.

• Implement RemoteAccessProvider interface.
• Implement OpenVpnRemoteAccessProvider.
• Add enableRemoteAccess method on the Network class.
• Add createRealWorldRouter on the AutonomousSystem class.
• Rewrite examples and documentation.

Is it possible to shorten the BGP timeout duration? During the experiment, I would like to disconnect some networks to see how the BGP reroute the traffic. BGP will wait for some time before doing the rerouting. This is for the stability of the network. The timeout duration is too long for the lab activities (it is good for the real world). Can we shorten it to 10 seconds?

Symptoms:

• scion endhosts in different ASes are unable to 'scion ping' each other -> Error fetching paths
  log files of control service reveal that beacon dissemination failed and thus no paths were discovered

Steps-to-reproduce:

• start slightly modified bandwidth-test-example( same topology ): https://github.com/amdfxlucas/seed-emulator/blob/master/examples/scion/S06-overlay-multicast/overlay-multicast.py

Relevant log files:
scion_control_service_log.txt
docker_compose_of_faulty_seed_sim.txt

The routing layer provides the base routing support for other routing protocol layers like OSPF and BGP. Currently, to put a network into the routing daemon's RIB, we use the addDirect call on the routing layer instance.

A better way to handle direct networks is to make direct an attribute of the network object. Instead of calling addDirect on every network, one can specify that they want the network to be added to RIB when doing as.createNetwork. (or maybe even default to direct unless the users set otherwise?)

This is a breaking change and being worked on on the routing-rework branch.

• Remove addDirect from routing layer
• Rework routing layer merger.
• Add direct attribute to networks.
• Rework AS::createNetwork
• Remove addDirect calls from examples.
• Rewrite READMEs from example: add note about direct in createNetwork of AS.

Because containers do not have GUI, for some tasks, we may have to use the docker host (which as GUI). However, the docker host is directly connected to all the networks inside the emulator, i.e., it has a short cut to all the networks. For the purpose of emulation, we would like the host to be directly connected to only one of the networks, so its packets can follow the routing inside the emulator, instead of directly going to the destination.

We do not have a solution yet. We have tried the following:

• Disconnecting the host from those networks: that will break the docker, because apparently the containers depend on them.
• We do have the option to connect to none of the networks by having docker assign "dummy" network prefixes to networks and replace IP addresses with the "real" IP address in the containers at run time.

Having issues building emulators using the docker-compose v2.

The issue caused by an usage of dummy image. When the ImageA is build from ImageB, docker-compose v2 does not necessarily wait until ImageB build is done. So, when the docker compose tries to build ImageA before the ImageB is built, it causes error.

To solve this issue, need to specify that ImageA depends on ImageB using -depends_on entry in docker-compose.yml.