[PATCH] Part 1 of low level 802.1p priority support

Hi, Here is the first patch to bring in 802.1p Packet Priority to FreeBSD; this is to support Differentiated Services and Quality-of-Service. This builds on the M_VLANTAG support introduced by Andre last September. This first stage enables FreeBSD to pass packets for 802.1q with VLAN 0 to th

[PATCH] Part 2 of low level 802.1p priority support

This updated patch moves VLAN tag decapsulation into if_ethersubr.c and always uses M_VLANTAG, which is also passed to the upper layer. Tests with ping: fxp (no VLAN_HWTAGGING support) OK msk (VLAN_HWTAGGING enabled) OK msk (VLAN_HWTAGGING disanabled) FAIL I am concerned that t

[PATCH] Introduce M_PROMISC to lower part of Ethernet code

Hi, Thunderbird keeps crashing whenever I draft these messages, which is frustrating. Can we discuss this change? I would like to get it in as we get the following wins: 1. Potentially cleaner code in ether_demux()/ether_input() 2. Ways of detecting and preventing L2/L3 forwarding loops 3.

[PATCH] Make INET6 MROUTING dynamically loadable in GENERIC

Hi, This should do what it says on the tin... Regards, BMS Make IPv6 multicast forwarding dynamically loadable into a GENERIC kernel. Index: conf/files === RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.1175 diff -

[PATCH] netstat(1) should print CIDR prefixes

Hi, This is a POLA violating 'let's move with the times' patch that gets rid of the special treatment of classful IPv4 network prefixes in 'netstat -rn' output. Comments please! Rgards, BMS Index: route.c === RCS file: /home/ncvs

Re: [PATCH] Part 2 of low level 802.1p priority support

Andrew Thompson wrote: This is great for the bridge, it has needed to take the vlan tag into account when deciding to forward or not. Having m_pkthdr.ether_vtag always set makes this much easier to implement. In the deleted code M_VLANTAG is cleared but is not done anymore, is this right?

Re: Configuring rendevous point

[EMAIL PROTECTED] wrote: Hi all situation: got freebsd box working as NAT for my local network. In kernel config there is an option PIM. FYI, PIM is now the default in -CURRENT; the option has been removed. You should be able to load multicast routing with PIM as a loadable kernel module in

Re: [PATCH] netstat(1) should print CIDR prefixes

Gary Corcoran wrote: Since those 'classes' haven't meant anything for many years, and interpreting them as 'special' is just plain wrong in almost all cases these days, I think the change is the right thing to do. I've had +3. Any objections? If I hear none I will make this change in -CURRE

Re: "route add" how it behaves

Kather Rafi -TLS,Chennai wrote: Hi all, I am new to FreeBSD. I want to know how the "route add " is working for the network routes and host routes in the case of with out specifying the gateway. In linux we can add like "route add -host 10.0.12.24 eth0" but in FreeBSD it should be like "route

Re: [PATCH] Part 2 of low level 802.1p priority support

