[RADIATOR] Proxying RADIUS Accounting Packets to Third Party Vendor: Not all Attributes proxied

[Traiano Welcome]

Hi List

I've configured my radius servers to send a copy of radius accounting
packets to a receiving radius server at  third party vendor, who will then
process radius accounting packets for billing purposes. I'm doing this
using an "AuthBy RADIUS" clause placed after an "AuthBy SQL" clause:

My configuration  is as follows (Thanks to, Heikki and Hugh!):

---------
<AuthBy RADIUS>
        Identifier Accounting_Packet_Feed
        Host 196.181.13.1
        Secret  s3cr3t
        RetryTimeout 30
        AuthPort        1812
        AcctPort        1813
        NoForwardAuthentication
</AuthBy>

---------

This is then used in a Handler, right after <AuthBy SQL> as follows (
Identifier Accounting_Packet_Feed):

---------------
<Handler NAS-Identifier=/^MyNAS-.*$/>

        AuthByPolicy ContinueWhileAccept

        <AuthBy SQL>
                DBSource        dbi:Pg:dbname=acctrecords;host=localhost
                DBUsername      logmonkey
                DBAuth          y34hr1ght
                AuthSelect
                AccountingTable acctrecords
                AcctColumnDef nasidentifier,NAS-Identifier
                AcctColumnDef timestamp,Timestamp

                .
                .
                .
        </AuthBy>
        AuthBy Accounting_Packet_Feed
 </Handler>.
-------------------

In my AuthBy SQL statement, there are around 200 attributes defined,
however not all of them are being proxy'ed by the "AuthBy RADIUS" module,
especially, we're not seeing all the attributes being exported in the
accounting stop packets proxied to the third party vendor's radius server.

We see a lot of the following type of error in our logs associated with
our destination radius server:

---
.
WARNING: Bad authenticator received in reply to ID 153
.
WARNING: Unknown reply received in AuthRADIUS for request 153 from
196.181.13.1:1813 
.
---

I've confirmed the secret is the same between the proxying radius servers
and the destination radius server, so this doesn't look like the issue.


In addition, when I do a verbose tcpdump of packets received from my
proxying radius servers, I notice a lot  of this type of error:

----
          Vendor Specific Attribute (26), length: 8 (bogus, goes past end
of packet)
          Vendor Specific Attribute (26), length: 12 (bogus, goes past end
of packet)
----



My questions are as follows:


1. Is there any configuration that  must be applied to the <AuthBy RADIUS>
module to ensure all the available  radius attributes in the original
accounting packet from the NASes are proxied in their exact state to the
final destination radius server ?
2. Are the  "(bogus, goes past end of packet)" messages anything to be
concerned about ?


Any help would be much appreciated!

Thanks in Advance,
Traiano