1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Unable to delete guest ssid in latest shibby tomato build5x-092

Discussion in 'Tomato Firmware' started by 838Joel, Apr 17, 2012.

  1. 838Joel

    838Joel Serious Server Member

    I'm using now this version of shibby tomato-usb (build5x-092) on Asus RT-N16.
    Did configure wireless guest ssid (2 of them) because when I created only 1 of them, there was no MAC address on it and could not connect to it.
    Anyway, I created a second one and all went okay then! (mystery to me soo far).
    Now since I configured a VPN, I'm running low in nvram, so I want to delete the second guest ssid, but can not delete it from the GUI…
    How should I delete it? Deleting everything in the nvram related to "wl0.2_*"? Or this would break something?
    If it is a good fix to delete it, what is the nvram delete command?
    Thank for all the help,
  2. teaman

    teaman LI Guru Member

    Did you wait for the network subsystem to restart? Were you using any kind of security/encryption/or-something-else? Did you erase your NVRAM before getting started playing with experimental stuff? I'm sure you did take a backup of your settings before starting, right? ;)

    Oh well... in moment like these... I wonder... why-oh-why I devoted those countless hours into designing a functional-yet-simple interface... not to mention writing those so-called "Notes" sections... containing nothing but... useful or relevant information and warnings meant to be read and understood by a whole lot of people out there trying these new features: yeah - the first-time users :(

    Anyways - those 'Notes' are present in almost/pretty much every single page of the Tomato web UI these days... and still... not a lot of people seem to read that stuff... and/or in some cases... even simply skipping/ignoring what we usually refer to as... 'Release Notes' :(

    Please don't take me wrong here, but we've seen quite a few people reporting some kind of issue as if it was some sort of 'real problem' when in fact... it could/would be just some sort of well known limitation and in some cases even... 'the' expected behavior -;)

    With that being said, please allow me to copy/paste the current/latest version of those 'Notes' on the Advanced: Virtual Wireless Interfaces page:

    Notes (Click here to hide)
    • Interface - Wireless VIF name.
    • Enabled - If this VIF should be active and brought online.
    • SSID - Wireless Service Set Identifier.
    • Mode - Interface mode: Access Point, WDS, Wireless Client, etc...
    • Bridge - Which LAN bridge this VIF should be assigned.
    • Other relevant notes/hints:
      • Once created/defined, a wireless VIF cannot de deleted: it can only be disabled.
      • When creating/defining a new wireless VIF, it's MAC address will be shown (incorrectly) as '00:00:00:00:00:00', as it's unknown at that moment (until network is restarted and this page is reloaded).
      • When saving changes, the MAC addresses of all defined non-primary wireless VIFs could sometimes be (already) set but might be recreated by the WL driver (so that previously defined/saved settings might need to be updated/changed accordingly on Advanced/MAC Address after saving settings and rebooting your router).
      • This web interface allows configuring a maximum of 4 VIFs for each physical wireless interface available - up to 3 extra VIFs can be defined in addition to the primary VIF (on devices with multiple VIF capabilities).
      • By definition, configuration settings for the primary VIF of any physical wireless interfaces shouldn't be touched here (use the Basic/Network page instead).
      • This is highly experimental and hasn't been tested in anything but a WRT54GL v1.1 running a Teaman-ND K24 build and a Cisco/Linksys E3000 running a Teaman-RT K26 build.
      • There's lots of things that could go wrong, please do think about what you're doing and take a backup before hitting the 'Save' button on this page!
      • You've been warned!

    You see - there are three distinct groups of notes in there:
    • the first one mentions a few words about the 'Overview' table/grid, with basic information.
    • the second group mentions quite a few interesting things, and I strongly advise that anyone that might be thinking about fiddling/messing with the 'Save' button on this page should understand the full extents/risks of any possible implications and/or some unexpected/weird interaction with some other subsystem on your router...
    • last but not least, there's the third group of notes: this can brick your router. I've done that myself. More than once. You've been warned - period!
    Did you had any MAC addresses for WL VIFs already defined? Did you get a chance to restart/reboot your router in-between any of those moments? Did you try checking these wiki pages?

    Right - I'm sure you did take that backup before starting, right? ;)

    Recommended way: export NVRAM to a txt file on your computer, reset your router to 'factory' settings (that is, defaults from Shibby's build), then reconfigure the whole thing by hand (do NOT restore the backup file).
    Pros: you'll be able to review the whole thing with your settings and just restore/reconfigure what you'll be actually using/requiring.
    Cons: none.

    Lazy/risky way: try to get rid of everything wlX.Y*-related on NVRAM, cross your fingers and pray.
    Pros: you might not have to configure the whole thing from scratch.
    Cons: there is a chance you might miss something and leave something behind (needless to say, such thing could eventually lead to some/any/all sorts of unforeseen, strange and/or inexplicable problems in the future).

    Well... if you're willing to hang yourself, I suppose I could even help and give you some rope ;)

    This command will help/show you which variables you're interested:
    nvram show | grep wlX.Y
    Then, you could just execute:
    nvram unset varname1
    nvram unset varname2
    nvram commit
    The caveat is... some of those variables might be actually required for the router to boot... so you don't wanna unset those! Now, the really funny part: those are not very well known and can be easily mistaken/wiped out :(

    Still - here's something you might want to try at your own risk:
    for i in `nvram show | grep ^wlX.Y | cut -f1 -d\=` ; do echo "nvram unset $i" ; done
    This should take care of all nvram vars 'starting' with wlX.Y. Then, we want to know which variables mention our wlX.Y but their name does not begin with that:
    nvram show | grep wl0.1 | grep -v ^wl0.1
    Once your're done with your 'nvram set var="value"' thingies, you should be ready to just commit NVRAM, reboot, cross your fingers and start praying your router comes back ;)
    nvram commit
    Best of luck - cheers!
  3. Dark_Shadow

    Dark_Shadow Addicted to LI Member

    Are there any plans of making the delete button functional? Not that I want to delete my guest wifi.
  4. teaman

    teaman LI Guru Member

    Plans? Yeah, sure... but those functions are somewhat low-priority at this moment - mainly, for two reasons:
    • a 'standard' WL VIF 'costs' around 500~600 bytes of NVRAM (YMMV).
    • when a WL VIF is set to 'disabled' on advanced-wlanvifs.asp, it has the very same effect as if it wasn't even defined in the first place: negligible (i.e. pretty much the very same as "doesn' exist" or "not defined at all" - this approach was chosen to make it easier to eventually/possibly allow enabling/disabling guest WL VIFs via the "Access Restriction" menu items).
    So - yes: there are plans (but don't hold your breath, really).
  5. Dark_Shadow

    Dark_Shadow Addicted to LI Member

    No problem, Makes sense. Thanks for the explanation.
  6. shibby20

    shibby20 Network Guru Member

    Teaman about our conversation and my problem, here is few information:


    1) basic -> network
    2) advanced ->VLAN
    3) advanced -> Virtual wireless overview
    4) advancer -> virtual wireless wl0.1
    5) status -> overview

    Result: groov_guest is visible by netbook and mobile phone but i can`t connect to this network. I can connect to groov_shibby without problem. Null info in syslog.

    NVRAM settings:
    Thank you for your help.
    Best Regards!
  7. Riddlah

    Riddlah Networkin' Nut Member


    The setup you have looks similar to what I tested on your builds and Toastman's. The only difference between them, I had to remove Port 4 (don't think it matters which port is used) from VID1. I set up VID3 with Port 4 and set the Bridge to LAN1 (br1). Once I did this, I was able to connect to the virtual interface after a restart (there was an odd instance I had to wait an hour or so before it came up).
  8. 838Joel

    838Joel Serious Server Member

    Well thank you for the detailled reply, I really appreciate it...

    But let me make it shorter here ;)

    Most of the time, Yes I do read the notes, but I may read quickly and catch 75% of it... I should read more of it, but I did get most of them...

    I did not read that http://code.google.com/p/tomato-sdhc-vlan/wiki/ExperimentalMultiSSID, and yes there is useful info there to read.. thank's for that...

    Another thing I may have done wrong in the first place... I came from DD-WRT and did flash Shibby build92 with the option to erase the nvram.
    What I did not done before configuring is to set by default nvram from the shibby firmware... So this might give some trouble later...

    Therefore, I do have backups (Has I make backups at every step of configuration...) but this backup is useless now!

    So, I'll go with the good way and start all over (After I noted all the step first ;) and I will make sure to set by default from shibby interface first!)

    A quick question before I restart all over... Has mentionned into http://code.google.com/p/tomato-sdhc-vlan/wiki/ExperimentalMultiSSID, is the part of removing port4 from VID1 to associate it to VID3 is necessary? Can I leave VID3 without any port? As I don't need to connect a physical port to this VID! Or this is mandatory.

    Thank again for help,
  9. 838Joel

    838Joel Serious Server Member

    Opps! Another question... How do I EXPORT the config in a readable text file?
  10. kthaddock

    kthaddock Network Guru Member

  11. 838Joel

    838Joel Serious Server Member

  12. teaman

    teaman LI Guru Member

    Cool! Glad we're on the same page ;)

    Yeah... I must admit those 'notes' sometimes don't tell the whole story... but often can be useful to understand and/or figure out why some of the 'rules' and/or 'restrictions' on that web UI/page are in place (and/or even give some hints about where we should start looking for problems when/if something doesn't work quite as expected...).

    Is assigning a physical port to your new/guest LAN bridge mandatory? Yes and no. That step is in there mostly for a few reasons:
    • It's a simple way of checking if your new/guest LAN bridge is properly isolated from your 'primary' LAN as well as easily checking if your DHCP settings are working as expected on each of them
    • Since we do have at least one physical port assigned to it, we ensure all the 'underlying' interfaces are brought 'up' when network subsystems are initialized (i.e. the 'primary LAN'/br0 usually has at least two members: a vlanX part and a wlX part - and we want to ensure all of these are configured in a 'proper' way at runtime)
    Therefore, while not strictly 'mandatory', it might be highly advisable to have it (specially since you can always assign that port 'back' to your original/primary LAN once you're done setting up and/or troubleshooting).

    One last/long note: due to recent findings, I've been working on trying to improve this whole experience (from the 'user' perspective) and it should be said I'm about 20~30 commits ahead/behind this current WL VIFs webUI :/ Here's the thing: when you hit the 'Save' button on this/current version, there's three distinct stages: first, we need to parse/populate/sync a few runtime/helper/state variables with what we have on our 'form' being posted (i.e. do we have any wlX.Y VIFs defined? Security? Assignments to bridges?). Next, we do some quite-ugly/lower-level-hacking and execute some raw-and-simply-dangerous 'nvram set' commands in order to 'fake' the existence of our (soon-to-be-created) virtual wireless interfaces and finally, we can post the whole thing just like any other page in the Tomato admin web UI. Needless to say - this second stage needs to be rewritten/improved - but that was the quickest/simplest solution I could think at that moment (until we had a chance to better understand this whole process - keep reading).

    The main differences on this (new) version are actually in how this second stage handles variables that might be already set, like 'wlX.X_hwaddr', which can play a major role when/if we expect any kind of encryption to be functional. Documentation on this is very sparse, but I eventually discovered that when any/some of those variables are unset, but seem to be 'needed' either by the closed-source Broadcom WL module or the open-source wlconf.c, these might be created/set by any of them at runtime (i.e. it seemed possibly quite tricky to 'effectively delete' a WL VIF once defined, but it was feasible to allow users to 'safely disable' those later on via webUI).

    To make things a bit worse, the Broadcom WL module and code on wlconf.c don't seem to always 'agree' on some of the values each would choose for some of those NVRAM vars, which seems to be the case of the MAC addresses for our virtual/guest wireless interfaces and (in some situations) their BSSIDs (i.e.'wlX.X_hwaddr' et al).

    With that in mind, the current/new (soon to be released) version of the WL VIFs webUI doesn't try to unset/reset/mess with any possible discrepancies between any HWaddr/BSSIDs pairs (we leave that job to the Advanced: MAC Address page as it always should have been). Instead, it just shows a warning to the user when/if there's any discrepancies between the current/saved HWaddress being used by some of your wireless interfaces on the OS side and... the BSSID/HWaddress expected/that should be used since the WL driver decided to do so and ignore some of the values/settings we told it to use ;)

  13. teaman

    teaman LI Guru Member

    @shibby20 - here's a hint - the HW address on those three should be a match:
    ifconfig wl0.1
    wl -i wl0.1 bssid
    nvram get wl0.1_hwaddr
    Also, watching the Status: Device List page while trying to associate/join this new/guest WLAN interface while having this set in Custom Configuration on Advanced: DHCP/DNS could be helpful:
    Best of luck!
  14. shibby20

    shibby20 Network Guru Member

    i make new wl0.2 and this is what i have:
    ifconfig wl0.2
    wl0.2 Link encap:Ethernet HWaddr E2:CB:4E:56:9F:A1
    RX packets:10 errors:0 dropped:0 overruns:0 frame:44169
    TX packets:399 errors:1 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:984 (984.0 B) TX bytes:69457 (67.8 KiB)
    wl -i wl0.2 bssid

    nvram get wl0.2_hwaddr
    Why result from 2nd and 3rd command return different MACs??

    I cant change MAC for wl0.2 from advanced -> MAC

    if i use nvram set to force MAC i haven`t wl0.2 on overview page.

    when i go to advanced -> virtual wireless and press save, then MAC for wl0.2 is changing to E2:CB:4E:56:9F:A1.

    I cleared NVRAM and define only new virtual vireless (bridged to br0). I still can`t connect to guest ssid :/ This is problem only on my rtn16. On rt-n15u and rtn-66u all works great. I this this is problem with MAC adresses.
  15. shibby20

    shibby20 Network Guru Member

    i delete wl0.1 and wl0.2 and make wl0.1 one more time. MAC`s was still diffent well i force new mac using nvram set command. Now i have:
    ifconfig wl0.1
    wl -i wl0.1 bssid
    nvram get wl0.1_hwaddr

    wl0.1 Link encap:Ethernet HWaddr E2:CB:4E:56:9F:B0
    RX packets:16 errors:0 dropped:0 overruns:0 frame:5780
    TX packets:72 errors:4 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:1855 (1.8 KiB) TX bytes:13084 (12.7 KiB)

    but still cant connect to new ssid. Log of dnsmasq is clear.
  16. teaman

    teaman LI Guru Member

    There's a new version coming up over the next few days... stay tuned ;)
  17. 838Joel

    838Joel Serious Server Member

    Thank you for all the explanation, and I'm looking forward to the next version (Which I will be able to upgrade without redoing my config).
    But just to let you know, after reset the firmware with default config I was able to reconfigured it as I wanted... I was following a little about this page : http://code.google.com/p/tomato-sdhc-vlan/wiki/ExperimentalMultiSSID, but did everything from the GUI... Probably not following exactly the same step by step, but most of it and it did workout good for me!
  18. 838Joel

    838Joel Serious Server Member

    Since the last time... Is there an ETA for the new version?
  19. Elfew

    Elfew Addicted to LI Member

    Yeah some info?
  20. teaman

    teaman LI Guru Member

    838Joel, Elfew:

    WOW! It's been almost 6 weeks since my last post on this thread! WOW, indeed!
    (sorry about that!)

    There /is/ a new version coming up, for sure! Bad news is: it's still/currently on my local git repo. Good news is: this version does check (and throws warnings about) any disagreements between some of the configured and/or runtime values of a few settings here and there (such as... the MAC/HW address being used/expected by the WL subsystem).

    Those sources /will/ be released. Soon.

  21. Elfew

    Elfew Addicted to LI Member

    OK, thank you Teaman! I am looking forward for it ;)
  22. Elfew

    Elfew Addicted to LI Member

    Any news Teaman? :)))

Share This Page