Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#14908 closed bug (fixed)

net_server mixes up interfaces in settings file

Reported by: pulkomandy Owned by: axeld
Priority: normal Milestone: R1/beta2
Component: Servers/net_server Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

/system/settings/network/interfaces:

interface       /dev/net/usb_ecm/0 {
        address inet {
                address 192.168.4.2
                mask    255.255.255.0
        }
}
interface       /dev/net/rtl81xx/0 {
        address inet {
                auto_config     true
        }
}

USB interface currently not connected. Static IP gets assigned to the second interface. I have to reset that one in Network preferences everytime, which does not seem to have any effect on the setting file. At next reboot, the problem is back.

Change History (12)

comment:1 by waddlesplash, 5 years ago

Probably a duplicate of #6351?

comment:2 by pulkomandy, 5 years ago

No, #6351 is/was exclusively about the DNS information, which isn't specific to a device, but extracted from DHCP fr each device, leading to some understandable confusion.

Here the setting entries are not bound to the right card, which is a more important bug.

comment:3 by Pete, 5 years ago

I'm tagging this on here, rather than in a new ticket, because I'd guess it's related. Apologies if I'm wrong. I've recently installed Beta1 (hrev52295+129), and find that it insists on using DHCP even though I want Static! It seems to ignore the ...settings/network/interfaces file, which has:

interface	/dev/net/iprowifi4965/0 {
	address	inet {
		address	192.168.1.6
		mask	255.255.255.0
		gateway	192.168.1.1
	}
}
interface	/dev/net/rtl81xx/0 {
	address	inet {
		address	192.168.1.16
		mask	255.255.255.0
		gateway	192.168.1.1
	}
}

Despite that file, it always assigns an arbitrary DHCP addrees on boot, and the Preferences correspondingly says 'DHCP'. If I change it to Static, with the desired IP, I just lose the connection, and at next boot it's back to DHCP. Strangely the file's timestamp indicates it was rewritten, but the contents seem to remain as I set them above.

Version 0, edited 5 years ago by Pete (next)

comment:4 by kallisti5, 5 years ago

see https://dev.haiku-os.org/ticket/14626 as well. It was closed but I think that was premature.

comment:5 by AGMS, 4 years ago

Yes, it's still a problem in hrev53552. Switching DHCP to Static works while running, but upon reboot, it's back to DHCP. Looking at the /boot/system/settings/network/interfaces it has two network card entries, and picks the wrong one - did someone put != instead of == in a string comparision? The workaround is to delete the interfaces file then use the Preferences, which will recreate it with just one network card.

comment:6 by Pete, 4 years ago

Hmm. In contrast -- running hrev53511 -- I don't see this anymore. Both my wifi and wired connections are set as static, and that's the way they connect. Maybe when I did the upgrade somehow I set the interfaces file correctly. Anyway it just shows one entry for each card.

OTOH, although I have a 'wireless_networks' file pointing to my local router, it doesn't connect automatically as I would expect. I have to select it from thewifi menu.

comment:7 by AGMS, 4 years ago

My trouble was that there were two network card entries, but only one network card. One entry was for a different network card that had been present earlier. One entry was DHCP, the other static. Easiest to test when you switch virtual network cards in VirtualBox.

comment:8 by Pete, 4 years ago

Ahh. apparently I misunderstood. One of the entries was for a no-longer-existing card? I guess the system should be able to figure out that card was gone!

in reply to:  4 comment:9 by axeld, 4 years ago

Replying to kallisti5:

see https://dev.haiku-os.org/ticket/14626 as well. It was closed but I think that was premature.

The bug itself is no bug, but intended behaviour. Whether that makes sense or not, I left open for discussion, but no one cared so far :-)

In any case, the behaviour described in this ticket is certainly a bug.

comment:10 by axeld, 4 years ago

Status: newin-progress

comment:11 by axeld, 4 years ago

Resolution: fixed
Status: in-progressclosed

Fixed in hrev53582.

comment:12 by nielx, 4 years ago

Milestone: UnscheduledR1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.