Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#15661 - [netcfg] Vlan-Config

Attached to Project: Arch Linux
Opened by Oluf Lorenzen (Finkregh) - Thursday, 23 July 2009, 22:26 GMT
Last edited by Ionut Biru (wonder) - Saturday, 12 February 2011, 13:35 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To James Rayner (iphitus)
Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

Details

Description:
Support of VLANs in netcfg would be quite nice


patch is attatched
This task depends upon

Closed by  Ionut Biru (wonder)
Saturday, 12 February 2011, 13:35 GMT
Reason for closing:  Implemented
Additional comments about closing:  http://projects.archlinux.org/netcfg.git /commit/?id=a9d39a075bed12243e6571f475dd f1c2ee0b078b
Comment by Oluf Lorenzen (Finkregh) - Thursday, 23 July 2009, 22:28 GMT
diffstat 0108-added-complete-VLAN-setup.patch
examples/ethernet-iproute-vlan | 10 ++
src/connections/ethernet-iproute-vlan | 134 ++++++++++++++++++++++++++++++++++
src/network | 18 +++-
3 files changed, 159 insertions(+), 3 deletions(-)
Comment by Johannes Woerner (jkwoerner) - Tuesday, 01 June 2010, 19:02 GMT
I would like to see vlans implemented within netcfg. Any chance, this will happen?
On thing needs to be added/configurable: vconfig set_egress_map VLANINTERFACE 2 6
Without this parameter vlans don't work for me.
Comment by Oluf Lorenzen (Finkregh) - Wednesday, 02 June 2010, 08:49 GMT
what sort of hardware/config do you have?
I dont really get why you have to set skb_priority/vlan_qos o.O
Comment by Johannes Woerner (jkwoerner) - Wednesday, 02 June 2010, 09:22 GMT
I've found a way without using egresss_map. Had to use vconfig set_flag VLAN 1 1 (<- need both numbers).
Sorry for that.
Is there a chance that the feature request will be implemented?
Comment by Oluf Lorenzen (Finkregh) - Wednesday, 02 June 2010, 09:38 GMT
what sort of switch and what special config do you have that you have to set the QOS? o.O?

And yes, i think i might implement that sometime...
oh, i still have to test my patch with the newer version of netcfg...
Comment by Johannes Woerner (jkwoerner) - Wednesday, 02 June 2010, 10:54 GMT
Sorry - was double post - so removed
Comment by Johannes Woerner (jkwoerner) - Wednesday, 02 June 2010, 10:58 GMT
Brand of switch is Foundry BigIron, but as I mention in the previous comment, I had to use set_flag with 2 numbers. Without I couldn't use the vlan interface.
I'll give your patch a try.
Comment by Eugene Diachkin (Ineu) - Sunday, 14 November 2010, 21:28 GMT
Hello.
This ticket is not closed, so: is VLAN support going to be implemented in netcfg? It would be convenient to use standard tools to manage VLANs instead of writing script by hands. Thank you.
Comment by Thomas Bächler (brain0) - Sunday, 14 November 2010, 22:12 GMT
I have no time to really work on netcfg (nor does James as it seems), but I am willing to accept new features. The patch in the original post is rather old - if someone would rebase it on the current netcfg code and/or test its function, I'd be glad. I'd also appreciate if any patches would be set up in a public git tree (for example, github).
Comment by Oluf Lorenzen (Finkregh) - Monday, 15 November 2010, 08:50 GMT
well, i'll try to move the patch stuff to github in the next days :o lets hope i find some spare time
Comment by Oluf Lorenzen (Finkregh) - Friday, 10 December 2010, 21:28 GMT
finally rebased on [de9a2b3]: <http://gitorious.org/archlinux-projects/netcfg/commit/df4e0684ca5ee8a41ce646888b1b07847f82624a>

i sadly still have had no time to test the patch...
Comment by Oluf Lorenzen (Finkregh) - Monday, 13 December 2010, 17:01 GMT
now also on github if you like that more ;)
<https://github.com/Finkregh/netcfg/commit/df4e0684ca5ee8a41ce646888b1b07847f82624a>
Comment by Thomas Bächler (brain0) - Monday, 13 December 2010, 17:12 GMT
James, are you still working on this? I am still not that comfortable with netcfg code yet, so my reviews might be a bit stupid.

On a first glance, I think this is redundant. Isn't it possible to just add the vlan-specific configuration and then call the ethernet profile (like wireless does)? Right now, you are duplicating the whole IP configuration bits, like dhcp or static. If it isn't possible to re-use that, it should maybe be factored out so it can be called from both ethernet and vlan. (I know, I probably could have said all this before, when this was first submitted, sorry for all the slowness on my end.)
Comment by Oluf Lorenzen (Finkregh) - Tuesday, 14 December 2010, 11:52 GMT
heh, no problem with that - lets see when i come to work on that ;)
Comment by Wade Carpenter (wade) - Friday, 24 December 2010, 00:13 GMT
Thanks for the initial work! I have another patch based on df4e0684ca5ee8a41ce646888b1b07847f82624a (feature/vlan), see attached.

Subject: [PATCH] Fix some issues with VLAN configuration ...

- Re-use ethernet_up / ethernet_down
- Fix interface references in /var/run/network/ by requiring INTERFACE definition in profile
- Load required variables in network 'load_profile()' function
Comment by Wade Carpenter (wade) - Friday, 24 December 2010, 00:20 GMT
My test device:

CONNECTION="ethernet-iproute-vlan"
DESCRIPTION="A more versatile static ethernet connection using iproute and VLAN"
PHYS_INTERFACE="eth0"
INTERFACE="eth0.10"
VLAN="10"
FLAG="false"
IP="static"
ADDR="10.0.1.120"


And results:

# netcfg -u Test
:: Test up [BUSY] Added VLAN with VID == 10 to IF -:eth0:-
Set flag on device -:eth0.10:- Should be visible in /proc/net/vlan/eth0.10
[DONE]
# ifconfig eth0.10
eth0.10 Link encap:Ethernet HWaddr 00:1D:60:C2:F2:8F
inet addr:10.0.1.120 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: ...
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:418 (418.0 b)

# arp -n 10.0.1.122
Address HWtype HWaddress Flags Mask Iface
10.0.1.122 ether 00:09:0f:88:da:76 C eth0.10

# netcfg -d Test
:: Test down [BUSY] Removed VLAN -:eth0.10:-
Comment by James Rayner (iphitus) - Friday, 24 December 2010, 01:25 GMT
Thomas: yes, that's correct.

It could be refactored out, or setup like the wireless profile, which just calls ethernet. Long term, I suppose refactoring would be better for both wireless, ethernet and this - however for now, just calling ethernet (like wireless) would do fine.

If nobody else picks this up, I might merge another wave of patches in Jan/Feb sometime.
Comment by Thomas S Hatch (thatch45) - Wednesday, 02 February 2011, 00:18 GMT
I thought that vlans did not require vconfig, I have a working implementation of this using only iproute, I will post it
Comment by Thomas Bächler (brain0) - Wednesday, 02 February 2011, 10:05 GMT
Wade, your last patch looks better (only a quick glance, I have no time for a thorough review now). I'd probably squash your and Oluf's patch into one though.

If this (as Thomas says) is possible with iproute and without vconfig, I'd prefer that.

James, how is it looking with the review? If you want me to pull a new batch of patches, please send me a request.
Comment by Thomas S Hatch (thatch45) - Wednesday, 02 February 2011, 15:15 GMT
Sorry, I intended to get this file posted last night, but you know how life is.

I needed to modify the vconfig plugin to allow for named vlan interfaces and a little more flexibility, and I have been using that for my production systems. I have only done some basic preliminary tests with this one, but if we can do it without vconfig, and if we can include interface naming I think that the vlan support would be much better overall. Here is a link to the vlan file:
http://enterprise-archlinux.googlecode.com/hg/netcfg-vlan/vlan

Like I said, I would like to test this more extensively, and I would like to clean up a few things, but I think that the two concepts I am working towards should shine through in the code.
   vlan (0.9 KiB)
Comment by Thomas Bächler (brain0) - Thursday, 03 February 2011, 00:55 GMT
About your vlan script:
1) Don't use ifconfig here, use ip.
2) The error message is copied from the bridge code, maybe fix it so it fits better.
Comment by Thomas S Hatch (thatch45) - Thursday, 03 February 2011, 01:00 GMT
Like I said, it is not done :)
I will have those changes done in a few days and give it ample testing, thanks for the feedback
Comment by Thomas S Hatch (thatch45) - Thursday, 03 February 2011, 06:23 GMT
Alright gents, let me know what else I need to make better!

I have tested this out on some of my qa servers, and it... works!