Pyun YongHyeon wrote: > Further testing with drivers is needed (I can't be 100% sure it fails > with msk(4) because something strange is happening when vlan tagging is > turned off). Perhaps Pyun knows? > I guess I've not merged local changes before committing to HEAD. How about attached

[PATCH] Updated 802.1p/q patch

Hi, I have tested my 802.1p input patch with vlans configured. So far so good. It is now available from: http://people.FreeBSD.org/~bms/dump/latest-8021p.diff This updated patch moves the 802.1q encapsulation into if_ethersubr.c, allowing M_VLANTAG to be passed up and down the stack for 802

Re: Gateway slowed down to barely usable

Andrea Venturoli wrote: Today it suddenly dropped to a bare few b/s. I checked the ISP line by attaching another machine in place of this and it could do full 1Mb/s, so this box was the problem. After a simple reboot it started working as good as always. Now the question is: in case this ha

Re: [PATCH] Updated 802.1p/q patch

Yar Tikhiy wrote: Do you have any architectural reservations about nested VLANs in the main network stack? Presently, a one-line patch can allow a vlan(4) to attach to another vlan(4), but I haven't heard about the behaviour of the resulting setup yet. After looking around it seems there is d

Recommendations for OSPF v3 book?

Does anyone have any good suggestions for a book which discusses OSPF v3 architecture? I have read the original John Moy book 'OSPF: Anatomy of an Internet routing protocol' but would very much like to know of there is a good text out there which discusses OSPF in the wider context of IPv6 and

[PATCH] Re: ioctl: SIOCADDMULTI (howto?)

Jouke Witteveen wrote: So my apologies for suggesting it doesn't work at all; it seems that the application I'm trying to get to work (wpa_supplicant for wired interfaces) just doesn't _send_ its packets the right way. That's a big relief! I added an item to the Wiki for someone to write a regr

Re: Unable to connect broadband

satimis wrote: Hi folks, FreeBSD-6.2-amd64 ... The onboard NIC seems not detected. In the absence of required information, I speculate your machine has msk(4) or another recent chipset which may be supported in FreeBSD-CURRENT but not FreeBSD-STABLE. Please post the full output of 'pcicon

If you run IS-IS please contact me

Anyone out there running IS-IS on a FreeBSD machine, please contact me. It's my understanding that IS-IS requires link-layer multicast support. Therefore I would like to hear from anyone who is running an implementation of it on FreeBSD successfully. I want to make sure it continues to operate

Re: ioctl: SIOCADDMULTI (howto?)

Here is a better patch for the netstat output. I haven't had time to look at the kernel yet. If this patch is good for you I'll commit it on -CURRENT. It cleans up the group membership output significantly and displays the Link-layer information separately. If anyone 'out there' has been rel

Re: ioctl: SIOCADDMULTI (howto?)

Jouke Witteveen wrote: I hope someone can find a spare minute to look at if_findmulti. It would help me quite much. I verified with mtest that FreeBSD cannot delete an AF_LINK multicast membership, reproduced with both 7-CURRENT and 6.2-RELEASE. if_findmulti() appears to be doing a possibly i

NetworkRfcCompliance is born

http://wiki.freebsd.org/NetworkRfcCompliance Please begin wiki-whacking! BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NetworkRfcCompliance is born

Luigi Rizzo wrote: On Wed, Feb 21, 2007 at 02:50:27PM +, Bruce M Simpson wrote: http://wiki.freebsd.org/NetworkRfcCompliance before it is too late to change, maybe it is the case to spell RFC as all capital letters ? It would surely be better named NetworkStandardsCompliance as

Re: [PATCH] Re: ioctl: SIOCADDMULTI (howto?)

I have now added a regression test for this bug in HEAD, under src/tools/regression/ethernet/ethermulti. BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECT

Re: kern/86848: [pf][multicast] destroying active syncdev leads to panic

Hi, Please try the attached patch which should hopefully fix this issue (untested). Regards, BMS ? .swp Index: if_pfsync.c === RCS file: /home/ncvs/src/sys/contrib/pf/net/if_pfsync.c,v retrieving revision 1.32 diff -u -p -r1.3

Re: kern/100519: [netisr] suggestion to fix suboptimal network polling

Synopsis: [netisr] suggestion to fix suboptimal network polling State-Changed-From-To: feedback->open State-Changed-By: bms State-Changed-When: Sun Feb 25 16:18:13 UTC 2007 State-Changed-Why: Back to the net pool Responsible-Changed-From-To: bms->net Responsible-Changed-By: bms Responsible-Chan

Re: kern/86848: [pf][multicast] destroying active syncdev leads to panic

Whups. That needs 'int s' or the spl calls removed. I am under the weather today (dry flu type virus)... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: making a dumb switch into a smart one

Luigi Rizzo wrote: partly off topic, but maybe someone migth find this interesting given that the device can do vlan tag insertion/removal, so it can be used to provide additional fan-in/fan-out to freebsd-based routers in not too high-speed networks. Were you trying to perform the same evil e

Re: Networking FreeBSD Wiki

[EMAIL PROTECTED] wrote: George, maybe there should be a separate category in GNATS also, for network issues? Instead of being in kern you mean? I have thought that before but I don't control GNATS and we'd have to review a lot of bugs. I have noticed there has been a gradual effort o

Re: [PATCH] Feature request: exit netstat(1) after user specified outputs

LI Xin wrote: Hi, If no one objects this change, I will commit it? No objection here. BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Proposal: Add M_HASCL().

Much network code needs to know if the mbuf it is looking at is using a cluster. I propose putting M_HASCL() in sys/mbuf.h. I realise this is a style change, however, it seems to be a very common idiom. Places this macro is currently defined and used directly: netinet/ip_mroute.c netinet6/ip6_m

Re: Proposal: Add M_HASCL().

Bruce M Simpson wrote: Much network code needs to know if the mbuf it is looking at is using a cluster. I propose putting M_HASCL() in sys/mbuf.h. I realise this is a style change, however, it seems to be a very common idiom. I sent this, then I looked at NetBSD, having caught a glimpse of

Re: nconsistencies with IP_ONESBCAST and/or IP_SENDSRCADDR

Bruce M Simpson wrote: Hello, In preparation for tightening up our handling of INADDR_BROADCAST sends, I ran some brief tests today on the network stack with the attached test code. I found some inconsistencies when run against 6.2-RELEASE; 1. IP_ONESBCAST breaks if SO_DONTROUTE is

Re: Inconsistencies with IP_ONESBCAST and/or IP_SENDSRCADDR

Andre Oppermann wrote: I have some WIP here too. I'll send it to you later this afternoon. Thanks, I look forward to seeing it, re Issue #2 IP_SENDSRCADDR. Dealing with dhclient is a separate issue -- here, something like IP_SENDIF needs to be introduced, as we are truly in an 'ip unnumbere

Re: is setsockopt SO_NOSIGPIPE work?

Anton Yuzhaninov wrote: RE> It works, but only if you use send() instead of write(). RE> Alternatively, you can control the behavior on a per RE> message basis, by passing the MSG_NOSIGNAL in the "flags" RE> argument to the send() call (without having to set a RE> socket option). Thanks, with se

[PATCH] Re: is setsockopt SO_NOSIGPIPE work?

Anton Yuzhaninov wrote: Thanks, with send() it works fine. I think it should be documented in setsockopt(2). Try this patch. The comment doesn't reflect what the code does. SIGPIPE may actually be getting queued twice in your case. It is most likely that the process's main thread wasn't preemp

Re: [PATCH] Re: is setsockopt SO_NOSIGPIPE work?

Anton Yuzhaninov wrote: Works for me. Committed, thanks for finding this bug. BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Re: is setsockopt SO_NOSIGPIPE work?

N.J. Mann wrote: Could this be why mail from cron doesn't work for me in 6.2? I got as far as finding that cron receives a SIGPIPE while sending the mail message to sendmail, but never worked out why. I ended up hacking cron to ignore SIGPIPE and then ENOTIME to investigate further. Unlikely,

[PATCH] Ethernet cleanup; 802.1p input and M_PROMISC

Hello all, I would like to announce an updated version of the 802.1p input patch, available at: http://people.freebsd.org/~bms/dump/latest-8021p.diff I have cut down the original scope of the patch. I previously ran into problems when I tried to move VLAN tag input and output processing in

CARP behaviour

During testing of M_PROMISC I noticed a couple of issues with our CARP. 1. carp doesn't seem to maintain input/output statistics on its ifnet. 2. carp doesn't seem to detect that the underlying route to the subnet its address is exposed on changed to another interface. Are these conditions no

Re: [PATCH] Ethernet cleanup; 802.1p input and M_PROMISC

Yar Tikhiy wrote: In fact, there two independent flags indicating interface's readiness: IFF_UP and IFF_DRV_RUNNING. The former is controlled by the admin and the latter, by the driver. E.g., an interface can be UP but not really ready to operate due to h/w reasons, or vice versa. Perhaps we s

Re: bin/94920: [rpc] rpc.statd(8) conflict with cups over tcp and udp ports 631

Synopsis: [rpc] rpc.statd(8) conflict with cups over tcp and udp ports 631 Responsible-Changed-From-To: bms->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Sun Mar 4 15:03:40 UTC 2007 Responsible-Changed-Why: Someone else with Copious Free Time can do this -- not a priority for

Re: bin/100969: [rpc.lockd] rpc.lockd conflict with cups over udp ports 631

Synopsis: [rpc.lockd] rpc.lockd conflict with cups over udp ports 631 Responsible-Changed-From-To: bms->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Sun Mar 4 15:04:14 UTC 2007 Responsible-Changed-Why: Someone else with Copious Free Time can do this -- not a priority for me.

[PATCH] IP_SENDIF option; rework ip_output() source selection logic

Hello, Thanks to andre making a start on this, I have managed to get the IP_SENDIF option implemented today in p4 bms_netdev. Here's a patch against -CURRENT: http://people.freebsd.org/~bms/dump/sendif-20070304.diff For those who are new to this work: IP_SENDIF is broadly an analogue of

Re: CARP behaviour

Yar Tikhiy wrote: We shouldn't cache route pointers anywhere anymore. It has been completely removed from the PCBs and things like gif and others. Sounds like a good way to go, too! :-) Thanks! gre(4) does very funky things with the route it caches to the tunnel endpoint. Someone(tm)

Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge

Hi, I haven't seen your patch, can you point me at it off-list? Thanks. Eygene Ryabinkin wrote: I traced the current if_bridge.c behaviour to the NetBSD's if_bridge.c 1.9. This was the first version in that the firewall hooks were introduced. And the assumtion that the MAC identifies the physi

Re: [PATCH] Ethernet cleanup; 802.1p input and M_PROMISC

Yar Tikhiy wrote: Now I see your point, thanks! Well, at least in theory, the driver shouldn't call ether_input() if the interface isn't running. OTOH, the interface shouldn't be getting traffic if it's !UP. However, I suspect that not all drivers handle IFF_UP fully or even can do it at all

Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge

Eygene Ryabinkin wrote: Will try to understand if it will cure my problem, thanks! Attaching my patch, just in case if freebsd gnats will be down ;)) Thanks for this. It looks like Andrew may be in a better position to say if this fix should go in or not. It is possible that if bridge cha

