User Tools

Site Tools


technical_logs:401_richmond

This is an old revision of the document!


A PCRE internal error occured. This might be caused by a faulty plugin

====== April 27, 2011 ====== Ali phoned again today, saying that the POS stopped working soon after I left yesterday. (I had forgotten to disable wifidog on startup.) I already had a new router with me (with a "broken bridge" -- info on how to set that up is now on the router setup instructions page on this wiki), so I popped by and installed it. I had forgotten that Beanfield locks DHCP to the MAC address, so I had to change the MAC address of the WAN interface (instructions below). All working now. ====== April 26, 2011 ====== Ali phoned today, saying that he got a new POS, but that it can't get online. (This is expected; we're still using a MAC-address-based whitelist.) To get it working quickly, I just turned off the wifidog gateway (wdctl stop), but this is only a temporary solution, because now authentication is off for that node. I told him I'd swap in a new router later this week. I need to figure out how to break the bridge so that we can have authentication on the wifi network and none on the Ethernet ports. ====== April 21, 2011 ====== Ali phoned me today, saying that the router is cutting out sometimes, and it knocks out the POS machine. I said I'd come in in the afternoon to take a look. I got there at 4:30 and Ali had already left. The wifi seemed to be working fine. It had rebooted a few times today: 2:22pm, 4:08pm and 4:49pm. (This, according to the wifidog logs on auth. To get this, I did: "grep wifidog-201104.log | grep gw_id=23 | grep uptime | tail 500". But Ali phoned me at noon, and the router hadn't rebooted since at least 9am. Staff said the POS machine had been down since sometime yesterday. I plugged my laptop in the POS Ethernet cable, and it worked fine. So the Ethernet is working fine. No-go with the POS, though. The cable connecting the handheld part to the base part is clearly damaged; it's awkwardly wrapped in electrical tape. When you jostle it in the least bit, the machine beeps. The Ethernet cable plugs into the base. I'm guessing that the wires that enable network access to the handheld part are damaged. The POS machine or the cable need to be replaced. ====== January 10, 2011 ====== They got a new debit machine, and Ali called me 'cause it wasn't working. The ideal solution here would be to keep the ethernet ports open, but I need to figure out how to do that and test it. For now, I just whitelisted the MAC address for the new POS. #debit machine (pre-Jan 2011), debit machine (Jan 2011), Ali's laptop TrustedMACList 00:03:81:be:64:7d,00:0b:4f:1c:ba:73,00:18:de:4b:83:35 ====== September 23, 2010 ====== They got a debit machine which they want to connect to the Internet, and the momentary switch broke, so some changes were in order. I've been a few times in the past week; today I swapped in a new router (the one before flaked out a lot, and was running old versions of OpenWRT and Wifidog), moved the router (it's now on the wall within reach, not on the ceiling), and removed the momentary switch. Everything seems to be working, but when I had to leave the debit machine hadn't received an IP address from the router. I'll go back to check in later today or tomorrow. I whitelisted the debit machine and Ali's laptop. One trick, though... The new router wasn't getting a DHCP address on the Ethernet interface. I plugged my laptop into it, and it too didn't get a DHCP address. I think the Beanfield network is refusing to assign an address to the unrecognized devices. I changed the MAC address on the new router to match the one on the old router. Old vlan1 address on that router (#85): 00:23:69:B3:CE:9D ifconfig vlan1 down ifconfig vlan1 hw ether 00:14:BF:38:FB:C6 ifconfig vlan1 up udhcpc -i vlan1 -r 0.0.0.0 -b -p /var/run/vlan1.pid -R It worked. So then I made the change permanent: nvram set wan_hwaddr=00:14:BF:38:FB:C6 nvram commit ====== June 3, 2009 ====== Cafe was reported down (vmail on June 2, 2009?). Ceiling-mounted router needed a reboot, handy addon made it a two second task. Up and at 'em. ====== June 26, 2007 ====== **Rooftop:** The rooftop router has been reported down for two weeks -- I (Gabe) finally went by to check it out. I connected fine... the problem seems to have been that it wasn't resolving DNS. /etc/resolv.conf listed "nameserver 127.0.0.1" -- which should work, assuming that dnsmasq is running properly. (I didn't *actually* check that before rebooting it.) A reboot fixed it. **Cafe:** This router has been up and down for months -- down for between a few hours and a few days. It had been down again for a couple of hours. I went to the cafe, and there was no wifi signal. I reset the router using the power cutoff switch, and it came right back. (Getting a DHCP address seems to take a little longer than one would expect.) I'll plan to schedule a router swap sometime soon -- this router is flaking out way too much. ====== April 25, 2007 ====== The cafe router flaked out yesterday. Gabe went by today, verified that it was down (ssid wasn't visible in Stumbler), and asked the staff to reset it using the switch -- it came back up. ====== April 19, 2007 ====== Strangely, since around the time we installed the rooftop router, the router in the cafe has started flaking out. Every day or two, it'll go down for a few hours, or a few days. Until now, it's been one of our most stable routers. The tough part is that since it's on the ceiling, it's impossible to powercycle it or anything without getting on a ladder. Getting a ladder into the kitchen is also difficult, and not possible in the afternoon, when the cafe is busy. So I arranged to this morning get the ladder, and brought a spare router to swap in (not wanting to troubleshoot the router while it's on the ceiling). When I arrived, the router in the cafe was working again. Still, I wanted to swap in the new router, just to see. I also created a power cut-off cable. Just a simple cable which plugs in in between the power supply and the router, comes down from the ceiling and has a momentary switch on the end. When the button is pushed (and only while it's pushed), power to the router is cut. It'll allow us to powercycle it from the ground. I swapped in the new router and the cut-off cable. I noticed that the clip on the Ethernet cable was missing. Still, it seemed to sit firmly in the jack. The router started up fine, but wasn't getting an external IP address. I rebooted it, fiddled with the Ethernet cable, and still no luck. I tried plugging the Ethernet cable directly into my laptop, to see if I could get a DHCP address. It didn't work. I swapped the original router back in. It took a while for it to get a DHCP address, too... so maybe I was just too impatient with the new router and my laptop. Or, maybe the network admins have locked that port to that MAC address. The router always gets the same IP address (66.207.208.122). I didn't try assigning the new router that IP address statically, because I hadn't written it down prior to swapping it in. Anyway, we'll see how things go now. ====== April 2, 2007 ====== Gabe and Patrick installed router #62 in the CARFAC office (below the bookshelf, near the door), to cover the rooftop patio. Gabe is working on creating a tunnel between this router and the one in the cafe, so that only one node is listed in wifidog. In the meantime, I did "nvram set wl0_closed=1; nvram commit" since right now it's totally open. ====== old ====== Router installed on cafe ceiling.

technical_logs/401_richmond.1303935072.txt.gz · Last modified: 2013/09/28 16:06 (external edit)