Possible bug in ospf_lsupd_receive
Hi guys, I think there's an endianness problem in ospf_lsupd_receive. On the lines where the program checks lsa->type or uses the LSA_SCOPE macro, it has not previously converted lsa->type to host representation. I saw this problem as I created a new LSA class with type BFF0, which has area scope. It was incorrectly displaying "<WARN> Received LSA with invalid scope" messages and refusing to add the LSAs to the database. I checked and at the line 513, if ((LSA_SCOPE(lsa) == LSA_SCOPE_RES)) was evaluating as true because lsa->type was F0BF, which is a reserved type. All the other LSA types are also inverted, but it doesn't pose a problem for the common LSA types as their first hex digit is usually 0 if they are misrepresented (0800 for link LSA, 0120 for router LSA etc). The problem can be fixed by putting ntohlsah(lsa, &lsatmp); before the checks and using &lsatmp instead of lsa for checks. Cheers
On Mon, May 14, 2012 at 02:37:39PM +0200, Benjamin Paterson wrote:
Hi guys, I think there's an endianness problem in ospf_lsupd_receive. On the lines where the program checks lsa->type or uses the LSA_SCOPE macro, it has not previously converted lsa->type to host representation. I saw this problem as I created a new LSA class with type BFF0, which has area scope. It was incorrectly displaying "<WARN> Received LSA with invalid scope" messages and refusing to add the LSAs to the database. I checked and at the line 513, if ((LSA_SCOPE(lsa) == LSA_SCOPE_RES)) was evaluating as true because lsa->type was F0BF, which is a reserved type. All the other LSA types are also inverted, but it doesn't pose a problem for the common LSA types as their first hex digit is usually 0 if they are misrepresented (0800 for link LSA, 0120 for router LSA etc). The problem can be fixed by putting ntohlsah(lsa, &lsatmp); before the checks and using &lsatmp instead of lsa for checks. Cheers
Thanks, you are right, i will fix that. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Benjamin Paterson -
Ondrej Zajicek