Re: [PATCH] Ethernet cleanup; 802.1p input and M_PROMISC

Hi, Thanks for your reply. Yar Tikhiy wrote: My concern is that, with possible callers of ether_input() being not really *from* but *on behalf* of the interface, e.g., in Netgraph, IFF_DRV_RUNNING can be a way for the interface driver to tell us: I'm not ready yet, so don't believe anyone who p

Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge

Hi, Eygene Ryabinkin wrote: Sure, I can test it, but then I need to know what problems are cured by your patch, or I just should watch if it will not break something. My concern is that I want to make sure that all these changes to the ether_input path work OK together. The M_PROMISC flag

Re: [PATCH] Ethernet cleanup; 802.1p input and M_PROMISC

Yar Tikhiy wrote: My proposed check for IFF_DRV_RUNNING is by no means a priority task. I can add it by myself after you finish your great current project regarding ether_input() and friends. Just committed in p4: //depot/user/bms/netdev/sys/net/if_ethersubr.c#6 - /home/bms/p4/netdev/

Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge

Eygene Ryabinkin wrote: I am awfully sorry, but you're seem to be mistaken: Thanks for clarifying this. That'll be because I didn't read if_bridge that far. ;^) In my original message I was just looking at if_ethersubr.c. I need to make sure any changes which are made to if_bridge to deal with

