Hey guys, sorry for the late response, been busy with the holidays and
work and www.packetfactory.net/ipgeo.

Ok, so let me knock these out right quick:

OSPF - please submit a patch if you have one. If you're right (and I
suspect you are) the code has been broken since day one and anyone
using it will be creating broken packets. As such, if an interface
change is the only *correct* way to fix it, let's do it.

Multiple Contexts - I agree and await Fred's patch (which is probably
already in my inbox.

I've CC'd this to the list so people can been kept abreast of what's
what.

On Dec 21, 2003, at 1:19 AM, Frédéric Raynal wrote:

> Hello Kathleen,
>
>
> On Fri, Dec 19, 2003 at 08:30:48AM -0500, Kathleen Poulsen wrote:
>> Hello Frédéric and Mike,
>>
>> i have made some changes to the OSPF Hello code (which i imagine i
>> will
>> soon need to make to the other OSPF messages)...basically the network
>> byte ordering is wrong on fields that use IPv4 addresses. Unlike
>> other modules which expect a network byte ordered address (see
>> libnet_build_ip.c
>> for example),
>> libnet_build_ospf adds an a htonl(value) for these addresses.
>> The sample code, when run on linux, illustrates the problem.
>>
>> More importantly however, the OSPF Hello header (and probably other
>> messages)
>> is not quite right--it requires a single IPv$ address--the neghbor,
>> followed by a payload which is a list of neghbor addresses
>> (also IPv4). OSPF does not require a single neighbor address (and in
>> certain
>> cases you can't have one, such a P2P), so the neighbor argument should
>> be removed. This is a change to the API, and I don't know how you
>> ordinarily handle that.
>>
>> I may have time to look at the other messages next week (i know i
>> cannot do so
>> today), but i expect similar changes elsewhere.
>
> When a change of API is in question, it is Mike who can decide.
> However, I can tell what I think : if the change is required, then we
> do it.
>
>> Another point...I don't understand why libnet opens a new fd for
>> each libnet context, particularly in the case where the user handles
>> the
>> LINK layer. It would be better to share a single fd per device.
>> In cases where we prepare thousands of packets prior to sending
>> anything,
>> this causes us to run out of fd's. it doesn't make sense to increase
>> the system fd max each time we need to do this. We have also
>> been working on a case where we need to fragment very large packets.
>> each fragment isusing a fd as it stands now, and again this is a
>> problem.
>>
>> What do you think about changing this setup such that a new fd is
>> allocated
>> (via open) only when there is no open fd for a device?
>
> that is one of the internal changes I wanted to do. You may have seen
> there is also a problem when trying to use a down interface. I will
> fix these 2 problems in one patch. I have an idea on how to do that
> without breaking everything.
>
>>
>> its been a good experience using libnet!
>>
>
> Thanks to you for your help and feedback,
>
> Fred Raynal
>
>
> <!DSPAM:3fe5db25118701223255551>
>
>
>
--
Mike Schiffman, CISSP
http://www.packetfactory.net/schiffman
Doveryay No Proveryay

[ reply ]