Bug 102540
| Summary: | [netgraph] [patch] supporting vlan(4) by ng_fec(4) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Artemiev Igor <ai> | ||||
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Open --- | ||||||
| Severity: | Affects Only Me | Keywords: | patch | ||||
| Priority: | Normal | ||||||
| Version: | 6.1-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Responsible Changed From-To: freebsd-bugs->ru I'll polish, test and commit. Hi, any progress on this? Would be nice to have it working :) http://www.freebsd.org/cgi/query-pr.cgi?pr=102540 Thanks! :) On Tue, 12 Dec 2006 19:33:21 +0100 Johan Strom <johan@stromnet.se> wrote: > Hi, > any progress on this? Would be nice to have it working :) > > http://www.freebsd.org/cgi/query-pr.cgi?pr=102540 > > Thanks! :) > It works, at least, for me. I've tested it on two routers with Cisco Catalyst 2960G. Considering the patch, ru@ thinks it would not be wise to commit it, as glebius@, it is said, is going to rewrite ng_fec to be a complete interface (not netgraph). glebius@ himself is silent about all this, and hasn't answered my question about the future of ng_fec. -- iprefetch ai Responsible Changed From-To: ru->freebsd-bugs Sorry, but I have lost interest in this. Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s). For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped Keyword:
patch
or patch-ready
– in lieu of summary line prefix:
[patch]
* bulk change for the keyword
* summary lines may be edited manually (not in bulk).
Keyword descriptions and search interface:
<https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
|
ng_fec(4) does not work with vlan(4), because ng_fec_start does not distinguish marked mbuf, also there is no support VLAN_HWTAGGING and VLAN_MTU capability for bundle even if underlying interfaces support it. Fix: Apply a followed patch. After : ngctl -f -<<-EOF mkpeer fec dummy fec msg fec0: add_iface "bge0" msg fec0: add_iface "bge1" msg fec0: set_mode_mac EOF ifconfig vlan2 create ifconfig vlan2 inet 10.0.0.1/8 vlan 2 vlandev fec0 ifconfig fec0 up ifconfig vlan2 up The host B, connected to cisco trunk: ifconfig vlan2 create ifconfig vlan2 inet 10.0.0.2/8 vlan 2 vlandev fxp0 ifconfig fec0 fec0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=18<VLAN_MTU,VLAN_HWTAGGING> ether 00:17:a4:3b:09:3c media: Ethernet none status: active ping 10.0.0.1 - working, because both bge0 and bge1 support VLAN_MTU and VLAN_HWTAGGING fec0 derived their capabilities. If undelying device changes the capabilities, the call ifconfig {vlantag|vlanmtu} updates capabilities at fec interface. How-To-Repeat: The host A, connected to cisco trunk: ngctl -f -<<-EOF mkpeer fec dummy fec msg fec0: add_iface "bge0" msg fec0: add_iface "bge1" msg fec0: set_mode_mac EOF ifconfig vlan2 create ifconfig vlan2 inet 10.0.0.1/8 vlan 2 vlandev fec0 ifconfig fec0 up ifconfig vlan2 up The host B, connected to cisco trunk: ifconfig vlan2 create ifconfig vlan2 inet 10.0.0.2/8 vlan 2 vlandev fxp0 ping 10.0.0.1 - no reply