Re: [PATCH] Ethernet cleanup; 802.1p input and M_PROMISC

Julian Elischer wrote: When we added netgraph we split both the input and output parts so that they would provide 'natural' entrypoints for a bridge. Consider where a bridge wants to put packets. In bms_netdev, bridge_input() is entered directly from ether_input(). It may potentially re-enter,

Re: Inconsistencies with IP_ONESBCAST and/or IP_SENDSRCADDR

Bruce M. Simpson wrote: Dealing with dhclient is a separate issue -- here, something like IP_SENDIF needs to be introduced, as we are truly in an 'ip unnumbered' situation -- ie the ifnet MAY not yet have been assigned an IPv4 address at all, and IP_SENDSRCADDR implies that you

Re: SO_ACCEPTCONN equivalent

Alexandru Arion wrote: Is there an equivalent in FreeBSD to the SO_ACCEPTCONN option for getsockopt(), available in Linux? It doesn't actually has to be an option for getsockopt(), just a way to determine if a socket has been marked to accept connections with listen(). SO_ACCEPTCONN appears t

Re: SO_ACCEPTCONN equivalent

Alexandru Arion wrote: Thanks for both suggestions. Since I'll support version 5.4 and up, this leaves me to using the workaround implied by calling accept and checking the returned value, for now. Erm. It looks like it's implemented in 5.4 as well, although you might have mentioned in your

