Hi community,

In this scenario: AR5213 or 5413 act as ap-bridge, RB532A 2.9.26 with PPPoE server that forward the user auth on a ext radius, and client-side antenna Osbridge 5XLi with firmware 3.31R2 (not 3.32 because i have *big* problems with mtu ...) some clients having a very long uptime (30% of total clients), the rest 70% got a "disconnected... peer is not responding" and a quick reconnect in the usual PPPoE way after 1-2 secs.
The typical disconnection time is every 2-3 hours.

Is not a antenna reboot - the antenna uptime show me uptime of 1 day and more - and a intuitive consideration i made is that more clients carry the ap, more frequent is this problem - i don't know is is a statistical issue or due to biggest load for AP.

Anyone experienced this with this OSBridge product or with other PPPoE products client-side??
Thanks for any help.

Hi ,

I have some problem too.

No solutions ?

Thank's

OSbridge have a problem with PPPoE ...they mess with the mac of the pppoe server . Yet another thing to throw in the bin

OSbridge have a problem with PPPoE ...they mess with the mac of the pppoe server . Yet another thing to throw in the bin

Hi ,

but we don't use PPPoE , the osbridge is configured as bridge ( trasparent ) .

Is a MTU problem ?

Thank's

This is the rf stat of 1 CPE osbridge xli5g



RF Statistics:

Watchdog Timeouts: 0
Hardware error interrupts: 0
Beacon Miss interrupts: 0
Recv Overrun interrupts: 0
Recv EOL interrupts: 0
TXmit Underrun interrupts: 0
TX Management frames: 38
TX Frames discarded prior to association: 0
TX Frames discarded 'cuz device gone: 0
TX Queue stopped because full: 0
TX Encapsulation failed: 0
TX Failed 'cuz no node: 0
TX Failed 'cuz no tx buffer (data): 0
TX failed 'cuz no tx buffer (mgt): 0
TX Failed 'cuz too many retries: 8
TX Failed 'cuz FIFO underrun: 0
TX Failed 'cuz xmit filtered: 0
Short on-chip TX retries: 0
Long on-chip TX retries: 220
TX Failed 'cuz bogus xmit rate: 0
TX Frames with no ACK marked: 29
TX Frames with rts enabled: 0
TX Frames with cts enabled: 0
TX Frames with short preamble: 746
TX Frames with an alternate rate: 42
TX Frames with 11g protection: 0
RX Failed 'cuz of desc overrun: 0
RX Failed 'cuz of bad CRC: 11522
RX Failed 'cuz of FIFO overrun: 0
RX Failed 'cuz decryption: 0
RX Failed 'cuz MIC failure: 0
RX Failed 'cuz frame too short: 967651
RX Setup failed 'cuz no skbuff: 0
RX Management frames: 0
RX Control frames: 0
PHY errors: 12229
OFDM timing: 11267
OFDM illegal parity: 29
OFDM illegal rate: 18
OFDM illegal service: 914
OFDM restart: 1
No skbuff available for beacon: 0
Periodic calibrations: 1327
Periodic calibration failures: 0
RFgain value change: 0
Rate control checks: 0
Rate control raised xmit rate: 0
Rate control dropped xmit rate: 0
RSSI of last ACK: 34
RSSI of last RCV: 35

Suggestions ?

Thanks'

Today , i have connect a client with osbridge to a new BTS at 5ghz with xr5 .

Identical problem. Random disconnection , lost pinging .

Perfect LOS , signal up to -48 .

bye

upgrade the osbridge unit to the latest firmware, configure infrastructure client mode and it will be working fine.

Been using 2.4GHz ossies with MikroTik APs for a long time without any great problem - only irritation is that when you set one up to do PPPoE it will not pass on the DNS config to the connected DHCP clients so you have to hard code the DNS servers into the DHCP which seems a little pointless.

upgrade the osbridge unit to the latest firmware, configure infrastructure client mode and it will be working fine.

No, not exactly so.

I test OsBridge 5Xli on many wireless card act as AP bridge - seems to be more stable if my radius check only user and password and *not mac address* at auth.
BTW, from firmware rel 3.32 the PPPoE client (rewritten from scratch, as written in changelog) block the MTU autodiscovery in windows (or better on the client in LAN side).... and constrain me to fix all the MTU at safe levels into the base stations i have. Firmware 3.31R2 still not have this kind of problem.
As a result of this great PPPoE implementation, until i fix MTU, many customers can't open site like microsoft (not a great loss...), bank sites in https, and all the kind of sites that have issues with the fragmentation of the TCP packets...

A great help for me to solve all come from Sten posts - thank here for all - but i have one month of nightmares before figure out the problem.
So this "working fine" are two words that i'm glad to see explained better. And the packet loss in a simple ping -t something is terrific in certain situation that i still can't figure out when and why.

Regards,
crt