Bug 1403623

I was not able to reproduce it here using qemu images and c3745 image.

Could you please reproduce the bug using: gns3 --debug 2>&1 | tee gns3-debug-output.log

Please attach:

1. gns3-debug-output.log

2. project file (zipped, I suppose you don't have anything confidential there)

Created attachment 1230837 [details]
gn3 log when open a previous project built under Fedora 24 and gns3-1.5.1

Created attachment 1230838 [details]
the corresponding project for the first gns3 log provided above

Created attachment 1230839 [details]
gns3 log when trying to build a new project in a blank topology

Here above are the details.
I'm trying to compare what is different between Fedora 24 and Fedora 25 environnement.
Because the basic are the same:
gns3-gui-1.5.1
gns3-server-1.5.1
(in fedora 24 I installed the release from the original ZIP on github, and a *.spec file of my own. I tryed to rebuild on Fedora 25 the gns3-gui and gns3-server rpm packages , with the same ZIP original file and my spec file, but I get the same result than with the one coming from fedora standard repository

Because http_client.py, component of gns3-server use the pakage python3-aiohttp, I checked the release of this component.
I used the same release:
  Under Fedora 25:
  # rpm -qa | grep aiohttp
  python3-aiohttp-0.21.6-4.fc25.x86_64

  Under Fedora 24:
  # rpm -qa | grep aiohttp
  python3-aiohttp-0.21.6-4.fc24.x86_64

So the difference is more deeper in Python3 library. But I don't know how to track this !
=============
Additionally, with selinux in permissive mode, or in enforcing mode, and firewall stopped or running,
I ALWAYS GET a good result in Fedora 24, while gns3 fails in Fedora 25

A TEST with curl, confirm the problem.
Once gns3-gui is open, with no project open ( so just only a process python3 corresponding to gns3-server ins running and listening on TCP port 8000),
ON FEDORA24
# curl http://127.0.0.1:8000
return Nothing on stderror, and $?=0,

ON FEDORA25
[root@ismf33 ~]# curl http://127.0.0.1:8000
405: Method Not Allowed[root@ismf33 ~]# 
and $?=0

I'll take a look into the project file.

Could you update python3-aiohttp to python3-aiohttp-1.0.5-1.fc25, it should be in -testing repo, you'll need to manually install python3-async-timeout-1.1.0-3.fc25.noarch

https://bodhi.fedoraproject.org/updates/FEDORA-2016-2282d5fd5b


dnf install --enablerepo=updates-testing python3-async-timeout 
python3-aiohttp

Thanks
I just do
# dnf install --enablerepo=updates-testing python3-async-timeout
and
# dnf update --enablerepo=updates-testing python3-aiohttp

AND NOW all is working fine;
-> Creating a new project by adding router
-> Openning an old project
=======================

AT lest if webmin service is not running (by default on TCP 10000 and UDP 10000)

+++++++++++++++=
This is an other problem, with NIO port, if we let in
GNS3 Preference -> server -> UDP tunnelling port range to the default:
10000 to 20000
GNS3 cannot open the first link between object. I already discussed about that in GNS3 forum and I dont know if some one is trying to correct this bug. The problem is in the method used to check if the port is busy or not, so in that circumstance with the same project that I provided here, only a link remain open

and we have something like the following in GNS3 console:
=================
error while adding a NIO for R1: unable to create UDP NIO
Server error from http://127.0.0.1:8000: R1: unable to create UDP NIO
deleting link from R1 FastEthernet0/0 to SW1 FastEthernet0/0
================

and on port point of view:
# netstat -aupn | grep 10000
udp        0      0 0.0.0.0:10000           0.0.0.0:*                           27434/perl          
udp        0      0 127.0.0.1:10001         127.0.0.1:10000         ESTABLISHED 17241/dynamips   

Perl process is the webmin server. Can you imagine dynamips trying to talk with webmin perl proces ???? A "deaf Dialog" when we say in French !!!
==== 
On the other hand On my MacOSX El Capitan, with the release gns3-1.5.2, all is working fine. When webmin perl process is running on top of TCP and UDP port 10000, gns3 open NIO port for links, starting from 10001, 10002 and so on.
=====

So I tried also
# dnf update --enablerepo=updates-testing gns3-gui  gns3-server
to be in gns3-1.5.2 release on my fedora 25, 

==> BUT the problem PERSISTS.
Once again, the under lying python3 library are not implemented in the same way than on BSD MacOSX I suppose.
===

+++++++++++++++++++++++++++++++++
Well this problem is far less critical than the one signalled by this bug, because you can easily turn around by changing the UDP tunnelling port range in GNS3 preference.
But anybody must be AWARE of it, if ever they make running an other service than webmin on 10000 UDP port !!!
+++++++++++++++++++++++++++++++++

THANKS for the suggestion

Thanks for your feedback, regarding the second issue, I think it's hard to avoid since GNS3 components will use a lot of ports for various things (consoles, vnc, telnet and such), but most of them are binded to localhost.

It might be good to bind Webmin port to main IP [1] to avoid similar issues (if I recall in miniserv.conf file)

[1] http://doxfer.webmin.com/Webmin/Webmin_Configuration#Ports_and_Addresses

Please let me know if I can close this bug.

Yes this bug as defined in the title, gets its solution with python3-aiohttp-1.0.5.
But it means, that python3-aiohttp-1.0.5, andpython3-async-timeout-1.1.0-3  must be in fedora update, 

and may be gns3 spec file modified with:
Requires:  python3-aiohttp >= 1.0.5
Requires: python3-async-timeout >=1.1.0

and so updated too, in fedora update
to avoid future request for the same bug ?

Shouldn't this be filed against the python3-aiohttp component?
The example server from aiohttp docs doesn't work either, so it's in no way specific to gns3-server.

python3-aiohttp has been pushed to -testing, it'll soon hit stable
gns3 1.5.2 pushed to stable