Re: SO_ACCEPTCONN equivalent

Vlad GALU wrote: Erm. It looks like it's implemented in 5.4 as well, although you might have mentioned in your original mail you were working with a legacy version of FreeBSD. :^) http://fxr.watson.org/fxr/ident?v=RELENG54&i=SO_ACCEPTCONN Manpage diff attached. Mailman ate your homework.

Re: SO_ACCEPTCONN equivalent

Bruce M. Simpson wrote: Manpage diff attached. Mailman ate your homework. :/ My bad. Committed. BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[

Re: SO_ACCEPTCONN equivalent

Alexandru Arion wrote: Tried it on fresh install of 5.4: compiled the source locally, run, got error "Protocol not available". Same code works on Linux. By replacing SO_ACCEPTCONN with SO_REUSEADDR, or any other option that appears in the manual page for 5.4, the program works correctly. Bruce,

Re: Inconsistencies with IP_ONESBCAST and/or IP_SENDSRCADDR

Bruce M. Simpson wrote: I have just committed a change in bms_netdev which enforces strict and better defined semantics for the IP_SENDSRCADDR option in udp_output(). I have just committed this change in -CURRENT. After testing it with 'ipbroadcast', it looks good apart from sock

Re: tap(4) should go UP if opened

Frank Behrens wrote: How does tun(4) handle this? tun(4) is also set to down, when closed. It is not set to up, when ist is opened, but when an address is assigned by the user process. This is fine, because it needs always an ip address. tap(4) as layer 2 tunnel device does not need an ip addres

Re: UltraVNC on freebsd

Rashid N. Achilov wrote: TightVNC or TridiaVNC. But encryption and file transmission will not available with these VNC's and UltraVNC at another end JFYI: I have heard corporate IT people who mostly work with Windows discuss UltraVNC. I don't see a port for it. It is on SourceForge so per

Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge

Hi, Eygene Ryabinkin wrote: Speaking about vlan problems: the original problem is to do something with VLAN interfaces only because they are sharing the MAC of their physical parent. The problem itself is not VLAN-specific -- if there will be two physical interfaces with the same MACs and they

Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge

Eygene Ryabinkin wrote: This is a different point. The bridge wants to know about bridge members MACs just because it should catch the packets that are destined to the bridge members. It is the only way for an L2 thing that is operating in the promiscious mode. Correct. For our case (when MA

Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge

Yar Tikhiy wrote: Guys, excuse me, but I still fail to see how the case of VLANs' sharing a single MAC differs from the case of several physical interfaces with the same MAC from the POV of a bridge. A bridge can have no own MAC addresses at all, it plays with foreign MAC addresses only. Theref

Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge

Eygene Ryabinkin wrote: I tried to understand this, because Bruce already gave me a patch, but I am a bit stupid: I do not see how M_PROMISC that is cleared unconditionally before BRIDGE_INPUT will help us to identify the right interface. As I see now, the BRIDGE_INPUT is called once from if_ethe

Re: Generic ioctl and ether_ioctl don't agree

Yar Tikhiy wrote: Hi folks, Quite a while ago I noticed that our ioctl handlers get the ioctl command via u_long, but ether_ioctl()'s command argument is int. This disarray dates back to 1998, when ioctl functions started to take u_long as the command, but ether_ioctl() was never fixed. Fortunat

Re: tap(4) should go UP if opened

Hi, Frank Behrens wrote: If we have no possibility to mark the interface as UP for the non-root process the net.link.tap.user_open=1 is useless, because we can not transmit any packets. With the patch the interface goes UP only, when the administrator allowed non-root user access. The co

Re: [PATCH] Removal of redundant entries from ifnet manpage

Aniruddha Bohra wrote: Hi, The ifnet manpage contains entries for the following routines which do not exist in the ifnet struct. committed, thanks! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsu

Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network

Gleb Smirnoff wrote: AFAIK, the problem needs a more generic approach. I see two approaches. 1) Introduce RTM_CHANGEADD, a command that will forcibly add route, deleting all conflicting ones. Use this command in in_addprefix(). 2) In rt_flags field we still have several extra bits. We can use t

Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network

