Netgraph module problem

  • I need to build netgraph kernel module for pfSense 2.0 RC.
    I tried to add "export MODULES_OVERRIDE=${MODULES_OVERRIDE:-"i2c ipmi acpi ndis ipfw ipdivert dummynet fdescfs cpufreq opensolaris zfs glxsb runfw if_stf netgraph"}" to pfsense-build.conf, build it.  "kldload /boot/kernel/netgraph.ko" it says module already registered, with ng_vlan.ko, ng_ether.ko either. But "ngctl list" doesn't include physical ether interface, only shows socket type.

    The question is that whether the above procedure is correct for building netgraph kernel module? If not, please give me a hint.

  • You are not saying what you need to do since i have patched pfSense for some things in netgraph.

  • @ermal:

    You are not saying what you need to do since i have patched pfSense for some things in netgraph.

    ermal, Sorry for my inaccurate post.
    I'm trying to do super vlan in pfSense, which depends on netgraph, ng_ether, ng_vlan kernel module.
    Currently, I tested it on FreeBSD 8.1 amd64 with 2.0RC1. After adding netgraph to  MODULE_OVERRIDE option, I successfully built them. But, it seems that ng_ether doesn't recognize onboard physical ethernet interface.

    With pfSense 1.2.3 on FreeBSD 7.2, the ng_ether kernel module work well but I can't have ng_vlan module compile. So I tried pfSense 2.0.

    Normal "ngctl list“ command on FreeBSD would show:

    There are 3 total nodes:
      Name: em0             Type: ether           ID: 00000002   Num hooks: 0
      Name: em1             Type: ether           ID: 00000003   Num hooks: 0
      Name: ngctl17227      Type: socket          ID: 0000001e   Num hooks: 0

    But in pfsense 2.0, it only shows the following without ether type.

    There are 4 total nodes:
      Name: <unnamed>Type: socket ID:0000000d Num hook: 0
      Name: <unnamed>Type: socket ID:0000000c Num hook: 0
      Name: <unnamed>Type: socket ID:00000005 Num hook: 0
      Name: ngctl9676	Type: socket ID:000000019 Num hook: 0</unnamed></unnamed></unnamed> 

  • All is there, you do not need to build anything, just that in pfSense we detach by default ng_ether from the intefaces(since its overhead).
    You can attach interfaces to ng_ether again if you want with php code since i haven't patched ngctl actually.

    Super vlan means QinQ?
    If yes there is support in the GUI for that though it needs more testing.

    Not sure if that answers your question.

  • Super VLAN is not QinQ, it's defined in RFC 3069.

    Could you please give me more guide on attach ng_ether to interfaces?

  • Its a php function pfSense_ngctl_attach() search around in the source tree its.

    BTW can you tell me how you achieve this with netgraph so i can possibly integrate into pfSense?

  • Thanks for your indication. I'm currently making efforts on testing it.
    You can refer:

  • There is nothing in that link that cannot be done today on pfSense from the GUI.
    He is using ng_vlan possibly because he likes too but really it is just the same vlan that pfSense GUI provides in the end.

    Also for the bridge functionality just go to interfaces->assign->bridge and create teh bridge and under advanced option you have everything he does.
    Assign the bridge interface and you are done!

    Thought it was something else.

    Tell me if it works or not.
    Possibly a wizard needs to be done for this super-vlan since it envolves some operation!
    For now i put it here

  • You are right, ermal.
    It could be done in pfsense by create a bridge and associate vlan interfaces without netgraph.
    I've manually created a bridge named br0 and assign several vlan interfaces to it, then assign br0 as LAN interface, test result shows it works fine.
    As you said, a web wizard is needed to be implemented. I cannot assign vlan interface to a bridge in pfsense and a bridge cannot be assigned as LAN in web.

  • Really do not need to assign bridge as another interface and then just change description and possibly the ip back and forth to the new assignment.
    You want feel the difference. LAN/WAN is relevant only on 1.2.x series, i can not stress this that much.

    In 2.0 LAN is just a description.

Log in to reply