ROBIN -  Open Source Mesh Network Forum Index ROBIN - Open Source Mesh Network
users community forum
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

t_c738.n Gateway dies every day

 
Post new topic   Reply to topic    ROBIN - Open Source Mesh Network Forum Index -> c7xx
View previous topic :: View next topic  
Author Message
Ads






Posted: Sun Apr 23, 2017 8:54 am    Post subject: Ads

Back to top
jaebird
Intermediate User
Intermediate User


Joined: 05 Apr 2008
Posts: 59
Location: DFW, Texas

PostPosted: Mon Jun 02, 2008 10:52 pm    Post subject: t_c738.n Gateway dies every day Reply with quote

It seems my Robin gateway is dying every day now. Is anyone seeing this? not sure what to check. It started doing this with updates starting with t_c7***.

If I reboot it works for awhile again. I cannot SSH into it from LAN when dead [EDIT: this may or may not be true actually], as if the unit is locking up or something. The repeater node is working fine and continuously reboots until the gateway comes back up.

Any pointers?

Jae


Last edited by jaebird on Tue Jun 03, 2008 2:45 pm; edited 1 time in total
Back to top
View user's profile Send private message
jaebird
Intermediate User
Intermediate User


Joined: 05 Apr 2008
Posts: 59
Location: DFW, Texas

PostPosted: Tue Jun 03, 2008 2:44 pm    Post subject: Reply with quote

I'm going to do some tests with it. I've put it on a static lease and will attempt to login if this issue occurs again.

Antonio (or anybody): Is there a good place to look on the device assuming dropbear is still running when it happens. Or I could place some sort of debug script, or utilize the watchout4node to get the last state upon forced reboot (ie pulling power)

I may flash another unit and replace this one...it could be heat related I suppose.

Cheers,

Jae
Back to top
View user's profile Send private message
bgottlieb
User
User


Joined: 17 May 2008
Posts: 1

PostPosted: Tue Jun 03, 2008 4:43 pm    Post subject: Reply with quote

Jae,

I saw this with earlier code when I had accidentally had my gateway plugged into a 10M hub. Once I moved it to a 10/100M switch, the problem cleared.

Just my $0.02.

-bill
Back to top
View user's profile Send private message
Antonio (isleman)
Site Admin
Site Admin


Joined: 10 Feb 2008
Posts: 2323
Location: Toscana, Italy

PostPosted: Tue Jun 03, 2008 6:02 pm    Post subject: Reply with quote

Hi Jae

jaebird wrote:
I'm going to do some tests with it. I've put it on a static lease and will attempt to login if this issue occurs again.


you ran a gateway on a dynamic lease ? I don't understand, sorry.

Above the reasons of reboots run the command:

cat /etc/reboot_reasons

and look at the codes... and post here that file.

A
Back to top
View user's profile Send private message Send e-mail Visit poster's website
jaebird
Intermediate User
Intermediate User


Joined: 05 Apr 2008
Posts: 59
Location: DFW, Texas

PostPosted: Tue Jun 03, 2008 7:05 pm    Post subject: Reply with quote

The gateway was receiving an IP address from the dhcp server on the lan "dynamically" so I wasn't always sure what it was (made it a little hard to ssh in!) I now have it assigned a static lease from the dhcp server so I'll be able to ssh in to a known ip address.

There is no /etc/reboot_reason file on it...there is a returned_reason file with "0"

Does it seem like bad hardware? As of this writing it has been running for over 4 hours.

Jae
Back to top
View user's profile Send private message
Antonio (isleman)
Site Admin
Site Admin


Joined: 10 Feb 2008
Posts: 2323
Location: Toscana, Italy

PostPosted: Tue Jun 03, 2008 9:43 pm    Post subject: Reply with quote

Jae,

maybe dynamic lease deallocate gateways... let's wait for some hours.
Thanks
Back to top
View user's profile Send private message Send e-mail Visit poster's website
johu
User
User


Joined: 06 May 2008
Posts: 27

PostPosted: Tue Jun 03, 2008 11:07 pm    Post subject: Reply with quote

Antonio (isleman) wrote:
maybe dynamic lease deallocate gateways... let's wait for some hours.


I think my problems are due DHCP issues as well. My ISP issues very short DHCP leases.