Gleb Smirnoff wrote: I was afraid that this would raise an argument on multipath routing. Let's temporary do not speak about multipath but just decide what is the correct way to remove conflicting routes when we are assigning an IP prefix to a local interface? My suggestion is to take the seco

Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network

Anton Yuzhaninov wrote: Thursday, March 15, 2007, 7:30:54 PM, Andre Oppermann wrote: AO> IMO when configuring a interface with an IP address and network it should AO> kick out previous host and/or network routes matching it. Unless those AO> are from locally configured interfaces, then it shoul

IPv4, IPv6 and link-layer multicast refcounting in bms_netdev

I have just committed reference counting for multicast structures in p4. Change list number is 116036. This should fix the problems with pfsync and carp since the scalability fixes for IPv4 multicast last September. A further cumulative fix for pfsync is present in this branch. Basic testing

MFCing rev 1.96 of netinet/in.c for Zeroconf

The change itself is very simple; http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=1.95&r2=1.96 This change is necessary before IPv4 address scope and source selection policy may be implemented. Does anyone see any potential problems with this? It is possible that there

Interface index hack in IP_ADD_MEMBERSHIP

Hi, I plan to get rid of the ugly little ip_multicast_if() hack in the IP stack.= Before I do, is anyone actually using this? RFC 3678 specifies a protocol independent API for socket group memberships which allow joins on interfaces referenced by index. This is intended to support IGMPv3 and

Re: Interface index hack in IP_ADD_MEMBERSHIP

Eugene Grosbein wrote: I recall that routed and ripd used to utilize something similar long time ago. I'm not sure if they have switched to another API. You're right -- this would break routed on point-to-point interfaces. They didn't, unless it was updated at the upstream, i.e. rhyolite.co

[PATCH] Multicast refcounting in network stack

Hi, A patch against -CURRENT is now available: http://people.freebsd.org/~bms/dump/multi_refcounting.diff This is a fairly sweeping architectural change which should resolve memory leaks and potential panics with the network stack as a whole, to better support interface detach at runtime.

Re: networking code and splx()

Ignacio Rey wrote: ... The question is: Have calls to these functions been wrapped? or are they simply not used in this context? splx() and friends have been no-ops since FreeBSD 5.x was branched. Synchronization is now done using other mechanisms such as mutexes and spin locks. See the new

