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

wireless multicast

Discussion in 'Tomato Firmware' started by encee, Mar 18, 2013.

  1. encee

    encee Serious Server Member

    I've been using Tomato for many years. It's so rock solid that I almost forgot how to set it up. However, I got a new problem with a new device that connects via WiFi. it is my wifi enabled deadbolt lock that looks for updates every 60 minutes (or whatever time interval i want to set it at). Since the deadbolt lock only runs on batteries, it disconnects and connects as needed. Well, this appears to be the problem. I think it is connecting via multicast as the last few log items indicates such consistently. But I don't know where to start.

    The company I bought this deadbolt lock from has no info on it other than the mac address. That just tells me that their company made it. Do you all have any experience with wifi devices that connect for a brief time, and what the common problem usually is? The good thing is, I'm able to send settings for it, but when it connects it ends up rebooting my router everytime. It's annoying when I'm in the middle of streaming something.
     
  2. xtacydima

    xtacydima LI Guru Member

    I think ti would help if you listed your hardware and firmware versions installed, as well as some idea of what setup you have in your settings... otherwise this is a very general broad overview of a problem
     
  3. encee

    encee Serious Server Member

    Here are my wireless settings

    Afterburner disable

    AP Isolation disable

    Authentication Type auto

    Basic Rate default

    Beacon Interval (range: 1 - 65535; default: 100) 100

    CTS Protection Mode disable

    Distance / ACK Timing meters (range: 0 - 99999; 0 = use default) 0

    DTIM Interval (range: 1 - 255; default: 1) 1

    Fragmentation Threshold (range: 256 - 2346; default: 2346) 2346

    Frame Burst disable

    Maximum Clients (range: 1 - 255; default: 128) 128

    Multicast Rate auto

    Preamble long

    RTS Threshold (range: 0 - 2347; default: 2347) 2347

    Receive Antenna auto

    Transmit Antenna auto

    Transmit Power mW (range: 1 - 251; default: 42) 42

    Transmission Rate auto

    WMM disable
     
  4. seatown

    seatown Serious Server Member

    those settings you just posted are all default, you havent changed 1 thing for crying out loud!
     
  5. Marcel Tunks

    Marcel Tunks Networkin' Nut Member

    It's likely a 802.11b device. Perhaps CTS protection would be helpful.

    Sent from my Nexus S using Tapatalk 2
     
  6. encee

    encee Serious Server Member

    I set the CTS protection to Auto, still not working right. Here is the log

    Apr 3 20:29:53 ? user.info kernel: vlan1: dev_set_allmulti(master, 1)
    Apr 3 20:29:53 ? user.info kernel: vlan1: add 01:00:5e:00:01:3c mcast address to master interface
    Apr 3 20:30:32 ? cron.err crond[87]: time disparity of 22750590 minutes detected

    I have the MAC address for the device.
     
  7. Monk E. Boy

    Monk E. Boy Network Guru Member

    802.11b? Really? What encryption method are you using? A lot of cheap/stupid 802.11b devices (Sony, I'm lookin' at you, and your PSP's 802.11g chipset running in 802.11b mode) can't use WPA2.

    If you're really, really sure it's using multicast (why it's sending/receiving a multicast stream would be an interesting question for the manufacturer) you probably want to adjust Multicast options under Advanced -> Firewall.

    Depending on what Tomato firmware you're running (hint) (hint) there may just be a single "Allow Multicast" checkbox there, or there may be individual settings for IGMPproxy and Udpxy. If you told us whose Tomato firmware you were running we could probably be a lot more helpful.
     
  8. encee

    encee Serious Server Member

    Thanks for your help. I've been so busy with other things that I can't believe how much I forgot about the software. About 4 years ago, I set up my linksys WRT54GL with another WRT54GL using wireless access point mode. I'm wondering if this may be the issue.

    I already did have multicast enabled (the checkbox is checked).

    I have WPA setup. When setting up the wifi device, it connected. It had special instructions to connect to WPA, but mentioned nothing with AES encryption. It works. Status and operations can go to it, but it then seems to cause my router to reboot. It's like it isn't disconnecting properly.

    I'm running Tomato version 1.28

    Tomato Firmware RAF1.28.121006
     
  9. encee

    encee Serious Server Member

    I think I may have found the problem. When I setup the device, I connected to it from my computer's wifi as per the instructions from the wifi device. Well, my computer defaulted to automatically connect to that device when it was available. I removed that connection from my computer. I also removed my wireless network connection from my computer to the router. Didn't need it since I am connected via wired connection. I get the following in my logs. It looks good, hopefully.

    Apr 4 22:49:13 ? daemon.info dnsmasq-dhcp[94]: DHCPDISCOVER(br0) 20:f8:5e:a0:36:03
    Apr 4 22:49:13 ? daemon.info dnsmasq-dhcp[94]: DHCPOFFER(br0) 192.168.1.111 20:f8:5e:a0:36:03
    Apr 4 22:49:13 ? daemon.info dnsmasq-dhcp[94]: DHCPDISCOVER(br0) 20:f8:5e:a0:36:03
    Apr 4 22:49:13 ? daemon.info dnsmasq-dhcp[94]: DHCPOFFER(br0) 192.168.1.111 20:f8:5e:a0:36:03
    Apr 4 22:49:13 ? daemon.info dnsmasq-dhcp[94]: DHCPREQUEST(br0) 192.168.1.111 20:f8:5e:a0:36:03
    Apr 4 22:49:13 ? daemon.info dnsmasq-dhcp[94]: DHCPACK(br0) 192.168.1.111 20:f8:5e:a0:36:03

    The MAC address starting with 20:F8 is the wifi device, and is now setup with the ip address indicated, and is also in the device list..
     
  10. encee

    encee Serious Server Member

    I still have the problem. It's not what I thought it was from post above.

    The manufacturer said it is 802.11b. They don't believe it uses any part of multicast. The router and device connect as you can see above in the post. But, after some time (approx 3 minutes), the disconnecting part causes the router to reboot. I cant catch the log in time to see what happens. Not sure the log would post anything anyway. What I do expect is the wifi device connects for only a few seconds to provide its status and retrieve any requests. Then it disconnects to save on battery life. So total time connected is less than a minute.

    I added the device to the static dhcp. It keeps the address, but does not fix the problem.
     
  11. koitsu

    koitsu Network Guru Member

    I'm not sure what firmware version this is (what is 1.28.121006?!). Can you please make sure you're running the latest Tomato RAF, which is 1.28.9013, then try to reproduce the issue?

    Also, if you could please clarify what the actual issue is, I would appreciate it. Your initial post doesn't do a good job explaining what the actual problem is -- all I can assume, from the way it's phrased, is that your Wifi-enabled (802.11b) deadbolt lock periodically connects to your router via Wifi, and that at some point the device disconnecting (or connecting? You tell me!) causes your router (model completely unknown) to reboot. Is that correct? If not, can you please explain the problem? And can you please explain what evidence you have that the deadbolt lock device is what's causing your router to reboot (vs., say, general wifi interference/noise floor issues that cause the wireless driver in the router to crash/freak out, watchdog kicks in, and reboots the router (this is much more common than you might think)).

    Also: please cease fiddling around with random settings in the Advanced -> Wireless section. It is fairly obvious at this point that you do not understand a lot of the technologies involved (the multicast comment is one such indicator). To troubleshoot an issue, you do not start changing wireless driver settings that you "think" look relevant -- all this does is make troubleshooting impossible because you're "messing around" and those of us here on the forum cannot keep track of all the things you're fiddling with. Calm down, step back, and take things one step at a time.
     
  12. encee

    encee Serious Server Member

    I have a WRT54GL router.
    Version 1.28.121006. I think this is the latest version I can use on this router after checking victek website. I couldn't access my router with telnet, but I doubt I can load the ND versions.

    The deadbolt lock made by Lockstate ( not sure if links are allowed here, but just google Lockstate dead bolt lock, or check on youtube). It's a slick deadbolt lock that you can do lots of things with since it is wifi enabled.

    The deadbolt lock wifi updates every 60 minutes (this time can be changed, but this is what I have it set at. I've tried other times like 20 minutes, and still no difference in the problem). I see the deadbolt lock connect to the router. It is in the device list, and shows up in the log. I know that during this connection that the updates are successful as I have checked that the settings/requests have changed on the deadbolt lock (i.e., I send a request from the webserver page to unlock the deadbolt lock. 60 minutes later the lock unlocks). Now, after a couple of minutes (not sure the exact time) the router reboots.

    Now the requests/updates are coming from LockStates server somehow. In otherwords. I have to login to LockState webserver to change settings on my Deadbolt lock. I cannot change them directly from my home network.

    It's really wierd because its connects, it correctly updates, but for some reason, the disconnecting part is not handshaking right. I really wonder if the LockState dead bolt lock is malfunctioning.
     
  13. encee

    encee Serious Server Member

    these are the last few lines pertaining to the lockstate deadbolt lock. and then the router reboots.

    Apr 6 20:49:20 ? daemon.info dnsmasq-dhcp[521]: DHCPDISCOVER(br0) 20:f8:5e:a0:36:03
    Apr 6 20:49:20 ? daemon.info dnsmasq-dhcp[521]: DHCPOFFER(br0) 192.168.1.111 20:f8:5e:a0:36:03
    Apr 6 20:49:20 ? daemon.info dnsmasq-dhcp[521]: DHCPREQUEST(br0) 192.168.1.111 20:f8:5e:a0:36:03
    Apr 6 20:49:20 ? daemon.info dnsmasq-dhcp[521]: DHCPACK(br0) 192.168.1.111 20:f8:5e:a0:36:03 Lock

    I did notice that turning the CTS Protection mode to "auto" did help the router stay connected for a while longer.
     
  14. koitsu

    koitsu Network Guru Member

    All I'm seeing from that log you provided is this:

    * Device with MAC address 20:f8:5e:a0:36:03 (I'll call this "Lock") requests an IP address via DHCP
    * WRT54GL DHCP server (dnsmasq) responds with an offer of 192.168.1.111 to Lock
    * Lock accepts the DHCP offer (this is what DHCPREQUEST is for)
    * WRT54GL DHCP server responds with an acknowledgement (DHCPACK) indicating the DHCP negotiation is complete

    I see absolutely nothing wrong with this. Nada. None.

    Tomato/TomatoUSB tends to not be chatty with its logs. You can see what logging option you have under Administration -> Events Logged. Not a lot there, I know -- there is a lot under the hood that you can't see, however.

    If you want my opinion, the issue is probably related to a layer 1 (meaning physical layer) or layer 2 issue pertaining to your wireless reliability/connectivity in general -- meaning, the router is probably rebooting due to something that the Lock is doing with 802.11 packets, which tickles a bug in the wireless driver on the WRT54GL, causing it to either a) crash the kernel (kernel panic), or b) lock up the router (which is then auto-rebooted due to hardware watchdog support (I think it has this anyway!)).

    The wireless driver used in almost all consumer routers that TomatoUSB supports is closed-source -- it's a binary blob provided by Broadcom, therefore any bugs/issues cannot be easily fixed because nobody can examine the source, nor can it be debugged (no debugging symbols, etc.). The fact that these devices are embedded units also makes debugging very difficult (no VGA console, no serial console (unless you mod the router), kernel lacks serial console debugger support, etc.).

    Wireless drivers can also get into a state of confusion where they become wedged or lock up -- especially in cases where there is a lot of 802.11 wireless interference surrounding the area. I've personally experienced this (on a different OS (FreeBSD), using an Atheros-based wireless chip), where for a few minutes the driver would work, but then after a few would begin complaining about "stuck beacons" and eventually wedging/locking up, resulting in either a non-working wireless driver state (requiring a reboot), or sometimes a kernel panic. This situation can be caused by wireless interference or even things like shoddy antennas.

    Then there's the issue of encryption or wireless "models" -- e.g. WEP vs. WPA vs. WPA2. Some of these have vendor compatibility issues, others perform badly.

    Welcome to wireless technology -- it's generally crap, I'm sorry to say. This sounds like a crummy excuse/blanket statement, I know, but it's true. I'm not just talking out my ass.

    So, first, I would suggest you talk to Lockstate and find out if there is a firmware update for your lock. There is firmware on that thing, trust me. It may be that a firmware update fixes some weird behaviour in the locks' wireless driver and begins to behave better/differently.

    If a firmware upgrade for your lock doesn't help, then my next recommendation would be to try a newer firmware for your router -- preferably one with a different or newer wireless driver (binary blob). Victek may be able to help tell you which firmware version has such (if any); I only follow Toastman's firmwares. Victek's firmwares are listed here (and this is why I questioned you about the firmware version number): http://victek.is-a-geek.com/tomatoen.html

    If none of this solves the issue, I would recommend purchasing a different router -- the Asus RT-N16 is a good choice -- solely to see if you can work around driver bugs. Try using the stock firmware first and see if the router reboots when using (this would help determine if it's a Tomato/TomatoUSB thing or if its something else).

    I cannot recommend to you that you do a serial port mod + build your own kernel with tons of debugging + verbosity enabled, etc. because the WRT54GL has extremely limited amounts of flash space. This is another reason to consider a newer router.

    P.S. -- Question in passing: a deadbolt lock is usually used for something like locking a door (say the ones to your home). Is that the case here? If so, why on earth would you trust wireless? I'd trust physical wire, not wireless. :) This is purely just me asking a question in general and has no bearing on the technical side of things.
     
  15. encee

    encee Serious Server Member

    Thanks for the advice/help. I hate to have to replace my old WRT54GL, but I may have to. It is so rock solid, and I think it is over 8 years old too. I got Tomato originally for the QOS. Then about 4 years ago, I added another WRT54GL to my home network to extend the range and provide a wired connection point for some devices. I just haven't need to shop/browse for anything better.
     
  16. encee

    encee Serious Server Member

    I took your advice and bought the RT-N16. The deadblock lock wifi works fine now with the new router. I went ahead and went with dd-wrt for the new router and loaded on my other 2 WRT54GL routers. the WRT54GL routers are now repeater bridges. i've got great range and connectivity now!
     

Share This Page