#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 , 6 years ago
comment:2 by , 6 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 , 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.
I should add that I normally connect via WiFi, but when I connect a cable it behaves the same.
follow-up: 9 comment:4 by , 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 , 5 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 , 5 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 , 5 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 , 5 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!
comment:9 by , 5 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 , 5 years ago
Status: | new → in-progress |
---|
comment:12 by , 5 years ago
Milestone: | Unscheduled → R1/beta2 |
---|
Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone
Probably a duplicate of #6351?