Binding sockets to devices in FreeBSD

Hi all, I am developing an implementation of the Optimized LinkState Routing protocol(RFC3626) for Linux(www.olsr.org). OLSR is a routing protocol for mobile, multihop, wireless ad-hoc networks. I would really like to have my code compile on FreeBSD - but there is one major issue. OLSR sends

ng_netflow: request for feature

Hi Gleb, Wednesday, February 18, 2004, 3:49:58 PM, you wrote: GS>Dear collegues, GS>a port of ng_netflow has been just commited to ports GS> tree. It builds both on STABLE and CURRENT, and was tested GS> to work on really busy routers. GS>As before, I'd be glad for any kind of feedba

Re: ng_netflow: request for feature

On Thu, Feb 19, 2004 at 02:34:02PM +0300, Andrew Riabtsev wrote: A> GS>a port of ng_netflow has been just commited to ports A> GS> tree. It builds both on STABLE and CURRENT, and was tested A> GS> to work on really busy routers. A> GS>As before, I'd be glad for any kind of feedback: ideas,

Re[2]: ng_netflow: request for feature

Привет Gleb, Thursday, February 19, 2004, 3:18:11 PM, you wrote: GS> On Thu, Feb 19, 2004 at 02:34:02PM +0300, Andrew Riabtsev wrote: A>> GS>a port of ng_netflow has been just commited to ports A>> GS> tree. It builds both on STABLE and CURRENT, and was tested A>> GS> to work on really busy r

Re: ng_netflow: request for feature

On Thu, Feb 19, 2004 at 04:02:09PM +0300, Andrew Riabtsev wrote: A> GS> In most cases the answer is no. In 90 % cases ng_netflow is used on A> GS> top of ng_ether(4) node, which passes all data coming on wire. All A> GS> packet filtering with help of ipfw or ipf are done later. A> GS> You can try s

Re[2]: ng_netflow: request for feature

Привет Gleb, Thursday, February 19, 2004, 4:50:42 PM, you wrote: GS> On Thu, Feb 19, 2004 at 04:02:09PM +0300, Andrew Riabtsev wrote: A>> GS> In most cases the answer is no. In 90 % cases ng_netflow is used on A>> GS> top of ng_ether(4) node, which passes all data coming on wire. All A>> GS> pack

Solution: TX performance problems with 3Com 905C cards

Hi all, the performance problem seems to disappear, when the hardware checksuming for TX direction is disabled (RX hw checksuming still on). Here are the results: otherbox -> box with 3c905C: Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s l40960 34.80

Wireless USB Adapter

Does anyone know how to configure FreeBSD to use a wireless USB WLAN adapter. The adapter is a X-Micro WLAN USB adapter. When i plug it into FreeBSD i get a "ugen0" device loaded message. I understand this means that the OS doesn't specifically recognise it as a WIFI adapter, treating it as a g

Re: Solution: TX performance problems with 3Com 905C cards

On Thu, 19 Feb 2004, Marian Durkovic wrote: > Hi all, > > >the performance problem seems to disappear, when the hardware checksuming > for TX direction is disabled (RX hw checksuming still on). > Here are the results: Hm... This, combined with Matt blaming the Tx checksum for corrupting pac

PPP Problem and question.

Hello there to everyone. I'm using freebsd for pptp server and I'm trying to setup a reeradius ippoll feature working with fbsd. I'm expiriencing problems with that, it dues to a problem that (according to me) comes from a ppp userland tool. I have setupped working freeradius+mysql and a pptp+ppp

Re: Wireless USB Adapter

Gareth Bailey wrote: Does anyone know how to configure FreeBSD to use a wireless USB WLAN adapter. The adapter is a X-Micro WLAN USB adapter. When i plug it into FreeBSD i get a "ugen0" device loaded message. I understand this means that the OS doesn't specifically recognise it as a WIFI adapter,

Re: Binding sockets to devices in FreeBSD

Hi, You need to use sendto or sendmsg. For example, with IPv6, Quagga is sending IPv6 multicast packet on a per interface basis. The interface's ifindex is provided into the pktinfo structure. int ripng_send_packet (caddr_t buf, int bufsize, struct sockaddr_in6 *to, struct i

Re: Binding sockets to devices in FreeBSD

Well it doesn't look like it would work for IPV4. If you look at the following code there is no place to specify the interface index at packet level in send as in IPV6. If the broadcast addresses on the different interfaces were different then there is no problem the sendto would work but if broad

Re: Binding sockets to devices in FreeBSD

Thanks for your replies mr. Kumar and mr, Jardin. I've been informed by Bruce Simpson that two interfaces actually cannot be configured with the same broadcastaddress in FreeBSD. Bruce M Simpson wrote: > > Can't currently do this due to limitations in the routing > code (that is, can't have more