Here's /etc/reboot_reasons
Code:
root@AP8:/# cat /etc/reboot_reasons
Sat Jan 1 00:14:07 UTC 2000 - reason: 202
Sat Jan 1 02:06:48 UTC 2000 - reason: 204
Sat Jan 1 00:49:49 UTC 2000 - reason: 204
Sat Jan 1 00:35:02 UTC 2000 - reason: 204
Sat Jan 1 00:35:00 UTC 2000 - reason: 204
Sat Jan 1 00:35:00 UTC 2000 - reason: 204
Sat Jan 1 00:34:56 UTC 2000 - reason: 204
Sat Jan 1 00:34:58 UTC 2000 - reason: 204
Sat Jan 1 00:35:00 UTC 2000 - reason: 204
Sat Jan 1 00:35:00 UTC 2000 - reason: 204
Sat Jan 1 00:35:14 UTC 2000 - reason: 204
Sat Jan 1 00:35:01 UTC 2000 - reason: 204
Sat Jan 1 00:35:08 UTC 2000 - reason: 204
Sat Jan 1 00:34:57 UTC 2000 - reason: 204
Sat Jan 1 00:35:01 UTC 2000 - reason: 204
Sat Jan 1 00:35:05 UTC 2000 - reason: 204
Sat Jan 1 00:35:01 UTC 2000 - reason: 204
Sat Jan 1 00:34:59 UTC 2000 - reason: 204
Sat Jan 1 00:35:04 UTC 2000 - reason: 204
Sat Jan 1 00:35:03 UTC 2000 - reason: 204
Sat Jan 1 00:35:04 UTC 2000 - reason: 204
Sat Jan 1 02:07:40 UTC 2000 - reason: 204
Sat Jan 1 00:35:03 UTC 2000 - reason: 204
Sat Jan 1 00:35:13 UTC 2000 - reason: 204
Sat Jan 1 00:35:05 UTC 2000 - reason: 204
Sat Jan 1 00:35:05 UTC 2000 - reason: 204
Sat Jan 1 00:35:06 UTC 2000 - reason: 204
Sat Jan 1 00:35:05 UTC 2000 - reason: 204
Sat Jan 1 00:35:12 UTC 2000 - reason: 204
Sat Jan 1 00:35:18 UTC 2000 - reason: 204
Sat Jan 1 00:35:06 UTC 2000 - reason: 204
Sat Jan 1 00:35:00 UTC 2000 - reason: 204
Sat Jan 1 00:35:06 UTC 2000 - reason: 204
Sat Jan 1 00:34:57 UTC 2000 - reason: 204
Sat Jan 1 00:35:00 UTC 2000 - reason: 204
Sat Jan 1 00:34:55 UTC 2000 - reason: 204


There's no udhcpc process running on my gateways. Is this normal situation? There's "-q" flag passed to udhcpc on /etc/init.d/S22dhcp-discover forcing it to exit after DHCP lease is successfully received. Shouldn't it be forked to background as now nothing is renewing lease thus ISP blocks traffic causing gateway to restart due loss of connectivity?

Is there some hack hidden in scripts called from crontab or watchout4node that's supposed to take care of DHCP lease renewals? I tried to look for one without success.

I launched DHCP client with "udhcpc -i eth0 -n -s /usr/share/udhcpc/robin.script" and left it running on background. We'll see on morning if it helped and fixed rebooting issue.

Code:

root@AP8:/etc/rc.d# ps
  PID  Uid     VmSize Stat Command
    1 root        408 S   init
    2 root            SWN [ksoftirqd/0]
    3 root            SW< [events/0]
    4 root            SW< [khelper]
    5 root            SW< [kthread]
   17 root            SW< [kblockd/0]
   28 root            SW  [pdflush]
   29 root            SW  [pdflush]
   30 root            SW< [kswapd0]
   31 root            SW< [aio/0]
   41 root            SW  [mtdblockd]
  150 root            SWN [jffs2_gcd_mtd1]
  254 root        416 S   logger -s -p 6 -t
  256 root        488 S   /bin/sh /sbin/watchout4node
  257 root        588 S   /bin/ash --login
  267 root        348 S   syslogd -C16
  272 root        288 S   klogd
  284 root        268 S   /sbin/hotplug2 --override --persistent --max-children
 2269 root        608 S   hostapd -B /var/run/hostapd-ath1.conf
 2366 root        608 S   hostapd -B /var/run/hostapd-ath2.conf
 2370 root        308 S   /usr/sbin/dropbear -p 22
 2514 root        440 S   /usr/sbin/batmand -o 1500 -g 5000 --hop-penalty 30 -a
 2515 root        440 S   /usr/sbin/batmand -o 1500 -g 5000 --hop-penalty 30 -a
 2516 root        440 S   /usr/sbin/batmand -o 1500 -g 5000 --hop-penalty 30 -a
 2517 root        440 S   /usr/sbin/batmand -o 1500 -g 5000 --hop-penalty 30 -a
 2561 root        144 S   duende /usr/sbin/maradns
 2562 nobody      584 S   /usr/sbin/maradns
 2563 66          216 S   duende /usr/sbin/maradns
 2576 nobody      368 S   /usr/sbin/dnsmasq -C /etc/dnsmasq.ap.conf --bind-inte
 2583 nobody      368 S   /usr/sbin/dnsmasq -C /etc/dnsmasq.Myap.conf --bind-in
 2596 root        392 S   crond -c /etc/crontabs
 2650 root        436 S   /usr/bin/nodogsplash
 2940 root        436 S   /usr/bin/nodogsplash
 2941 root        436 S   /usr/bin/nodogsplash
 2942 root        436 S   /usr/bin/nodogsplash
 4016 nobody      584 S   /usr/sbin/maradns
 7132 root        300 S   sleep 180
 7137 root        392 R   ps


I also receive messages like this on console port
Code:
sh: packets: unknown operand
Uptime: 0d 0h 12m 13s


Timestamps on log are bit useless as is. Do I need to manually enable ntp (or rdate as it seems) or is lack of clock sync due some error? I'm running t_c738.
Back to top
View user's profile Send private message
johu
User
User


Joined: 06 May 2008
Posts: 27

PostPosted: Wed Jun 04, 2008 6:27 am    Post subject: Reply with quote

DHCP lease renews are working now after I started udhcpc manually and gateway no longer rebooting itself. Now if I'd just figure out how to break out from "logread -f" running on serial port console without power-cycling device. Smile Seems some tty settings are not configured on Robin firmware and thus ^C is disabled. Guess I need to ssh in over WLAN and kill process that way - or power cycle.
Back to top
View user's profile Send private message
Antonio (isleman)
Site Admin
Site Admin


Joined: 10 Feb 2008
Posts: 2323
Location: Toscana, Italy

PostPosted: Wed Jun 04, 2008 7:35 am    Post subject: Reply with quote

Hi

-q flag will be removed from the udhcpc start command: thanks for this tips, it was a my lack.

About syncing nodes using rdate... I've done many thoughts about this issue, it is simple to implement (just two lines in /etc/init.d/nodeclean) but in this way we'll have all nodes that try to gain inet connection for update at the same time (and this may cause problems) while in the current way (no sync) inet requests are quite spread along a 5 minute window.

A solution could be the add of a random offset:
Code:

offset () {
#     set random offset      
   currenttime=$(date)
   hour=$(date '+%H')
   realminute=$(date '+%M')
   randomminute=$((0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % 5))
   adjustedminute=$(($realminute + $randomminute))
   seconds=$((0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % 60))
   date -s $hour:$adjustedminute:$seconds      
}

rdate -s $ntpd_srv
wait
offset


such as in the case of chilli (look at /etc/init.d/timing).

Wait for users proposals in order to understand if I have to insert this in every node, your thoughts?

A
Back to top
View user's profile Send private message Send e-mail Visit poster's website
johu
User
User


Joined: 06 May 2008
Posts: 27

PostPosted: Wed Jun 04, 2008 8:35 am    Post subject: Reply with quote

Easy fix would be adding random delay to beginning of update script, but I don't think delay value can be generated randomly on each time update script is executed as that would result unpredictable timing between update cycles. Either generating per-device delay value and storing it on flash or per-restart delay value stored under /tmp should do it.

However I would implement it slightly different myself. Instead of adding delays to beginning of scripts called via crontab do timing using cron itself. Currently it's "0-59/5 * * * * /sbin/update" on all nodes. Replacing "0-59/5" with "1-59/5" to "4-59/5" would spread load over five minutes. There would still be issue of large number of nodes connecting at x:x:01s and none connecting at x:x:59s. That could be solved by adding device specific 0-59s sleep to crontab itself.

"0-59/5 * * * * /bin/sleep 5 ; /sbin/update" on first node would connect at x:00:05 to x:55:05 and
"3-59/5 * * * * /bin/sleep 21 ; /sbin/update" on second would connect at x:03:21 to x:58:21 etc.

Also why we're using rdate and not ntpdate? Many if not most time servers have already dropped rdate support. Also using pool of time servers instead of only tick.greyware.com would be better idea. Running full ntpd is probably waste of resources so once or twice a day ran ntpdate using 0.openwrt.pool.ntp.org to 3.openwrt.pool.ntp.org as source would spread timeserver load nicely and keep clocks close enough of actual time. Same issues with flood of concurrent connections as with update script apply to this as well.
Back to top
View user's profile Send private message
Antonio (isleman)
Site Admin
Site Admin


Joined: 10 Feb 2008
Posts: 2323
Location: Toscana, Italy

PostPosted: Wed Jun 04, 2008 8:59 am    Post subject: Reply with quote

I think you have the right skill to implement some elegant solution.
I didn't spent so much time on sync and on checkin flood items but your ideas are quite interesting and certainly they deserve attention such as the load that dahsboard server can sustain (and our router too...)

So, I'm waiting for some tested fix oriented to improve sync & load and I'll be happy to merge it in the firmware.

Let me know
Back to top
View user's profile Send private message Send e-mail Visit poster's website
johu
User
User


Joined: 06 May 2008
Posts: 27

PostPosted: Wed Jun 04, 2008 3:25 pm    Post subject: Reply with quote

Perhaps not so elegant, but here's something for audience to comment. This also implements service window to prevent firmware upgrade related restarts during business hours. Would be plus if service window could be configured thru Dashboard.
Code:
--- nodeclean.t_c738    2008-06-04 16:04:26.000000000 +0300
+++ nodeclean   2008-06-04 17:06:56.000000000 +0300
@@ -24,20 +24,18 @@
 RESOLV_CONF="/etc/resolv.conf"
 
 sched_a () {
-# echo "$m * * * * /sbin/upgrade"
 (     
-               echo "0-59/5 * * * * /sbin/update"
-               echo "22 * * * * /sbin/upgrade"
+               echo "$updaterunminute-59/5 * * * * ( /bin/sleep $nodedelaysecond ; /sbin/update )"
+               echo "$upgraderunminute $upgraderunhour * * $upgraderunday ( /bin/sleep $nodedelaysecond ; /sbin/upgrade )"
                ) | crontab - 2>&-     
 }
 
 
 sched_b () {
-# echo "$m * * * * /sbin/upgrade"
 (
-               echo "0-59/5 * * * * /sbin/update"
-               echo "22 * * * * /sbin/upgrade"
-               echo "28,56 * * * * /sbin/iwag"
+               echo "$updaterunminute-59/5 * * * * ( /bin/sleep $nodedelaysecond ; /sbin/update )"
+               echo "$upgraderunminute $upgraderunhour * * $upgraderunday ( /bin/sleep $nodedelaysecond ; /sbin/upgrade )"
+               echo "$iwagrunminute/2 * * * * ( /bin/sleep $nodedelaysecond ; /sbin/iwag )"
                ) | crontab - 2>&-
 }
 
@@ -135,12 +133,54 @@
        echo "nameserver 127.0.0.1" >> $RESOLV_CONF
       
 ##### setup cron daemon
-# m=$(expr $(head -c2 /dev/urandom | hexdump -d | awk '$2 > 0 {print $2}') % 60)
-case $(uci get flags.status.iwag) in
-###    FIXME
+
+       # Firmware upgrades are performed at random time within maintenance window
+
+       # Default maintenance window is 01:00 to 03:00 UTC Saturday to Sunday
+       # To change maintenance window 12:00-18:00 UTC Wednesday-Saturday type
+       #   uci set general.maintenance=general
+       #   uci set general.maintenance.hourstart="12"
+       #   uci set general.maintenance.hourstop="18"
+       #   uci set general.maintenance.daymask="4-6"
+       #   uci commit general
+
+       # Get maintenance window from config file
+       maintstarthour=$(uci get general.maintenance.hourstart)
+       maintstophour=$(uci get general.maintenance.hourstop)
+       maintdaymask=$(uci get general.maintenance.daymask)
+
+       # Use defaults if not configured
+       [ $maintstarthour ] || maintstarthour=1 maintstophour=3
+       [ $maintstophour ]  || maintstarthour=1 maintstophour=3
+       [ $maintdaymask  ]  || maintdaymask="0,6"
+
+       # Day within maintenance window to perform upgrade
+       upgraderunday=$maintdaymask
+
+       # Hour within maintenance window to perform upgrade
+       if [ $maintstarthour -ne $maintstophour ]; then
+               upgraderunhour=$(($maintstarthour+(0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % (($maintstophour-$maintstarthour+1)))))
+       else
+               upgraderunhour=$maintstarthour
+       fi     
+
+       # Minute within maintenance window to perform upgrade
+       upgraderunminute=$((0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % 60))
+
+       # Minute to perform update. Repeated every 5 minutes
+       updaterunminute=$((0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % 5))
+
+       # Minute to perform IWAG check. Repeated every 30 minutes.
+       iwagrunminute=$((0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % 30))
+
+       # Second value is used for all jobs launched via cron. There's no point generating different value for every task.
+       nodedelaysecond=$((0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % 60))
+
+       case $(uci get flags.status.iwag) in
+       ###     FIXME
                0) sched_a ;;
                *) sched_a ;;
-esac   
+       esac   
 }             
 #
   


With above changes my /etc/crontab/root looks like this. Bolded values are generated per node to protect Dashboard against flood and to force off-hours firmware upgrades.
2-59/5 * * * * ( /bin/sleep 43 ; /sbin/update )
36 3 * * 4-6 ( /bin/sleep 43 ; /sbin/upgrade )


Bit from logfile. Cron launched update at 14:07:01 but due additional sleep command actual update process was delayed until 14:07:44.
Code:
Jun  4 14:07:01 AP8 cron.notice crond[2598]: USER root pid 14622 cmd ( /bin/sleep 43 ; /sbin/update )
Jun  4 14:08:03 AP8 user.notice update: main server succesfully updated
Jun  4 14:08:04 AP8 user.notice update: no settings file received
Jun  4 14:12:01 AP8 cron.notice crond[2598]: USER root pid 15806 cmd ( /bin/sleep 43 ; /sbin/update )
Jun  4 14:13:03 AP8 user.notice update: main server succesfully updated
Jun  4 14:13:04 AP8 user.notice update: no settings file received


I think there should be also some way to bring firmware of new nodes and nodes that have been long offline up-to-date immediately. Implementing service window approach like I did above would delay firmware upgrade of new node flashed on Monday until Saturday.
Back to top
View user's profile Send private message
Antonio (isleman)
Site Admin
Site Admin


Joined: 10 Feb 2008
Posts: 2323
Location: Toscana, Italy

PostPosted: Wed Jun 04, 2008 6:35 pm    Post subject: Reply with quote

Thanks for your work, it seems good and I'll surely look at this deeper and test in my nodes.
A question: have you ran rdate?

A
Back to top
View user's profile Send private message Send e-mail Visit poster's website
johu
User
User


Joined: 06 May 2008
Posts: 27

PostPosted: Wed Jun 04, 2008 9:23 pm    Post subject: Reply with quote

I synced clock manually with rdate after boot.
Back to top
View user's profile Send private message
Antonio (isleman)
Site Admin
Site Admin


Joined: 10 Feb 2008
Posts: 2323
Location: Toscana, Italy

PostPosted: Wed Jun 04, 2008 9:42 pm    Post subject: Reply with quote

yeah ...thanks
Back to top
View user's profile Send private message Send e-mail Visit poster's website
jaebird
Intermediate User
Intermediate User


Joined: 05 Apr 2008
Posts: 59
Location: DFW, Texas

PostPosted: Thu Jun 12, 2008 2:59 am    Post subject: Reply with quote

So now my gateway has been able to recover from failed uplink! So my original problem that I was seeing when I started this thread appears to have fixed itself. I'm still on c738.

Thanks for you work Antonio.
Back to top
View user's profile Send private message
jaebird
Intermediate User
Intermediate User


Joined: 05 Apr 2008
Posts: 59
Location: DFW, Texas