Re: PMTU Discovery support

Kevin Lahey wrote: The boxes were running FreeBSD-6.1, but I can't really vouch for the particular kernel configuration. It could well be that the problem is with the loose nut behind the wheel, rather than with FreeBSD. :-) I believe PMTU measurements may only be relied upon for active TC

Re: [PATCH] Multicast refcounting in network stack

Andre Oppermann wrote: http://people.freebsd.org/~bms/dump/multi_refcounting.diff Patch looks good. :-) Committed, with some changes. Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To un

Re: ICMP-floods

I have a patch attached to http://wiki.freebsd.org/Networking to rate-limit ICMP which is generated by the forwarding path. It would be useful to find out if this offers symptomatic relief in this situation, although as Chuck points out, it is most likely being caused by a routing loop. Rega

Proposal: Merge RFC3678 multicast APIs

Hi, I propose that we merge the RFC3678 advanced multicast APIs. Doing so gets us closer to IGMPv3 and SSM. I would greatly appreciate suggestions about how to deal with the include header issue below. I have already started merging the basic definitions into p4 branch bms_netdev. Backgrou

Re: MPLS implementation

Sam Wun wrote: Hi, Is there any MPLS implementation for FreeBSD? I found a port ayame mpls for netbsd, but the last implementation was dated back to 2003, seems very old. There is NISTswitch, but it is most likely very bit-rotted by now. I would suggest helping Anihudda Bodhra out on the Cli

Re: kern/19875: A new protocol family, PF_IPOPTION, to handle IP options at socket interface

Synopsis: A new protocol family, PF_IPOPTION, to handle IP options at socket interface State-Changed-From-To: suspended->closed State-Changed-By: bms State-Changed-When: Mon Mar 26 14:36:38 UTC 2007 State-Changed-Why: It is unlikely this code will ever be committed. Reasons: 1) This information

Re: GRE with key

Cristian KLEIN wrote: Hello everybody, I am new to FreeBSD kernel hacking, so please excuse my perhaps stupid questions. I would like to add key support to gre(4). I have already been able to use gre(4) with a hardcoded key. The single thing remaining to do is to transfer the key from ifconfig(

Re: Vrrp/CARP/ucarp Problems

Andrea Venturoli wrote: Jordan Gordeev wrote: The only load balancing that CARP supports, to my knowledge, is ARP level load balancing. From carp(4): The ARP load balancing has some limitations. First, ARP balancing only works on the local network segment. It cannot balance traffic that

Re: The broadcast of python in FreeBSD

Zhu Yan wrote: When I send the broadcast in FreeBSD with address 255.255.255.255, the packet can not be received by other OS. FreeBSD applications need to use the IP_ONESBCAST option to send all-ones broadcasts. See the ip(4) man page. Regards, BMS _

Re: Merging rc.d/network_ipv6 into rc.d/netif

Mike Makonnen wrote: I would especially like feedback from folks more familiar with IPv6. One gotcha I've noticed is that if you boot with ipv6_enable turned off, then try to start IPv6 on an interface later on, it doesn't work because none of the interfaces (except lo0) has a link-local address

Re: IPFW update frequency

For what it's worth, the code I wrote for XORP is only for IPFW2, and uses its tables feature to atomically transcribe XORP rulesets to IPFW ones before swapping them in. Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/m

Re: accf_{data,http} defaults?

On Fri, Jun 06, 2003 at 09:49:25PM -0500, Conrad Sabatier wrote: > Is this impression correct, or will accf_data and accf_http actually have > any effect if simply loaded? Correcto. Apache has patches in its tree to use these features when loaded. BMS _

Re: IP over DVB

On Mon, Jun 23, 2003 at 10:48:31PM +0200, Vincent Jardin wrote: > I am looking for an IP over DVB-S and MPE support on FreeBSD. > > I could only find a very old driver for FreeBSD 2: > http://www-sop.inria.fr/rodeo/personnel/eduros/index-dvb.html > > Are there any better support for FreeBSD 4 o

Re: IP over DVB

On Tue, Jun 24, 2003 at 05:42:00AM -0700, Julian Elischer wrote: > what is DVB? > Digital Video Bus? DVB stands for Digital Video Broadcasting. It is a standard for broadcasting multiplexed data/audio/video content, typically over a satellite, cable or terrestrial transmission medium. More informa

Re: Request for Review: bin/54151

On Sun, Jul 06, 2003 at 09:33:11PM +0400, Dmitry Morozovsky wrote: > Dear colleagues, > > would you please spend a bit of your time to review > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/54151 > [patch to add -i option to arp(8)]? I think this sort of thing is badly needed, especially for the

Re: ipprecedence

On Sat, Jul 05, 2003 at 12:33:32PM -0700, Luigi Rizzo wrote: > permit. Certain hardware even has multiple, prioritized > transmit rings, but there is no support for them in our > drivers (basically we don't have an API for that). One example which immediately springs to mind is the RTL8139C+ which

AODV RFC is now ratified

On Tue, Jul 08, 2003 at 08:13:03AM -0600, M. Warner Losh wrote: > Cool! Hopefully this work will include fixing lucent cards too :-) Hail Eris. All hail Discordia. By the way, have you seen RFC 3561? It's just out. http://www.faqs.org/rfcs/rfc3561.html Ad hoc On-Demand Distance Vector (AODV) Ro

ether_resolvemulti() doesn't expire routes

I noticed that if I do this:- # route add -net 224.0.0.0/4 -iface xl0 -expire 3000 The resultant cloned routes don't get given a lifetime, i.e. they're totally static and remain in the route table for the lifetime of the kernel. Either multicast designated receivers or IGMP aware routers are the

Re: RTF_CLONING vs RTF_PRCLONING

On Mon, Jul 28, 2003 at 11:45:28PM +0200, Vincent Jardin wrote: > I do not understand the purpose of the flag PRCLONING. What is it for ? Compare the output of netstat -rn with netstat -rna, to see the difference between a cloned and a protocol-cloned route. BMS __

Re: RTF_CLONING vs RTF_PRCLONING

On Mon, Jul 28, 2003 at 05:51:28PM -0400, Garrett Wollman wrote: > RTF_XRESOLVE is set when the target of the newly cloned route is not > known by the kernel and must be set up by a user process. I'm not > sure if anything ever used this, although I guess it could be used to > implement ISIS. I h

[PATCH] AODV (RFC 3561) support for tcpdump

Hi all, I send you this patch in order that I may have your advice. I've added a module to tcpdump to decode AODV packets as per RFC 3561. The only extension currently understood is HELLO. I've submitted this to [EMAIL PROTECTED], but I've been working with a number of you on wi(4) related things

On demand routing redux (RFC 3561 AODV preparatory)

emand using a routing protocol * such as AODV. * This code will probably be vastly cleaned up and tested more thoroughly * before being used as the basis for a user-space BSD AODV implementation. */ /* * Copyright (c) 2003 Bruce M. Simpson <[EMAIL PROTECTED]> * All rights reserved. * *

Re: T/TCP useless on FreeBSD 4.7?

On Fri, Aug 01, 2003 at 11:14:12AM -0400, michael rabinovich wrote: > Does anyone know the status of T/TCP support on FreeBSD 4.7? ... > Am I missing something (after all, FreeBSD is supposed to be a ref > implementation of T/TCP!) and if not is there is a simple way around > this problem, short

IP over DVB

Good news, I have acquired IP-over-DVB hardware, dish and LNB. Bad news, the Adaptec (pre-Broadlogic) ABA-1040 is ancient, and would appear to have *nothing* in the way of available documentation, or drivers; unless anyone can help... ? Regards BMS ___

<    1   2   3   4   5   6   7   >