This should only require iproute, no vconfig and no ifconfig
Comment by Thomas Bächler (brain0) - Thursday, 03 February 2011, 09:59 GMT
This looks very good. What does the rest think (especially the authors of the previous patches)?

We could talk about the following:
1) Could we provide a useful 'status' function?
2) Does the link checking work automatically (i.e., a link on the physical interface will show a link on the vlan)?
3) It probably needs a check whether VLAN_RAW_DEV and VLAN_ID are set. I am also thinking about naming: should VLAN_RAW_DEV be rather names VLAN_PHYSDEV, or VLAN_PHYS_DEV or so (not important, just a thought)?
Comment by Oluf Lorenzen (Finkregh) - Thursday, 03 February 2011, 13:40 GMT
1) for dev in ${all netcfg-vlan-configs} ; do ip link show $dev ; done

3) VLAN_PHYSDEV / VLAN_PHYS_DEV would be better, as you can still have an IP on the phys-dev (making it a not-raw-dev). "Raw" should only be used if the underlying interface cannot be used itself anymore (which might never (vlan/briding/ppp...) happen, as far as i know)

the examples should look like that:
INTERFACE="eth0.11"
as this is the default notation. naming interfaces completely different should be upt to the user
Comment by Thomas Bächler (brain0) - Thursday, 03 February 2011, 13:56 GMT
Oluf, if I understand it correctly, 'status' should indicate whether the profile has been started or not.
Comment by Oluf Lorenzen (Finkregh) - Thursday, 03 February 2011, 14:05 GMT
Thomas: ah, i must say i did not look after the behaviour for the other profiles ;)

if [ -e /sys/class/net/${INTERFACE_FROM_PROFILE} ]; then
echo "profile '${PROFILE}' active"
ip link show ${INTERFACE_FROM_PROFILE}
else
echo "profile '${PROFILE}' inactive"
fi
Comment by Thomas S Hatch (thatch45) - Thursday, 03 February 2011, 17:21 GMT
Perfect, thanks! I will make those changes and additions and post a new one.
Comment by Thomas S Hatch (thatch45) - Friday, 04 February 2011, 02:08 GMT
The latest, but I can't seem to find an interface to test the status function, is it used at all?
Comment by Thomas S Hatch (thatch45) - Friday, 04 February 2011, 02:58 GMT
The latest, but I can't seem to find an interface to test the status function, is it used at all?
Comment by Thomas Bächler (brain0) - Friday, 04 February 2011, 07:18 GMT
I don't know. I think you are supposed to return true or false and not print anything. The ethernet_status functions seems to be the only working one - wireless has one that looks rather broken, ppp doesn't have one, bridge has a noop. James, what's the status of these status functions?
Comment by Thomas Bächler (brain0) - Friday, 04 February 2011, 07:19 GMT
Okay, other than the status function, this looks good.
Comment by Oluf Lorenzen (Finkregh) - Friday, 04 February 2011, 07:32 GMT
okay, i dunno if we intend to follow the LSB, but we should print something human-readable and use exit-codes for automatic interaction <http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html>

i should eventually open a new bug for that and let you pack that what we have into the next version ;)
Comment by Thomas Bächler (brain0) - Friday, 04 February 2011, 08:07 GMT
That is a bigger project that would include lots of review of the netcfg code.

The status function is intended as an internal function (as far as I can see) - a human-readable output should be generated by the frontend.
Comment by Thomas S Hatch (thatch45) - Friday, 04 February 2011, 19:39 GMT
So then, whats the final verdict? Should I change the status function to return a bool? And is there anything else barring this feature from being placed into netcfg? I would love to get this put through, it why I am writing it :)
Comment by Thomas Bächler (brain0) - Friday, 04 February 2011, 22:13 GMT
Yes, change the status to a bool with no output. I am not sure if or where it is needed, but let's just do it.

The only other thing to do is: you could prepare it as a patch using git, so you will be listed as author in the log.
Comment by Thomas S Hatch (thatch45) - Friday, 04 February 2011, 22:48 GMT
the git, of course :) will do
Comment by Thomas S Hatch (thatch45) - Saturday, 05 February 2011, 18:27 GMT
Ok, here is the patch, and the status function has been changed to return a bool.

Let me know if there is anything else I can to get this into netcfg
Comment by Thomas Bächler (brain0) - Saturday, 05 February 2011, 18:34 GMT
Applied, thanks.
Comment by Thomas S Hatch (thatch45) - Saturday, 05 February 2011, 18:49 GMT
Thanks Thomas! I assume we can close this out then!

Loading...