Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with creating ip address/assinging port in Linux (arch) #12

Closed
ocnix opened this issue Jul 30, 2019 · 11 comments
Closed

Issues with creating ip address/assinging port in Linux (arch) #12

ocnix opened this issue Jul 30, 2019 · 11 comments

Comments

@ocnix
Copy link

ocnix commented Jul 30, 2019

I am having some issues running monday on arch linux, while looking through the code base looks like the networkinterface is being hard coded:
/monday/pkg/proxy/network.go:

const (
	networkInterface = "lo0"
)

my loopback interface is set to lo. I changed the constant and ran into some other issues: ifconfig is being used to, some linux distros dont come with net-tools installed (ip is a better choice) but even with net-tools installed it is running ifconfig incorrectly for linux:

args := []string{"lo0", "alias", ip.String(), "up"}

linux should be args := []string{"lo", ip.String(), "up"}

after making all these changes on my local i am still getting this error:

Unable to find an available IP/Port

Looks like its unable to assign a port to ip addresses ( last byte in addr is always off by one so it never assigns a port) in
/monday/pkg/proxy/network.go
if addr.String() == ip.String()+"/8"

@ocnix
Copy link
Author

ocnix commented Jul 30, 2019

Looks like there is an integer overflow of some sort, first iteration the ip addresses look like this:
interface ip: 127.1.2.254/8 ----- generated ip: 127.1.2.1/8 after flushing the interface

if you stop the service and restart looks like they finally line up

interface ip: 127.1.2.1/8 ----- generated ip: 127.1.2.1/8

it connects this time but still breaks:
tcp 127.1.2.1:8080: connect: connection refused

was anyone successful in running this in linux?

@eko
Copy link
Owner

eko commented Jul 30, 2019

Hi @ocnix,

Thank you for your feedback, it will really help me to make Monday compatible with the most environments. I am currently running under macOS.

I will add an environment variable like MONDAY_NETWORK_INTERFACE in order to allow you setting a custom network interface (lo in your case). Will this be a good solution to fix your issue?

It’s great if the tool works after flushing your interface, I think you have forwarded a port but it is not available so the TCP proxy cannot connect to it.

@ocnix
Copy link
Author

ocnix commented Jul 30, 2019

@eko thanks for getting back!

yes that would be great if we can pass the interface or having something like this:

func getInterface() (string, error) {
var networkInterfaceName string
ifaces, err := net.Interfaces()
if err != nil{
fmt.Println("Error getting interfaces: ", err)
return "", err
}
for _, i := range ifaces{
ifaceFlags := i.Flags.String()
if strings.Contains(ifaceFlags, "loopback"){
networkInterfaceName = i.Name
return networkInterfaceName, nil
} else {
return "", err
}

}

return "", nil
}

also the usage of ifconfig needs to be addressed because it is used differently on Linux. MacOS you need to pass alias sub command while Linux you don't.

Another thing is that on Linux the Ip addresses will never match because the generate IP address is always higher, any reason why this is happening?

@eko
Copy link
Owner

eko commented Aug 1, 2019

Hi,

I have to idea why generate IP address is higher for you. I will try to install a linux VM to debug this over the week-end.

While waiting, I just added your suggested changes to determine the network interface automatically in the following PR: #14

Thank you for your help

@ocnix
Copy link
Author

ocnix commented Aug 2, 2019

@eko thanks for looking into it, I managed to find a way to get ip addresses in linux, you simply just return the ip address if linux but we are getting a segmentation vault when i do this on my fork:

`if networkInterface == 'lo'{
return b, nil
}'

[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x109a70d]
goroutine 29 [running]:
github.com/eko/monday/pkg/proxy.(*Proxy).handleConnections(0xc000316070, 0xc000328000, 0xc00050ce40, 0x17)
	/home/ocsam/go/src/github.com/eko/monday/pkg/proxy/proxy.go:105 +0x45d
created by github.com/eko/monday/pkg/proxy.(*Proxy).Listen
	/home/ocsam/go/src/github.com/eko/monday/pkg/proxy/proxy.go:72 +0x3cc

@mcadam
Copy link

mcadam commented Aug 28, 2019

Hello, I am trying out Monday to get some load of our machines while developing on services, great service and way of doing things.

I am also running into the same issue on linux if I have multiple forwards in place. If I only have one, even with the error that it can't find an IP, still works and just use 127.0.0.1 but with multiple forwards I get a nil pointer error cause the port can't be assigned twice to the same ip (normal).

Screenshot 2019-08-27 at 18 36 26

Same config works fine on MacOS.

@eko
Copy link
Owner

eko commented Aug 28, 2019

Hi @mcadam, which Linux distribution are you using please?

@mcadam
Copy link

mcadam commented Aug 28, 2019

Hi more information about my env
Ubuntu 18.04.2 LTS
monday 1.0.4

@eko
Copy link
Owner

eko commented Sep 13, 2019

Hi @ocnix, @mcadam,

I just fixed some issues using a Ubuntu VM, could you please test the new v1.0.6 release and see if it's better for you?

You can also upgrade your Monday version running: monday upgrade

Thank you

@ocnix
Copy link
Author

ocnix commented Sep 18, 2019

@eko it is stil broken, I have fixed this issue in my own fork, for linux you just have to check if tcp connection if available with that ip address and return it, no need to create it via ifconfig alias ex:

	if iface.Name == "lo" {
		_, err := net.Dial("tcp", ip.String()+":"+port)
		if err != nil {
			return ip, nil
		}
		return ip, err
	}

@eko
Copy link
Owner

eko commented Oct 28, 2020

Closing this issue for now as I think this is resolved since some latest updates. Network interfaces are not hardcoded anymore.

Feel free to reopen if the issue still persists and I will definitively tackle this issue.

Thank you

@eko eko closed this as completed Oct 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants