This has been annoying me for some time now. Such to the point where I changed the SSID for my network. But I cannot go around doing that for all. Basically there are lots of characters that are supported and 100% valid for SSID. But cannot be written to /etc/conf.d/net as is. It does not seem to break other things like wpa_supplicant. This might be related to openrc, I noticed some other bugs on characters not being supported. Clearly spaces and hyphens bash does not like. For example #Generated by NetworkManager ###### Global Configuration ###### modules=( "iproute2" "wpa_supplicant") ###### Connection Configuration ###### #---------------------------------- config_peak 10 customer=( "dhcp" ) enable_ipv6_peak 10 customer="false" auto_peak 10 customer="true" Using the above example net.lo init script fails to start. When net.lo fails to start, it causes all sorts of things to not work and is a head ache I am really tired of dealing with. Like now I can't even set the time on my machine. This is what I keep running into and is VERY annoying. Caused by spaces in the conf.d/net file written by network manager. /etc/init.d/ntp-client restart * Caching service dependencies ... /etc/init.d/../conf.d/net: line 16: syntax error near unexpected token `(' /etc/init.d/../conf.d/net: line 16: `config_peak 10 customer=( "dhcp" )' /etc/init.d/../conf.d/net: line 16: warning: syntax errors in . or eval will cause future versions of the shell to abort as Posix requires /etc/init.d/../conf.d/net: line 16: syntax error near unexpected token `(' /etc/init.d/../conf.d/net: line 16: `config_peak 10 customer=( "dhcp" )' /etc/init.d/../conf.d/net: line 16: warning: syntax errors in . or eval will cause future versions of the shell to abort as Posix requires /etc/init.d/../conf.d/net: line 16: syntax error near unexpected token `(' /etc/init.d/../conf.d/net: line 16: `config_peak 10 customer=( "dhcp" )' /etc/init.d/../conf.d/net: line 16: warning: syntax errors in . or eval will cause future versions of the shell to abort as Posix requires Service `nfs' needs non existant service `portmap' Service `nfsmount' needs non existant service `portmap' Service `rpc.idmapd' needs non existant service `portmap' Service `rpc.statd' needs non existant service `portmap' [ ok ] /etc/init.d/../conf.d/net: line 16: syntax error near unexpected token `(' /etc/init.d/../conf.d/net: line 16: `config_peak 10 customer=( "dhcp" )' /etc/init.d/../conf.d/net: line 16: warning: syntax errors in . or eval will cause future versions of the shell to abort as Posix requires * net.lo: error loading /etc/init.d/../conf.d/net * ERROR: net.lo failed to start * ERROR: cannot start ntp-client as net.lo would not start This was happening to me before when I had my network SSID as obsidian-studios. I changed that to obsidianstudios because the hyphen caused breakage just like above. Now it breaks on the next entry because it has spaces. This is a bit ridiculous, and something needs to be done to correct this ASAP, please. Network manager should not be writing stuff to conf.d/net that prevents net.lo from starting! This is the script I have to run to setup lo, I named it net_lo_hack.... depend() { need localmount after bootmisc before net } start() { ifconfig lo up route add -net 127.0.0.0 netmask 255.0.0.0 gw 127.0.0.1 cd /lib/rc/init.d/started ln -s /etc/init.d/net.lo domainname obsidian-studios.com eend $? } Hopefully this can be corrected ASAP as its pretty severe. It has happened on several versions of network manager now. Thus not including a version in the summary. I do not believe its specific to any one version, and is broken like this across all.
I hope that I understand you correctly. Here's the thing. ifnet plug-in store ssid in /etc/conf.d/net. If your ssid contains any character that can't be accepted by openrc, that file can't be handled. But if the plug-in doesn't write these things to /etc/conf.d/net, the connection couldn't be stored. So, if you have to use such ssid that can't be handled by openrc, I'd suggest you use keyfile plug-in instead which won't touch /etc/conf.d/net at all. Or you have to change your ssid.
(In reply to comment #1) > I hope that I understand you correctly. Here's the thing. ifnet plug-in store > ssid in /etc/conf.d/net. If your ssid contains any character that can't be > accepted by openrc, that file can't be handled. Yes that is correct > But if the plug-in doesn't write these things to /etc/conf.d/net, the > connection couldn't be stored. It can be stored at the user level not system. Some connections I want to come up when I boot up, not after log in or as part of my user account. Which I thought was the idea behind a system account. > So, if you have to use such ssid that can't be handled by openrc, I'd suggest > you use keyfile plug-in instead which won't touch /etc/conf.d/net at all. Or > you have to change your ssid. Ok I did not think that was an option for boot. I saw mention of it on wiki as route to take for boot support, but had other steps that do not seem to be necessary when using the ifnet plugin. Otherwise I have no problem going that route. However later on would like to see other things, like be able to change /etc/hosts file based on a connection. To have that like pre-specified and swapped out when changing connections. Not sure that would be possible going the keyfile plugin route. But that support does not exist, so would not be a blocker at this time. Now another option after reviewing /etc/conf.d/wireless.example, would be if the ifnet plugin used a different format. For example instead of using the ssid in the variable name. Why not record the mac address of the wap, and assign it an ssid as part of a variable for that wap. That will be safe across the board. Like config_001122334455=( "dhcp" ) mac_essid_001122334455="ESSID" Though that will only work after negotiation or once the mac address has been recorded and you are connected to the wap. Not sure when the information from ifnet plugin is written to /etc/conf.d/net. Like if someone adds a new connection, sets it to be system. They likely won't have a mac address if they know the wap mac address at all. Also I do not believe there is anywhere to specify that in the edit connection GUI. There is a place for device mac, but I assume thats for the nic mac, could be the wap mac. If so could pass that info along from there. Anyway that is another potential route to go that won't break openrc. More than one way to configure wireless settings in /etc/conf.d/net
> However later on would like to see other things, like be able to change > /etc/hosts file based on a connection. To have that like pre-specified and > swapped out when changing connections. Not sure that would be possible going > the keyfile plugin route. But that support does not exist, so would not be a > blocker at this time. keyfile plugin can do almost everything that ifnet plugin can do. So I think this could satisfy your need. > > Now another option after reviewing /etc/conf.d/wireless.example, would be if > the ifnet plugin used a different format. For example instead of using the ssid > in the variable name. Why not record the mac address of the wap, and assign it > an ssid as part of a variable for that wap. That will be safe across the board. > > Like > config_001122334455=( "dhcp" ) > mac_essid_001122334455="ESSID" > > Though that will only work after negotiation or once the mac address has been > recorded and you are connected to the wap. Not sure when the information from > ifnet plugin is written to /etc/conf.d/net. Like if someone adds a new > connection, sets it to be system. They likely won't have a mac address if they > know the wap mac address at all. Also I do not believe there is anywhere to > specify that in the edit connection GUI. There is a place for device mac, but I > assume thats for the nic mac, could be the wap mac. If so could pass that info > along from there. We developed ifnet plugin to simplify network configuration via /etc/conf.d/net, make NM compatible with /etc/conf.d/net. If we need new configuration file, ifnet plugin makes no sense because we already have keyfile plugin. There's one solution though I haven't tested. You can transform your SSID to ascii code and use config_0xab3ace....="...." in /etc/conf.d/net. Please let me know if this works.
(In reply to comment #3) > > keyfile plugin can do almost everything that ifnet plugin can do. So I think > this could satisfy your need. What is the purpose of the ifnet plugin then if most everything can be done with the keyfile plugin? I am a bit confused there. > We developed ifnet plugin to simplify network configuration via > /etc/conf.d/net, make NM compatible with /etc/conf.d/net. If we need new > configuration file, ifnet plugin makes no sense because we already have keyfile > plugin. I was not speaking about a new configuration file. The example I provided in comment #2 is an alternative syntax that is currently respected by conf.d/net. I mentioned wireless.example which is deprecated, but the syntax is still supported and valid in conf.d/net.example as well. > There's one solution though I haven't tested. You can transform your SSID to > ascii code and use config_0xab3ace....="...." in /etc/conf.d/net. Please let me > know if this works. I am not sure what your referring to as ascii code. Do you mean hex? Also wouldn't it be NM that would do the transformation and write that to /etc/conf.d/net? I don't care how NM writes the info, just so long as it doesn't break net.lo init script. But writing via hex seems like a safer way to go, and can put the regular ssid in a comment above.
By the way, are the monitoring log lines necessary? Seems like excessive and repeat logging of the same information. If not necessary might silence that, or maybe provide a verbosity level as part of config.
Comment # 5 was meant for another bug, my bad :)
(In reply to comment #4) > (In reply to comment #3) > > > > keyfile plugin can do almost everything that ifnet plugin can do. So I think > > this could satisfy your need. > > What is the purpose of the ifnet plugin then if most everything can be done > with the keyfile plugin? I am a bit confused there. > ifnet plugin could work when there's a usable /etc/conf.d/net. We want NetworkManager to work with our distro specific configuration file. You can refer to my blog for more info http://qiaomuf.wordpress.com/category/gentoo/. > > There's one solution though I haven't tested. You can transform your SSID to > > ascii code and use config_0xab3ace....="...." in /etc/conf.d/net. Please let me > > know if this works. > > I am not sure what your referring to as ascii code. Do you mean hex? Also > wouldn't it be NM that would do the transformation and write that to > /etc/conf.d/net? I don't care how NM writes the info, just so long as it > doesn't break net.lo init script. But writing via hex seems like a safer way to > go, and can put the regular ssid in a comment above. > Yeah, I was not clear :). Yes I mean hex. Your advice is very good, I will think about it. But before that, you could use hex format to solve your problem (not changing your ssid, just use equivalent hex format in /etc/conf.d/net or nm-applet)
(In reply to comment #7) > > ifnet plugin could work when there's a usable /etc/conf.d/net. We want > NetworkManager to work with our distro specific configuration file. You can > refer to my blog for more info http://qiaomuf.wordpress.com/category/gentoo/. FYI your blog is why I started using NM in the first place. I tried it years ago on Gentoo and gave up on it very quickly. Also started using valgrind as a result of your blog. Presently doing a port of java-config from python to C, mostly to learn C, but also to make the system tools independent of an interpreter. > Yeah, I was not clear :). Yes I mean hex. Your advice is very good, I will > think about it. But before that, you could use hex format to solve your problem > (not changing your ssid, just use equivalent hex format in /etc/conf.d/net or > nm-applet) Ok I am with you now, I wasn't sure where you wanted me to set that. Since I did not edit the conf.d/net file, I let NM do that. But I get what I typed into the GUI connection editor is what showed. However the GUI likes to sync the name with the SSID for some reason. Fought with that for a bit, then just let NM have its way :) I will check out the hex option and report back.
BTW forgot to mention, on the hex route. I was thinking more that the user would not do anything. But NM/ifnet-plugin would take the user entered SSID/connection name, and convert that to hex when writing to conf.d/net. That way the user doesn't do anything any different. Then in the comments in conf.d/net NM can write the actual SSID, with variables below being in hex. That might be your intention, not sure if you just want me to test out if having a hex variable name will work. But seems like you know that will, so might be best to handle it transparently in ifnet-plugin.
OK, I didn't expect that I could fix this so fast. Now NM could handle it transparently. Thank you for your support :). Please try networkmanager-0.8.2-r8.
I had faith in you, just needed a sounding board is all. That definitely resolved the issue with openrc and unsupported characters. Only one minor aesthetic issue left. Best way to explain that is in an attached screenshot. The SSID is converted back from hex in the SSID field. But ideally would be nice if it was converted in the connection name as well. Purely a visual thing, as read/write will have to convert from/to hex. But otherwise seems like we are good to go. Thanks for addressing the issue so fast, just wish I said something sooner ;)
Created attachment 263883 [details] Screenshot of hex ssid displayed in connection name but not ssid field
(In reply to comment #11) > I had faith in you, just needed a sounding board is all. That definitely > resolved the issue with openrc and unsupported characters. Only one minor > aesthetic issue left. Best way to explain that is in an attached screenshot. > The SSID is converted back from hex in the SSID field. But ideally would be > nice if it was converted in the connection name as well. Purely a visual thing, > as read/write will have to convert from/to hex. But otherwise seems like we are > good to go. Thanks for addressing the issue so fast, just wish I said something > sooner ;) Ah, right. Please try networkmanager-0.8.2-r9. I should have done this in the previous revision bump :P >
Excellent work, we are good to go, and closing the bug now, thank you for the speedy fixes!
