| ï
That would be my
guess as well. The single broadcast from DHCP in a
poor signal link is
more likely to be dropped and the client times out waiting
for it's
IP.
We've just about
eliminated all of our PPTP client setups because they were
using DHCP, and in
lower signal situations they were having problems getting
an IP and staying
online.
In PPPoE the PPPoE
session is set up first, and it's done over Layer 2. Then
the IP session is
created over that. It's proven to be a much more reliable
connection over the
wireless, and semi-immune to short signal drops.
We're still using
DHCP, but that's for those clients connecting at HotSpots.
We haven't fired up
any yet, but we're making contact with a few places to
get the ball
rolling. With HotSpots you are working within a much smaller
area and the signal
will be much better. So DHCP shouldn't have many
issues in the
HotSpot environment.
Kevin Summers
KISTech Internet Services
Inc.
www.kistech.com
Kevin, your observations are very
interesting. I guess the reason for this is that part of dhcp
negotiation involves broadcast messages (eg dhcp "request" if I
remember correctly), which by their very nature to not elicit an
acknowledgement. It gets worse for devices on the far side (eg a PC) of
an AB as even the reply ("heres your lease information") needs to
be broadcast (dest = ff-ff-ff-ff-ff-ff-ff-ff) using BootP to get thro the
AB.
Broadcast messages are sent once and if the
recipient doesn't get it well thats tough. In a situation where you have
poorer signal or interference the probability of receiving a broadcast, even
though its a very short message, reduces considerably. Where you have
both poor signal AND an AB at the client (ie you need to get at least 2
broadcasts thro), I believe the probability reduces by some square law (much
worse than halved).
So I suppose this means we should
only use dhcp over the air where you have rock
solid high level signal and no interference (yea right!), and avoid using dhcp
at all for clients behind an AB.
The solutions might be (it works for
me)
- Use fixed IP for anything that might otherwise
need a dhcp lease from across an air interface. This includes all sB
devices except APs at NOC - I use fixed IP there too just to use SimpleNMS
and other tools consistently.
- Use fixed IP for first client device after
AP(cb) (does AP have dhcp server on eth side ? - I've never
needed it so I might have missed it). This is essential when
using AB.
- Use a router at client premises. This
allows you to set fixed IP on the radio side (no dhcp across air), and offer
a dhcp server to the eth side. The client can then use any PC without
calling you every five mins for a new fixed IP address, or to fix arp table
probs mentioned elsewhere. (Linksys BEFSR11 or 41 ~GBP30 save so much
heartache)
I havn't read up on PPPoE. I think the initialisation of a PPPoE session also
requires a broadcast too, but I'm not sure if this is the same thing - which
comes first, IP address setup or PPPoE session setup ? Kevin, does this
work for you cos you have static IPs in the right places as
requirement to use PPPoE in your setup ? Interesting that you get
80% and not 100% ?
These solutions not only provide for reliable IP
setup but also take dhcp traffic off the air completely.
Of course the implication of this is that
normal messages (ie those requiring acknowledgements) under these sig strength
conditions (where a broadcast is not successful), would be retried until they
get through, or are lost. That means that your airspace is cluttered
with management traffic, fragmentation etc, which could be halving your
throughput from the best net rate ~5Mbs (which is only achievable with
good signal anyway) - possibly time to put up a new AP ?
fwiw I would imagine reliablity of dhcp would
improve if the data rate across the air was reduced.
And finally - on previous threads I have banged
on about dhcp servers not supporting BootP. Whilst its true that some
don't (and so probs with ABs), the reasons above are a better
explanation, esp for people that can get this working on the bench but not
when it gets to the field (please take note sB - problem not available on
your bench !! - like the 1.08 lockup issue?). This one is a
protocol issue not a hardware or sB issue per se.
bw
----- Original Message -----
Sent: Friday, November 21, 2003 10:22
PM
Subject: RE: [smartBridges] 1.08
locking up ???
We went to PPPoE
on all of our clients and that eliminated 80% of
the problems
associated with DHCP. For what it's worth DHCP on our
network did NOT
work unless you had at least 75% RSSI and 75% LQ.
Anything lower
than that was unreliable for DHCP.
Kevin Summers
KISTech Internet Services Inc.
www.kistech.com
Dear all,
I wonder if this is
the same problem I've experienced and found what the issue is (at least in
my case). For some reason, if a computer is off or after DHCP
lease time has expired, getting a new DHCP lease from the wireless
network's router is a pain in the @ss. Usually, I either have
customers reboot their computers AND airBridges or if it's too many
customers I just unplug the router and replug it back in. Had the
same problem this morning after exactly 24 days of continuously running
without a hitch since last DHCP lease was given to 3 customers, all 3
reported problems getting online. Sure enough, their lease had
expired (I've set it to 24 days which is the max) and their computers were
not picking up the new lease.
I had this problem before with the
airBridges, but I set all the airBridges to static IP and haven't had any
issues with those. Always associated...no problems especially for
airBridges connected to customer routers with static IPs on the routers,
too.
What do you think? Could this be the same thing you're
experiencing? I'm using Linksys routers.
Sevak
On Fri,
2003-11-21 at 16:17, shoffman wrote:
Patrick,
As someone plagued with issues on SB equipment over the summer, I HIGHLY
recommend you go to 1.08 AND burn in your config (using simpledeploy) as
your default setting.. Just doing 1.08 has decrease our troubles by
about 70%. Going to long Preamble has decreased issues by another 15%.
Burning in the config has about made our problems disappear. I DO ping
all my units though.
As I stated, this has become a monitoring tool, and I dare not turn it
off just to "find out" if problems arise. Only calls we get now are
from normal network issues (My mail won't work) or from units we have not
visited to burn in the default config..
I REALLY WOULD LIKE TO DO THIS REMOTE FOR AIRBRIDGED PRODUCTS I can see
SB's stance for this on AP's but not for CPE's... let the customer change
their settings and burn them in.. its not like the unit has bandwidth
control or something.. and even if it did, if we see a password change we
will just remove its MAC from authorization! SB please reconsider!!!
Scott
-----Original Message-----
From: "Patrick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Date: Fri, 21 Nov 2003 15:52:58 -0500
Subject: Re: [smartBridges] 1.08 locking up ???
> I have not upgraded to 1.08 because I figure what is the point? There
> has yet to be a firmware upgrade that hasn't had some sort of an issue.
> But anyways, what I have noticed with the airbridges that stop
> responding, is that they work great for 1-2 months flawlessly, then all
> of a sudden, they begin having problems, usually many times a day. I go
> to the customer location, upgrade the firmware and we seem to be good.
> My biggest complaint is that if the unit is bad, then why doesn't it
> have a problem in the beginning. I have not changed the APPO firmware
> since day one of installing them so that is not the problem.
>
> ----- Original Message -----
> From: Seeni Mohamed
> To: [EMAIL PROTECTED]
> Sent: Friday, November 21, 2003 2:28 PM
> Subject: RE: [smartBridges] 1.08 locking up ???
>
>
>
>
> The behavior of the airbridge firmware is that when there is no
> traffic passed for the certain period, the airbridge becomes idle but
> the LINK STATUS shows that it is REMAIN associated. Once the traffic
> (browsing, ping or any application) is kicked in, then it will wake up
> again and start talking to the access point.
>
>
>
> Since watchdog feature firmware continuously monitoring the link at
> every 3 minutes interval which will make sure that the LINK STATUS is
> up all the times and it is not necessary to run continuous PING to wake
> up the unit.
>
>
>
> I have done all my best effort to reproduce it here, but I always
> failed to reproduce it in our LAB setup. The LAB setup done with
> airbridge 0.01.08 which is connected to the Linksys switch and 3 more
> PCs are connected behind the switch, No traffic pass thru and it was
> running for about 3 days during the weekend.
>
>
>
> After 3 days, we logged into the unit, can browse and Ping to the
> gateway without having any power reset. We have tried by manually power
> OFF the AP (to check the aB reset) for certain period and then ON back
> again and still airbridge passes the traffic again.
>
>
>
> When you are seeing the Ethernet lockup with our BETA 0.01.08, can
> you see the link status is UP or not?
>
>
>
> If any one interested, please kindly try using the above setup at
> your LAB and see whether you can able to reproduce it there. If really
> an issue, then we also should be able reproduce it here at any time.
>
>
>
> We appreciate your feedback on this new beta firmware which is really
> helps (making busy) us to identify any root cause of the problem.
>
>
>
> Thank you
>
>
>
> Kind regards,
>
> Seeni
>
> sB Tech Support
>
>
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Pascal Losier
> Sent: Saturday, November 22, 2003 12:50 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [smartBridges] 1.08 locking up ???
>
>
>
> If we all have the problem....... Why does the SBtech team not having
> it
>
> ????
>
>
>
> When the custumer comes in at the PC & try to browse...... Does it
> wake
>
> the AB up ???
>
>
>
>
>
> -----Original Message-----
>
> From: [EMAIL PROTECTED]
>
> [mailto:[EMAIL PROTECTED]] On Behalf Of Jerry Carter
>
> Sent: Friday, November 21, 2003 12:29 PM
>
> To: [EMAIL PROTECTED]
>
> Subject: Re: [smartBridges] 1.08 locking up ???
>
>
>
>
>
> This is what I do. I ping everyone's router every 3 minutes and I
> never
>
> have a problem. I use a nice windows tool called smonitor.
>
>
>
> Jerry
>
> ----- Original Message -----
>
> From: "Martin Moreno" <[EMAIL PROTECTED]>
>
> To: <[EMAIL PROTECTED]>
>
> Sent: Friday, November 21, 2003 11:26 AM
>
> Subject: RE: [smartBridges] 1.08 locking up ???
>
>
>
>
>
> > So far I ping every 30 seconds and that seems to work and yes from
>
> > what I
>
> see
>
> > you have to ping the client sde router or PC to keep the lan awake
> on
>
> > the
>
> ABO
>
> > OR ABI..
>
> >
>
> > Quoting Pascal Losier <[EMAIL PROTECTED]>:
>
> >
>
> > > When running ping to all radio.....Do you ping every second or
> every
>
>
>
> > > minute ??
>
> > >
>
> > > Does it meen having 100 custumer will need having 100 ping going
>
> > > on..?
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > -----Original Message-----
>
> > > From: [EMAIL PROTECTED]
>
> > > [mailto:[EMAIL PROTECTED]] On Behalf Of shoffman
>
> > > Sent: Friday, November 21, 2003 12:03 PM
>
> > > To: [EMAIL PROTECTED]; Blazen Wireless
>
> > > Subject: Re: [smartBridges] 1.08 locking up ???
>
> > >
>
> > >
>
> > >
>
> > > The only time we have seen this issue is when there is a
>
> > > router/switch directly under the AirBridge. What's funny is that
> we
>
>
>
> > > started our continuous pinging of the radio side again, and the
>
> problem has
>
> > > disappeared again. Guess these AB's are like ditch diggers, if
> you
>
> > > watch them continuously (ping or something) then not a problem.
>
> > > Turn your back and trust they are working... they go off to sleep
>
> > > under a tree somewhere... ;)
>
> > >
>
> > > Scott
>
> > >
>
> > >
>
> > > -----Original Message-----
>
> > > From: "Blazen Wireless" <[EMAIL PROTECTED]>
>
> > > To: <[EMAIL PROTECTED]>
>
> > > Date: Fri, 21 Nov 2003 06:42:46 -0800
>
> > > Subject: Re: [smartBridges] 1.08 locking up ???
>
> > >
>
> > > > I fidn that if I constant ping everything I don't seem to have
>
> > > > that problem but I have to ping the device on the LAN side of
> the
>
> > > > ABO and most people have pings turned off but so far (cross my
>
> > > > fingers) the ones I am able to
>
> > > > ping have not had any problems this past week..
>
> > > >
>
> > > > I find this as a problem that needs so more investigation..
>
> > > >
>
> > > >
>
> > > > ----- Original Message -----
>
> > > > From: "Pascal Losier" <[EMAIL PROTECTED]>
>
> > > > To: <[EMAIL PROTECTED]>
>
> > > > Sent: Friday, November 21, 2003 6:29 AM
>
> > > > Subject: RE: [smartBridges] 1.08 locking up ???
>
> > > >
>
> > > >
>
> > > >
>
> > > > Hi , We've all heard about 1.08 locking up...
>
> > > >
>
> > > > I have a link that was OK with 1.08 but it started working
>
> > > > flawlessly.
>
> > > >
>
> > > > I have an APPO at the otherside of the link
>
> > > >
>
> > > > If I ping the AB wirelessly, it will always respond.
>
> > > > If I ping the APPO sitting at the back, it will respond but
> will
>
> > > > stop after a while.
>
> > > >
>
> > > > If I search with Airbridge monitor, it will wake up everything
> at
>
> > > > the back of this bridge.
>
> > > >
>
> > > > If I run simple NMS...... This lockup never happens.
>
> > > >
>
> > > > Smartbridges could not have those lock up when testing, maybe
> it
>
> > > > is simply because Simple NMS was running somewhere on their
>
> > > > network.... (Just a clue).
>
> > > >
>
> > > > But those lock up in 1.08 are real. I got them.
>
> > > >
>
> > > >
>
> > > > The PART-15.ORG smartBridges Discussion List
>
> > > > To Join: mailto:[EMAIL PROTECTED] (in the body type
> subscribe
>
> > > > smartBridges <yournickname> To Remove:
> mailto:[EMAIL PROTECTED]
>
>
>
> > > > (in
>
> > >
>
> > > > the body type unsubscribe
>
> > > > smartBridges)
>
> > > > Archives: http://archives.part-15.org
>
> > > >
>
> > > >
>
> > > > The PART-15.ORG smartBridges Discussion List
>
> > > > To Join: mailto:[EMAIL PROTECTED] (in the body type
> subscribe
>
> > > > smartBridges <yournickname> To Remove:
> mailto:[EMAIL PROTECTED]
>
>
>
> > > > (in
>
> > >
>
> > > > the body type unsubscribe
>
> > > > smartBridges)
>
> > > > Archives: http://archives.part-15.org
>
> > >
>
> > > The PART-15.ORG smartBridges Discussion List
>
> > > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
>
> > > smartBridges <yournickname> To Remove:
> mailto:[EMAIL PROTECTED]
>
> > > (in the body type unsubscribe smartBridges)
>
> > > Archives: http://archives.part-15.org
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > The PART-15.ORG smartBridges Discussion List
>
> > > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
>
> smartBridges
>
> > > <yournickname>
>
> > > To Remove: mailto:[EMAIL PROTECTED] (in the body type
> unsubscribe
>
> > > smartBridges)
>
> > > Archives: http://archives.part-15.org
>
> > >
>
> >
>
> >
>
> > Martin Moreno
>
> > Blazen Wireless
>
> > 909-326-5003
>
> > www.blazenwireless.com
>
> > The PART-15.ORG smartBridges Discussion List
>
> > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
>
> smartBridges <yournickname>
>
> > To Remove: mailto:[EMAIL PROTECTED] (in the body type
> unsubscribe
>
> smartBridges)
>
> > Archives: http://archives.part-15.org
>
> >
>
>
>
>
>
> The PART-15.ORG smartBridges Discussion List
>
> To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
>
> smartBridges <yournickname> To Remove: mailto:[EMAIL PROTECTED]
> (in
>
> the body type unsubscribe smartBridges)
>
> Archives: http://archives.part-15.org
>
>
>
>
>
>
>
>
>
> The PART-15.ORG smartBridges Discussion List
>
> To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
> smartBridges <yournickname>
>
> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe
> smartBridges)
>
> Archives: http://archives.part-15.org
>
The PART-15.ORG smartBridges Discussion List
To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname>
To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges)
Archives: http://archives.part-15.org
|
