vlan tagging on wan port

Discussion in 'Tomato Firmware' started by bogderpirat, Feb 24, 2009.

  1. bogderpirat

    bogderpirat Network Guru Member

    hello guys,

    i'm at a german isp that calls itself t-home, they offer IPTV and interwebs over VDSL2.

    in order to connect via vdsl, you get your modem hooked up and connect to it using a network card that lets you apply vlan tags to the outgoing packets. over an in such a way tagged device, you can then start your garden variety pppoe-daemon and establish a ppp connection.

    i have succeeded in establishing a connection using my ubuntu linux box and create a vlan interface doing the following:

    vconfig add eth0 7

    pppoeconf was then able to detect an access concentrator on eth1.7 and configure login data for a connection. `pon` then established the ppp connection and everything worked excellently.

    okay now, since tomato is basically an embedded linux system, i was trying to replicate what i achieved on the ubuntu linux box onto the tomato box.
    i figured, a simple pppoecd xyz[...] (syntax/parameters as they read in `ps w`) would do the job, so as the original pppoe-connection command accesses the vlan1 device, i attempted to add a VID7-tag to that device:

    vconfig add vlan1 7

    that created a device called vlan7.
    i tried `pppoecd vlan1.7[...]`, which would be the syntax the debianesque ubuntu uses, but that segfaulted. i'm guessing, tomato doesn't like the notation for the vlan'd interface.

    i afterwards tried `pppoecd vlan7[...]` which spat out no error, but didn't do anything of significance either. it didn't even result in any log output, although i configured tomato to log pppoe messages.

    my guess is now that just firing up pppoecd alone doesn't do the job. maybe i'm also doing something else wrong, i'm at a loss really.

    i'd be happy about any kind of pointer anyone can provide.

  2. bogderpirat

    bogderpirat Network Guru Member

    am i providing too few information, or can actually noone help me? :(
  3. humba

    humba Network Guru Member

    It's interesting that there's a vconfig tool.. as far as I know the only way to do vlans is setting the vlan variables in nvram and then rebooting.

    On my WRT54GL, the WAN port is port number 4.

    # nvram show | grep vlan
    lan_ifnames=vlan0 eth1 eth2 eth3
    vlan0ports=2 1 0 5*
    vlan1ports=3 4 5
    (note that I have lan port 4 on the wan side as well to allow me to connect a second router)
    Right now, that port is in vlan1. I figure if you want to move it you'd have to create vlan7 the tomato way:

    vlan7ports=4t 5

    (and don't forget about the little trick that makes tomato not reset the vlan variables upon startup). Also remove port 4 from vlan1. Now the WAN port should be a tagged member of vlan7 but nothing else.

    However, I have no idea what this will break.. I don't know if Tomato is set up to realize port 4 has been moved or if it will still apply all the rules (e.g. firewall) as if port 4 were in vlan1. Perhaps moving the wan_if* nvram variables to vlan7 will do the trick. If not, do a ps, note what is running in vlan1 and move that over to vlan7 (I see at least udhcpc and upnp refering to vlan1).

    P.S. your way of adding the vlan makes no sense. Think about it.. the WAN side is already a VLAN.. you can't have a VLAN upon a VLAN. When you're using ubuntu (I presume as a router with two NICs) you're adding the vlan to the untagged eth0.. in Tomato you have just one NIC for both LAN and WAN and that changes things.

    P.S.2: If all else fails.. I seem to recall seeing that some people managed to get this working with dd-wrt so you could have a look at how exactly they do it (having a spare routers for experiments always helps.. I have three boxes just in case).
  4. bogderpirat

    bogderpirat Network Guru Member

    hi humba, thanks a lot for your post. i was already starting to think people were ignoring me.

    i didn't know about (or rather didn't remember) the nvram variables concerning vlans. i'm assuming, the vlan-configuration defined in the nvram is implemented at startup using the vconfig utility (is there anything else?). thus, and with the existence of the wan_ifname(s) nvram variables, i'm now a little more confident about being able to keep the standard dialing mechanism of tomato working if i manage to get the tagging business to work.

    okay, now to work. i'm still not quite sure what the standard vlan configuration in tomato exactly does. from what i'm guessing, it's doing two kinds of splitting to the 5port-switch built into the device (i'm using a wrt54gl v1.1 as well, btw):
    vlan0ports=3 2 1 0 5* probably sums up the ports that are used by the "switch-part" of the router, the 5* port i'm assuming is some kind of bridging port, which then lets us connect to the wan interface (port number 4): vlan1ports=4 5

    you'll probably be guessing already that i'm not that fit with vlans. i've been reading through the forum threads here concerning vlan and have also read a couple of wiki articles over at dd-wrt (mostly howtos without too much elaboration).
    i just found this graphic over there, explaining the structure of the wrt54g v4.0, which is supposed to be the very same as the wrt54gls.

    i'm thinking i now understand your two suggested commands.
    vlan7ports=4t 5 will create a vlan7 interface between the internal port and the wan interface, using packet-tagging (?) on the wan port instead of just using VLAN to confine them in one network. this sounds already pretty much like all i need (if i'm assuming correctly :rolleyes:). i'll try that as soon as i get another thing sorted... namely:

    what trick with vlans are you referring to? the router will just forget my nvram settings? tell me, i must know!

    to your PS': yes, dd-wrt knows how to do this - they already have an option built into recent releases of the firmware called "DTAG VLAN tagging", which does exactly what i'm trying to achieve. but dd-wrt is slow, overloaded and as a religious tomato-fanatic, i can't even begin to think about using it productively. also, they wouldn't help me when i asked about it on their forums.
    the ubuntu box i was using was my laptop. as i said, that was just for figuring out how it would work under linux.

    edit: ah, i have now found this document explaining the ports: http://www.dd-wrt.com/wiki/index.php/Switched_Ports#The_Port_Numbering_Explained
    looks like i'm about right in my assumptions...
  5. bogderpirat

    bogderpirat Network Guru Member

    okay, i'm making this a double post, because i've come far. what i've done is:

    nvram set vlan7hwname=et0
    nvram set vlan7ports="4t 5"
    nvram set wan_ifname=vlan7
    nvram set wan_ifnames=vlan7
    nvram commit

    and then rebooted the box. after it was back up, i went back into it via ssh and checked the variables. this showed me what humba outlined in his posting: both wan_ifname and wan_ifnames had been reset. hence, tomato didn't establish the connection itself.
    i then did ifconfig, which showed the vlan7 device to not have been initialized, so i did a

    ifconfig vlan7 up

    and then did a `ps w` to copypasta the pppoecd command. this for me was:

    pppoecd vlan7 -u `nvram get pppoe_username` -p `nvram get pppoe_passwd` -r 1492 -t 1492 -i 0 -I 30 -N 5 -T 5

    note that this will automatically insert username and password set in the webif's pppoe settings from nvram.

    this instantly worked! it set the ip correctly, even the webif displayed it fine. port forwards work, QoS works. i'm not using upnp, but if i can get the wan_ifname(s) variables to stay, i think it'll also work correctly. udhcpc doesn't run on the wan iface, unless you have it configured for DHCP. but since for me this is pppoe, there's no need for taking care of that.

    one thing that i've noticed that doesn't work are passive FTP transfers (server behind the router - client in the interwebs). maybe the ipt_conntrack_* module(s) get(s) the wrong iface? but i'm hoping this will change when the iface variable stays.

    any pointers on that "trick"?

    about humbas suggestion on removing port4 from vlan1: i haven't done that. from what i'm gathering, vlan1 is only brought up when the wan interface is not disabled, and as it has only port4 and the internal port5 as ports, removing port4 from it would make it sorta useless, wouldn't it? but then again i bet it's hardcoded into the firmware and will reappear... hence i just left it as is... and am still hoping that these wan_iface variables will make the applications just circumvent vlan1 completely.
  6. humba

    humba Network Guru Member

    this is also a good document to have bookmarked - it explains a lot of the innner workings and openwrt is rather similar to tomato that way.

    And this is the vlan reset trick I'm refering to. On our model, vlans are reset unless we change that nvram variable.

    By the way, once you have it working could you dump the vlan and wan nvram variables here so that others know how things have to look like.
  7. bogderpirat

    bogderpirat Network Guru Member

    well, as my previous postings explain - i'm only halfway done.
    the connection is working properly, however since tomato is in someway coded to reset the wan_iface(s) variable, it's not managing the right interface by itself. that is to say:
    - ftp conntracking for instance doesn't work correctly
    - the disconnect/connect buttons aren't working properly
    - tomato doesn't use the correct device (vlan7) to initiate the pppoe connection after a reboot.
    these are all because they still try to make a connection via the vlan1 interface. those aforementioned variables probably should take care of that, but they're reset every time i reboot the router. manual_boot_nv=1 doesn't prevent that either.

    i have already begun writing a blog entry (in german, as i'm thinking that kind of configuration is only really interesting to those whose ISPs use VLAN tagging, namely german T-Home subscribers) on the topic, but sure am going to post a summary of the relevant nvram variables as soon as everything works smoothly, which hopefully will be when i figure out how to solve the issue described above.
  8. humba

    humba Network Guru Member

    Hmm... perhaps there's another reset function for the WAN. Back in the day, I asked Jon about the vlan variables reset and he could point out a solution.. so I suggest you contact him and ask if there's a way to make Tomato not reset those variables.

    Alternatively, have you tried changing the variables in the init script? If you go back to the vlan thread I linked to you'll see that I had some success overriding Tomato's resetting of the vlan0ports variable by simply changing them again in the init script. I suppose that would also work for other variables.. and then pppoed would run on the correct vlan since it's only started at the wanup stage and the init script is executed before that.
  9. bogderpirat

    bogderpirat Network Guru Member

    hey mate, thanks for your continued input!

    i have already spoken to jon and he confirmed that this build specifically resets the wan_ifname variable. he also sent me a beta build of 1.24 and described how to override this reset. i'll post a full howto on how to do configure the router once 1.24 is released and if the changes still stick.

    for now, here is a summary of what to do in order to get vlan7 tagging working with pppoe:

    get the nvram variable vlan1ports. it should be either "0 5", that being a wrt54g <rev4 or "4 5", that being a wrt54g >=rev4, a wrt54gl.

    in order to create a VID7-tagged vlan interface, we create these nvram variables:

    nvram set vlan7hwname=et0
    nvram set vlan7ports="4t 5"
    nvram commit

    we should also change the wan_ifname-variable to "vlan7", but with the current firmware, this variable is being reset upon reboot - hence we have to do a couple of things by ourselves.

    after the commit, we reboot the box. then re-log on to ssh. there, we activate the newly created vlan interface:

    ifconfig vlan7 up

    then, we set the wan_ifname control-variable and restart the wan service:

    nvram set wan_ifname=vlan7
    service wan stop
    service wan restart

    note that we're not committing the nvram change, as it gets re-set anyway upon reboot, and the variable gets used properly without commit (until reboot).

    now if all is right, connectivity should be established by now. port forwards should work correctly, as should the conntrack modules (they first didn't for me, but do now). if there is a forced reconnection set in the webif, that will work also. all peachy!
  10. humba

    humba Network Guru Member

    What if you put the following into your init script:

    ifconfig vlan7 up
    nvram set wan_ifname=vlan7

    then reboot the router?
  11. bogderpirat

    bogderpirat Network Guru Member

    i did try that, but to no avail. as i said, littering the scripts section will probably be superfluous once 1.24 is released.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice