[sudo-access] [sudo-discuss] can't reach door computer

Jake jake at spaz.org
Mon Apr 5 21:50:57 PDT 2021


yes the front door computer is accessible and says it's been up for 28 minutes

which is strange because the router that i connected to it through has only
been up for 19 minutes.  anyway it's working.

your email went out to four lists in addition to a couple of people directly.
I feel weird about messages going out to so many lists.

-jake


On Mon, 5 Apr 2021, robb wrote:

> fwiw, building just briefly lost power & 100.64.64.11 is still pingable
> after reboot
>
> On Mon, Mar 15, 2021 at 12:36 PM Jake <jake at spaz.org> wrote:
>
>> mine is not a solution!  just a method of increasing our awareness of the
>> situation.
>>
>> Robb it sounds like your link might be appropriate for our situation after
>> all
>> but I always like to have more information before trying a particular
>> solution.
>>
>> Does anyone know how to turn on logging and direct the logs to the
>> appropriate
>> place?  and cause periodic filesystem flush?
>>
>> On Sun, 14 Mar 2021, robb wrote:
>>
>>> fwiw, the building lost all mains power a day or two ago which may have
>>> caused it to reboot w/o eth. regardless, Jake's solution seems like the
>>> easiest solution
>>>
>>> On Sun, Mar 14, 2021 at 11:45 PM Jake <jake at spaz.org> wrote:
>>>
>>>> So I looked at the bash script Robb found, and it turns out it's
>> specific
>>>> to an
>>>> issue of the Beaglebone booting up without ethernet working in the first
>>>> place.
>>>>
>>>> It does not refer to ethernet stopping working while running!  So that
>>>> implies
>>>> that either our beaglebone is already rebooting but the ethernet doesn't
>>>> come up
>>>> (in which case this script would be wise) OR we're experiencing
>> something
>>>> else
>>>> entirely, and that script wouldn't help us.
>>>>
>>>> I just checked and saw we're running / off of the built-in eMMC chip
>> (4gb)
>>>> and
>>>> I uncommented the line of /etc/fstab that causes the (8gb) microSD card
>> to
>>>> be
>>>> mounted automatically to /mnt/sd_card/  (after fixing the parameters)
>>>>
>>>> So we can do logging to /mnt/sd_card/ and use it for backup purposes and
>>>> logging, because it's a removable microSD card and we don't have to
>> worry
>>>> about
>>>> ruining it.  And we should log there, so that if the ethernet port goes
>>>> down we
>>>> will have a record of why that happened - assuming someone knows how to
>>>> configure it so that cached disk writes are flushed to the disk every
>> few
>>>> minutes so that when we have to power cycle it, the logs are actually
>>>> written
>>>> to disk by then.
>>>>
>>>> -jake
>>>>
>>>> On Sun, 14 Mar 2021, Yardena Cohen wrote:
>>>>
>>>>> I'd prefer a solution that doesn't reboot. We lose the swipe log that
>>>>> way and I have to tell new people to go back and apply again for their
>>>>> cards
>>>>>
>>>>> On Sun, Mar 14, 2021 at 8:22 PM robb <sf99er at gmail.com> wrote:
>>>>>>
>>>>>> looks like a bash script to ping & reboot when necessary may fix it
>>>>
>> https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/
>>>>>>
>>>>>> On Sun, Mar 14, 2021 at 7:36 PM Jake <jake at spaz.org> wrote:
>>>>>>>
>>>>>>> [ removing omni-discuss and adding access control list in addition to
>>>> two other
>>>>>>> "admin" lists i didn't know about ]
>>>>>>>
>>>>>>> this is something that has happened before.  Something about the
>>>> beaglebone
>>>>>>> periodically randomly disables the ethernet port until it gets
>>>> restarted.  We
>>>>>>> have never logged into the beaglebone (through its TTL serial port
>>>> console for
>>>>>>> example) in order to diagnose why, we just power cycle it and it
>> comes
>>>> back up.
>>>>>>>
>>>>>>> would be interesting to save logs to a microSD card (we keep the
>>>> built-in eMMC
>>>>>>> in read-only mode most of the time to prevent wear) so that we could
>>>> get a clue
>>>>>>> as to what's happeneing.  Or perhaps make a process to watch for the
>>>> ethernet
>>>>>>> port being powered down and restart it if that happens for whatever
>>>> reason.
>>>>>>>
>>>>>>> -jake
>>>>>>>
>>>>>>> On Sun, 14 Mar 2021, robb wrote:
>>>>>>>
>>>>>>>> the beaglebone (BB) & switch to BB were sending (green lights on eth
>>>> ports)
>>>>>>>> but the BB wasn't receiving (orange light...) so i rebooted the BB &
>>>> it's
>>>>>>>> pinging now
>>>>>>>>
>>>>>>>> On Sun, Mar 14, 2021 at 6:51 PM Yardena Cohen <yardenack at gmail.com>
>>>> wrote:
>>>>>>>>
>>>>>>>>> Did something happen to the omni door computer? I can't reach it
>> over
>>>>>>>>> the network, even from within the building. It appears to be
>> working,
>>>>>>>>> letting people in. I tried looking at the box, but couldn't make
>>>> sense
>>>>>>>>> of the mess of cables. Maybe an ethernet got disconnected
>> somewhere?
>>>>>>>>>
>>>>>>>>> The rest of the network is fine. Other devices on that subnet and
>>>> that
>>>>>>>>> interface are reachable, but:
>>>>>>>>>
>>>>>>>>> $ ip neigh | grep 100.64.64.11
>>>>>>>>> 100.64.64.11 dev enp3s2  FAILED
>>>>>>>>> _______________________________________________
>>>>>>>>> discuss mailing list
>>>>>>>>> discuss at lists.omnicommons.org
>>>>>>>>> https://omnicommons.org/lists/listinfo/discuss
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>
>>
>


More information about the access mailing list