PostPosted: Tue Jun 17, 2008 1:14 am    Post subject: Reply with quote

Ok my problem is back. I can ping my gateway from within the network, but I cannot ssh or wget (8080) on it. It is not sending info to dashboard, hence my repeaters are offline as well. This is now with version t_c782.n. There is no way to remote reboot it since i cannot do anything but ping.

BTW: what is port 4421 for, and why is it open?

I will have to power-cycle, but will the reboot reason be helpful?

EDIT: I forgot to say that I moved to a different channel since I thought it may have been an interference issue before.

Is there a watchdog for gateway mode?

Jae
Back to top
View user's profile Send private message
john.breeden
Moderator
Moderator


Joined: 26 Apr 2008
Posts: 117

PostPosted: Tue Jun 17, 2008 1:28 am    Post subject: Reply with quote

jaebird wrote:

Is there a watchdog for gateway mode?


Only registered users can see links on this forum!
Register or Login on forum!

Back to top
View user's profile Send private message
john.breeden
Moderator
Moderator


Joined: 26 Apr 2008
Posts: 117

PostPosted: Tue Jun 17, 2008 6:03 am    Post subject: Reply with quote

jaebird wrote:

EDIT: I forgot to say that I moved to a different channel since I thought it may have been an interference issue before.
Jae


This may help;

I just moved som nodes from a test to production network. The only change was the essid

In preping the nodes, I plug them into an internet connection as gateways and when they come up and open-mesh.com is pingable, I run /sbin/update (I've got an rs232 serial console on the nodes).

The update script runs just fine EXCEPT it drops the default route on the gw node. No reboot after the update. This has been consistant across 10 nodes updating as gateways.

In other words, it "looses" the internet, the same symptoms you have now. You said you changed channels which means /sbin/update ran and it probably dropped the default route.

Either the update script isn't rerunning /etc/init.d/dhcp-discover or isn't doing a reboot after update (I don't know which antiono usually does).

BTW: You probably can ssh into your gw node, you're just not waiting long enough. I don't know about dropbear but openssh will attempt to resolve an incoming address and if there is no dns connection will sit and wait 60 seconds until the dns lookup times out then give you a passwd prompt - I assume dropbear does the same thing.

BTWII: I'd bet a simple reboot will cure your problem.
Back to top
View user's profile Send private message
jaebird
Intermediate User
Intermediate User


Joined: 05 Apr 2008
Posts: 59
Location: DFW, Texas

PostPosted: Tue Jun 17, 2008 8:25 pm    Post subject: Reply with quote

I did finally reboot it this morning. ssh never came back (the wait was much longer than 60sec), it always responded to ping tho. Before I power cycled it, i noticed that the WLAN led was blinking normally as if the radio was still on...so I don't think that this was the freeze lockup problem (as it did respond to the ping).

I tried downloading the watchdog patch...but that download site sux bigtime, someone else host it please.

Jae
Back to top
View user's profile Send private message
john.breeden
Moderator
Moderator


Joined: 26 Apr 2008
Posts: 117

PostPosted: Tue Jun 17, 2008 9:36 pm    Post subject: Reply with quote

You need to hookup a serial console to your gw node to find out what's really going on, otherwise you're shooting in the dark.

-JB
Back to top
View user's profile Send private message
jaebird
Intermediate User
Intermediate User


Joined: 05 Apr 2008
Posts: 59
Location: DFW, Texas

PostPosted: Thu Jul 17, 2008 2:29 am    Post subject: Reply with quote

I thought I'd follow up on this. It appears I was at a distance limit with Ethernet cable. My FON router was plugged into a WRT54G router with a "lot" of wire in between. I finally found out that the link was being dropped on the WRT54G. As soon as I plugged it into a different network switch, I have not had any issues at all.

So the problem was NOT related to ROBIN at all, it was simply a "weak" network port on the router.

Note: I'm not really sure how long the wire is, but it runs the length of the building that it is installed in. It appears stable with the new switch.

Cheers,
Jae
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ROBIN - Open Source Mesh Network Forum Index -> c7xx All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
c d
e



Powered by phpBB © 2001, 2005 phpBB Group

Abuse - Report Abuse - TOS & Privacy.
Powered by forumup.it free forum, create your free forum! Created by Hyarbor & Qooqoa
Confirmed

Page generation time: 0.544