< said:
> Where an RFC mandates that the reply source address must be the same
> as the request dest addr
This is true for *any* protocol built over IP, regardless of what the
individual protocol specifications say. See RFC 1122 sections
3.3.4.2, 4.1.3.5, and 4.2.3.7. (It actually says ``SHOUL
< said:
> i have freebsd 4.2 stable.
> what is difference between interface flags IFF_UP and
> IFF_RUNNING?
IFF_UP indicates that the interface is administratively configured up.
IFF_RUNNING indicates that the hardware has been set to an operational
state. For Ethernet-like interfaces, which o
< said:
> Can anyone realistically see bind or ntpd being modified to take
> advantage of it when running on FreeBSD?
Yes, given that it results in substantial simplification and (in the
case of named) enables non-privileged operation even in the presence
of dynamically-configured network interf
< said:
> Since rt was the cached route of the pcb, the ref count is >= 1
> since the pcb will have a ref count on it. In the case of a dynamic
> route, in_losing calls rtrequest to delete the route but not rtfree.
> rtrequest() only deletes the route from the routing table. It does
> not free
< said:
> Hmm, and what happens if the PCB is the only holder of this route?
> The refcnt will be 1 in this case, and the code drops the reference
> by setting inp->inp_route.ro_rt = 0. How this route can be reused
> (and deleted) later?
That would be a bug. rtfree() must always be called befo
< said:
> Looking at the comments in tcp_var.h, it should be
> keepintvl that sets this interval. Otherwise, why
> have such a large value for keepidle?
FreeBSD contains a kluge wherein all TCP connections have a form of
keepalive enabled by default. This is supposed to be separate from
the ex
< said:
> I'm working on modernizing the vlan device (making it loadable,
> unloadable, and clonable) and I've run into this sysctl. It allows you
> to set the ethernet protocol used for vlan packets. This doesn't strike
> me as very useful [...]
It has never proven useful to me, but all the V
< said:
> Is there any reason for ICMP source quench to be deprecated?
There are a few problems with ICMP source quench:
1) If a sender-TCP actually pays attention to them, an attacker can
substantially reduce TCP performance by forging them (a low-grade DoS
attack).
2) Few if any routers legi
< said:
> I have some other patches around that ease the interrupt-time requirements
> by scheduling a NETISR for vlan traffic. I wasn't ever sure if that was
> a true win, so I didn't contrib them.
I think it's actually a substantial lose, since all that will happen
is that the VLAN code will
< said:
> correct (in particular, it should be allowed to send a multicast with
> all-zeroes source address on an interface with no addresses).
It should also be allowed to send a broadcast with a zero source on
such an interface -- something which has been broken since The Dawn of
Time so far a
<
said:
> I am seeing something weird here. I get collisions on one of my vlan
> interfaces. Huh? How come? How can this happen?
UTSL.
/*
* Do not run parent's if_start() if the parent is not up,
* or parent's driver will cause a system crash.
< said:
> I'm using sendmail 8.11.5 on a FreeBSD-STABLE (4.4-PRERELEASE) system. I
> use the `.int' domain for hosts on my LAN
Hope you never need to communicate with anyone in the *real* .int
domain
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net"
< said:
> Current if_addmulti() calls MALLOC() with M_WAITOK. However,
> if_addmulti() can be called from in[6]_addmulti() with splnet(). It
> may lead kernel panic.
This is not a problem (or should not be). It is permissible to sleep
while some interrupts are blocked; it is just not (in 4-st
< said:
> I just want to ask around in case I turned out to be doing
> something incredibly evil.
Directed Broadcast is generally discouraged, and a BCP was published
not too long ago officially deprecating it (updating the router
requirements to require such a function to default to `off').
M
< said:
> So, your patch just adds the mentioned option -- which I'm fine with,
> as long as the default is 0 as the RFC requires...
We had directed-broadcast forwarding before, and it was removed.
Perhaps someone might examine the CVS logs to see when and why.
-GAWollman
To Unsubscribe: send
<
said:
> I was wondering about RTM_NEWADDR. I have noticed that no such message
> is generated when you add a new address to an interface with ifconfig.
This may or may not be a bug. I'm inclined to say that it is a bug; a
routing process should probably be informed when a new address is
co
< said:
> Protosw's are still externed, so more declarations are needed, but
> that should change.
I have wanted to move the protosw[] entries into the individual
protocols for a long time. We're already halfway there.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscri
<
said:
> Another question... when the interface goes up and an RTM_INFO message
> is generated, shouldn't the interface addresses be passed?
No; there is enough information in the RTM_IFINFO message for a
listener to determine which interface is being referred to. At least
on my machine it i
< said:
> I would like to commit ARP support for link level addresses with
> arbitrary length. Patches against HEAD attached. Most of this stuff
> was taken from NetBSD.
Why? Is there any reason to believe that FreeBSD will (or even should)
ever support ARCNET?
-GAWollman
To Unsubscribe: sen
< said:
> Someone is currently working on just that.
To what end?
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
< said:
> Can anyone tell me why the VLAN code might be causing my switches (ciscos)
> to see a lot of runt frames when the interface is in 802.1q trunking mode ?
It's possible that the Cisco is (bogusly, IMHO) trying to enforce the
Ethernet minimum frame length on the *de*capsulated frames.
< said:
> But doesn't the switch have to assume that the VLAN will be attached to
> some non-trunked ports, in which case the packets must be an appropriate
> length.
The minimum length needs to be enforced at the output interface.
(A switch would need to do so anyway for locally-generated packe
< said:
> Also, who is the VLAN maintainer these days ?
I think that code has a ``sticky hat'', so whoever last touched it is
``it''.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
< said:
> Disagree. Packet is either a runt or not a runt. It cannot be
> inconsistently bridged it to one (trunk) interface but not to (access)
> interface.
Runt-ness is not a property of the contents of the frame, it's a
property of the wire the frame is sent on. A frame bridged from
another
< said:
> raw_uattach(struct socket *so, int proto, struct proc *p)
> {
> struct rawcb *rp = sotorawcb(so);
> - int error;
> if (rp == 0)
> return EINVAL;
> - if (p && (error = suser(p)) != 0)
> - return error;
> return raw_attach(so, proto)
< said:
> + if (rtm->rtm_type != RTM_GET && so->so_cred->cr_uid != 0)
> + senderr(EACCES);
I'm certain rwatson would object to this. suser_xxx() allows checking
on the basis of credentials rather than a process, so that's what
should be used. In any case, the correct error is E
< said:
> net.inet.udp.maxdgram
> net.inet.udp.recvspace
> I assume that increasing both of these will improve performance.
Neither of these have any impact on UDP performance. In fact, there
really are no UDP performance parameters to be tweaked; the UDP
protocol doesn't hav
< said:
> There are a number of situations where it's desirable to authorize based
> on the current process, and others based on the current socket credential.
I would argue that any file descriptor is, in and of itself, a
(somewhat limited form of) credential. Presumably the 4.3BSD
developers
< said:
> The gateway's IP address actually refers to two different machines.
> Naturally the gateway is used quite a bit, and the syslog fills up with "arp
> X moved from Y to Z on fxp0" messages.
That's really not the right way to do it, and probably doesn't balance
the load as well as you mig
< said:
> The trouble with this is that your password will be sent unencrypted
> across the Internet, very possibly hitting a sniffer or two along the
> way. It's better to insist on chap and fix the broken peers.
Actually, no: the other side, which considers itself a server, doesn't
want to au
< said:
> Oh. I haven't actually sniffed it, so I'll assume you're right. I
> apologize for the misinformation.
Well, that's the situation as it was described upthread, and I
experienced something similar when I was first setting up PPP dialups
here.
-GAWollman
To Unsubscribe: send mail to
< said:
> +/*
> + * NB: For FreeBSD, it is assumed that each NIC driver's softc starts with
> + * one of these structures, typically held within an arpcom structure.
> + */
This has been true since at least 4.2.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freeb
< This has been true since at least 4.2.
Oops -- this is going to be the source of a lot of confusion. By 4.2
I am referring to 4.2BSD, of course, and not FreeBSD 4.2 which would
not be much of a precedent.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-ne
< said:
> can be changed to:
> mii = device_get_softc(dev);
> ifp = mii->mii_ifp;
I don't see anything wrong with the way things are. Perhaps some more
documentation is necessary, but as noted upthread this has a 20-year
history in the BSD networking stack and it's not like it's a
< said:
> - printf("%s\n", buf);
> + printf("%.*s\n", (int)len, buf);
This is a *much* better patch.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
< said:
> Ah! OK. I was using 4.1 so I guess it uses plain Reno,
No.
> that documents all the differences between the
> different types, Reno, NewReno, Vegas, etc?
Not really, since those names are not particularly meaningful, and
were mostly just invented by the researchers who were pushing t
< said:
> Hi,
> we're seeing a strange thing happening, related to ARP and IP fragments.
Not strange at all. The ARP cache only queues a single packet waiting
for a reply, so the first few fragments you send get tossed. We could
easily arrange it so that the first frag, rather than the last, g
< said:
> Similar things could be done in m_pullup() to avoid the
> extra allocation.
Can't be done in m_pullup: the whole purpose of m_pullup is to
*guarantee* that the data in question will never be shared. It might
be worth having a new interface which doesn't provide such a
guarantee.
-GAW
< said:
> - You mention moving if_flags to the first element, is there any code
> that assumes that if_softc is the first element in the ifnet? Putting
> at the start of the second cache line might be another option.
There shouldn't be; if_softc is a recent invention, and should by
ri
< said:
> (and anyhow Garrett got rid of the 'static' uses
> of mbufs, not 'travelling' 'per packet' uses..)
Only because I did not have the time or stomach then to introduce
`struct packet' everywhere. All of the queueing and metadata crap
should be pulled out of mbufs and put into a higher-le
< said:
> I'd be happy with a HAS_A(mbuf), as long as I have SOMEWHERE,
> to stash the metadata.
Mind, you don't put the metadata there; you put that in the packet
structure (or rather, in the ip_packet etc. structures). I'd like to
get rid of mbufs entirely, but that's a whole 'nother kettle
<
said:
> Are y'all going to discuss this at BSDCon? I'm probably going there
> and would like to contribute if I could.
I will not be going to BSDcon absent some sugar daddy paying the
freight.[1] I will be at LISA in San Diego (on my employer's dime) and
could discuss this with whoever migh
< said:
> I am looking at the ip_output routines, but so far cannot see any check
> for expiry of cached routes ? Can anyone point me in the right
> direction (or confirm they don't expire unless the route is physically
> unavailable ?)
Routes which are in use do not have timers on them, and the
< said:
> Unfortunately, this is not calculated; we still rely on a static
> (default 30sec) MSL quiet period. Ideally, it should be possible to
> set MSL based on some multiple of RTT for the connection, and default
> to a hard coded value if there are not enough samples to calculate RTT.
Th
< said:
> Where inet_pton(3) will fail (return a 1). That is, inet_pton(3) only
> understands dotted quads. The comments in src/lib/libc/net/inet_pton.c
> clearly show this is the intended behavior. But is that what we want?
Yes. The old format is deprecated, obsolete, legacy, however you want
Congratulations, Bill! I hope this won't suck up all of your Copious
Free Time... :-)
-GAWollman
--- start of forwarded message (RFC 934 encapsulation) ---
Message-Id: <[EMAIL PROTECTED]>
From: Bernard Aboba <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
To: IETF-Announce: ;
Subject: Ann
[Redirecting to a more-appropriate mailing-list.]
< said:
> I spoke to him on the phone this morning. He replaced it with a 3Com
> card, but there was no significant difference in performance. He's
> currently upgrading to -STABLE, which seems to be a sensible thing to
> do, so we should wait
< said:
> Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI.
> There is code obviously taken from if_loop.c and used in some
> drivers, which tries to do something with the third argument "data"
> of the if_ioctl() driver method if "data" isn't NULL.
The historic implementation pas
< said:
> On Tue, Oct 09, 2001 at 10:19:09PM -0700, Bill Fenner wrote:
>> (ifSpeed says "For a sub-layer which has no concept of bandwidth, this
>> object should be zero." I'd argue that this describes VLAN interfaces.)
> not that the vendor is always right or anything, but at least one
> imple
< said:
> If memory serves me right, =?iso-8859-1?q?Gavin=20Kenny?= wrote:
>> What flavour of TCP is standard in the FreeBSD stack,
>> is it Reno or New Reno, Vegas, Tahoe any others?
> You didn't say what version of FreeBSD you were concerned with, but
> 4.3-RELEASE and later versions all use
< said:
[Quoting Bruce Mah:]
>> happens. In *most* cases, the receiver somehow gets the missing data
>> because you can later see it acking later sequence numbers. The first
>> place I saw this was at :41.504152.
Those are not duplicate acks because the window is still getting updated.
>> An
< said:
> Your 4.4-STABLE machine, is it from before or after rev 1.107.2.18 of
> sys/netinet/tcp_input.c?
Before.
> Also...where did you do the trace (i.e. sender, receiver, or a third
> machine)?
Sender, of course -- that's the only place some of these phenomena
could possibly be observed.
< said:
> Can you run these tests again with rfc1323 off ?
Not any time soon.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
[Quoting Archie Cobbs, I think:]
>> There is probably a good paper somewhere outlining the "best effort"
>> philosophy but I don't know what it is.
That would be ``End-to-End Arguments in System Design'' by Jerry
Saltzer, Dave Reed, and Dave Clark, one of the most influential papers
ever written
< said:
> 5-CURRENT (11/19):9244 pps, 35.6 Mbps
> 4-STABLE (late November): 21827 pps, 84 Mbps
Doesn't seem right to me.
wollman@cheyenne-mountain(6)$ ttcp -t -s -v -f m -b 131072 -u mintaka
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001, sockbufsize=131072 udp ->
< said:
> But it's interesting the soalloc() is called with 'p != 0'
> as an argument. p is never 0 or else you would have already
> panic'd... you'd panic later on, too, referencing 'p->p_ucred'.
All of the credential frobbing stuff was added much later. At the
time I wrote that `p != 0', it w
>> is there any way to get at the if_multiaddrs list from user space (except
>> for digging through the kernel with kvm).
>>
> I'm affraid not.
There should be.
> I think the right way would be to add this to net/rtsock.c:sysctl_iflist()
> to be accessible through the NET_RT_IFLIST sysctl. BT
< said:
> Unfortunately, all I have is a binary for the app, so I can't figure
> out what they are doing. I don't even know if making a TCP connection
> to 255.255.255.255 is legal.
It is utterly, 100% bogus.
> Does anyone know where this explicit broadcast route is being added,
> and why? Is
<
said:
> i need to be modifying the firmware of the wireless
> network card which probably has the mac layer code?
The MAC layer is almost invariably implemented in hardware for modern
network interfaces. In the case of wireless networks, that's usually
firmware running on a microcontroller i
< said:
> net.inet.tcp.newreno. (At the risk of exposing my naivete, does disabling
> New-Reno leave me with ... Reno? Or possibly some FreeBSD hybrid?)
It leaves you with FreeBSD pre-New Reno. That's Reno, plus
high-resolution timers, plus some retransmit-avoidance stuff that goes
along with
<
said:
> This is an issue with the routing system design. Many routers
> allow duplicate routes (same netmask) that have different priorities.
> This makes it quicker to switch routes during a failure.
FreeBSD permits this as well. It is the responsibility of the routing
process to manage wh
< said:
> We still need to cap the number of sockets somehow, as it would be bad for
> sockets to consume all memory.
There's already a cap: maxfiles.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
< said:
> That would end up being a reduction below the current value; right now
> sockets > maxfiles with large maxuser values. Whether or not this is a
> necessary differential, I'm not sure. (With TIME_WAIT and FIN_WAIT_2
> sockets, I believe that maxsockets should exceed maxfiles.)
My poin
< said:
> I don't know, but it may have problems setting promiscuous mode..
> is there such a thing in vlan mode?
Certainly -- but the other VLANs configured on the same interface have
to be prepared to appropriately ignore the traffic they receive that
isn't addressed to them.
-GAWollman
To
Currently, FreeBSD's implementation of RFC 1323 uses the contents of
the `ticks' variable verbatim in the TCP timestamp options that it
generates. This is perhaps undesirable, in that it allows the system
at the other end to determine how long the system has been up.
(Current versions of `nmap' d
< said:
> Is doing this wise? I have this nagging feeling that randomizing (or
> zeroing on each new connection) the timestamp would degrade its usefulness
> for PAWS checks and the like. (Don't ask me how, I haven't thought it
> through fully.)
I don't think so, because the timestamps, as cur
< said:
> out of the box. Ideally, I would like applications sending packets to the
> interface to block when the outgoing queue is full.
No Can Do. The network stack is not prepared to block at all, ever.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-n
< said:
> A bug is that host routes created by redirect are never being purged.
> But that one has been present for a long (?) time.
You are expected to be running a routing process (like `routed' in
router-discovery mode) which will delete them for you. I agree that
this is not a reasonable ex
< said:
> datamib[5] = IFDATA_GENERAL;
> *ip = drvdata->ifmd_data.ifi_ipackets;
> *op = drvdata->ifmd_data.ifi_opackets;
> *ib = drvdata->ifmd_data.ifi_ibytes;
> *ob = drvdata->ifmd_data.ifi_obytes;
The ``general'' part of the interface MIB is implemented by generic
code in net/if_mib
In article <201407151034.54681@freebsd.org>, j...@freebsd.org writes:
>Hmm, I am surprised by the m_pullup() behavior that it doesn't just
>notice that the first mbuf with a cluster has the desired data already
>and returns without doing anything.
The specification of m_pullup() is that it re
So is anyone working on an RFC 7217 ("Stable and Opaque IIDs with
SLAAC") implementation for FreeBSD yet?
-GAWollman
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd
In article
<388835013.10159778.1424820357923.javamail.r...@uoguelph.ca>,
rmack...@uoguelph.ca writes:
>I tend to think that a bias towards doing Getattr/Lookup over Read/Write
>may help performance (the old "shortest job first" principal), I'm not
>sure you'll have a big enough queue of outstandin
Here's the scenario:
1) A small number of (Linux) clients run a large number of processes
(compute jobs) that read large files sequentially out of an NFS
filesystem. Each process is reading from a different file.
2) The clients are behind a network bottleneck.
3) The Linux NFS client will issue
<
said:
> I think your other suggestions are fine, however the problem is that:
> 1) they seem complex for an edge case
> 2) turning them on may tank performance for no good reason if the
> heuristic is met but we're not in the bad situation
I'm OK with trading off performance for one user agai
<
said:
> There have been email list threads discussing how allocating 9K jumbo
> mbufs will fragment the KVM (kernel virtual memory) used for mbuf
> cluster allocation and cause grief.
The problem is not KVA fragmentation -- the clusters come from a
separate map which should prevent that -- it'
< said:
> - as you said, like ~ 64k), and allocate that way. That way there's no
> fragmentation to worry about - everything's just using a custom slab
> allocator for these large allocation sizes.
> It's kind of tempting to suggest freebsd support such a thing, as I
> can see increasing requirem
< said:
> I'm not really (or really not) comfortable with hacking and recompiling
> stuff. I'd rather not change anything in the kernel. So would it help in
> my case to lower my MTU from 9000 to 4000? If I understand correctly,
> this would need to allocate chunks of 4k, which is far more logi
In article <41d96b7f-f76d-4f35-ba1d-0edf810e6...@young-alumni.com>,
"Chris" writes:
>True OR False
>
>1) NDIS only works with XP drivers.
Can't answer that as I've never needed to try a Vista driver.
>2) NDIS only works with 32-bit drivers and wont work on amd64.
False, unless someone has broke
In article ,
Robert Watson writes:
>m_pullup() has to do with mbuf chain memory contiguity during packet
>processing.
Historically, m_pullup() also had one other extremely important
function: to make sure that the header data you were about to modify
was not stored in a (possibly shared) cluster
In article <4a3bf2df.6080...@freebsd.org>, Andre writes:
>2) in old T/TCP (RFC1644) which we supported in our TCP code the SYN/FIN
>combination was a valid one, though not directly intended for SYN/ACK/FIN.
It still is valid, and should be possible to generate using sendmsg()
and MSG_EOF. No
In article <[EMAIL PROTECTED]>, Brooks
Davis writes:
>On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote:
>> FYI - HPN is already a build option in the openssh-portable port.
>
>I do think we should strongly consider adding the rest of it to the base.
Am I the only one who would be happ
< said:
> Garrett Wollman wrote:
>> Am I the only one who would be happier if openssh were not in the base
>> system at all?
> Quite possibly :)
> I don't think it's at all viable to ship FreeBSD without an ssh client
> in this day and age.
If that were w
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
>static int
>mpls_attach(struct socket *so)
The prototype for a protocol attach functions is
int (*pru_attach)(struct socket *so, int proto, struct thread *td);
(see sys/protosw.h). You don't have to use these arguments, but
In article <[EMAIL PROTECTED]>,
Jeff Davis <[EMAIL PROTECTED]> wrote:
>You should see something like "write failed: host is down" and the
>session will terminate. Of course, when ssh exits, the TCP connection
>closes. The only way to see that it's still open and active is by
>writing (or using) a
< said:
> Some time ago I noticed that there appeared to be several members
> of struct socket that were either only used by listen sockets or
> only used by data sockets.
You can't do that. Self-connect is a valid operation on a socket.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECT
< said:
> Why bother with a if_softc field when the interface and softc pointer are
> supposed to be the same? Also, the very old Lance driver (lnc) has this
> problem. It makes me wonder how true we are to TCP/IP Illustrated...
if_softc was added to pacify those who either didn't understand t
[Trying desparately to move this discussion to the correct list]
I spent a few minutes talking to Dave Clark about this question this
afternoon. Here's my paraphrase of his opinion:
- He disclaims completely up-to-date knowledge of the current research
results.
- He feels that 1000 ms is c
< said:
> Is there a reason why SO_TIMESTAMP does not work with TCP sockets
> but only with RAW and UDP ?
Because it doesn't really make sense?
Since the TCP stream may be arbitrarily re-ordered, knowing when a
packet arrived is not particularly useful to an application. If you
really care, yo
< said:
> protocols have the option of implementing pru_sosend() using the central
> sosend(), or providing their own optimized implementation. However, the
> exception to this appears to be in the nfsclient code, where sosend is
> invoked directly on the socket:
The NFS code is hairy and evil
< said:
> Accepting incoming T/TCP creates a pretty serious DoS vulnerability,
> doesn't it? The very first packet contains the request, which the
> server must act upon and reply to without further delay. There is no
> 3-way handshake, so a simple attack using spoofed source addresses can
> im
< said:
> anyone know of an in-kernel traffic generator similar to UDPgen
>
>(http://www.fokus.gmd.de/research/cc/glone/employees/sebastian.zander/private/udpgen/)
>
> for Linux? Userland traffic generators have high overheads with small
> packets at Gigabit speeds.
I wrote one a long time a
< said:
> In the meantime absolutely no code has picked up on this idea,
It was copied in spirit from OSF/1.
> The side effect of having some source-files using the _IP_VHL hack and
> some not is that sizeof(struct ip) varies from file to file,
Not so. Any compiler which allocates different a
< said:
> My processes writing to SOCK_DGRAM sockets are getting ENOBUFS
Probably means that your outgoing interface queue is filling up.
ENOBUFS is the only way the kernel has to tell you ``slow down!''.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net
< said:
> My question is do I realy need to fill this? Or is it there just for
> future use?
That depends on what you will be using the length for. Some
interfaces require that it be present; other interfaces (e.g., those
system calls which already take a separate length argument) do not.
-GAW
< said:
> root@heat[~]% sysctl -a | grep ipf | grep bridge
> net.link.ether.bridge_ipfw: 0
> net.link.ether.bridge_ipf: 0
Grrr... Who's responsible for creating non-protocol nodes under
net.link.ether?
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in
< said:
> Why is rt_refnt decreased so early and not later ?
So long as the route is marked RTF_UP, it cannot be deleted. In a
single-threaded kernel, it is not possible for this code to be
preempted, so there is no means by which the route flags could be
changed. (RTF_UP is unset when and only
< said:
> Has anyone done work to incorporate the ISO networking code
> into FreeBSD? This has been done for NetBSD. It is a required
> component if one wishes to natively support ISO based protocols
> such as IS-IS.
For the limited value that OSI protocols have today, it is a much
better use of
< said:
> On the other hand the NetBSD folks don't see it as dead weight
Are you volunteering to do all the work (or pay someone else to do
so)?
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
< said:
> What is involved?
A huge amount of work: converting the ancient netiso code to use
modern kernel programming interfaces, figuring out MP/MT locking,
adding the netiso support back to the protocol-independent parts of
the kernel, fixing all the warnings, translating all of the anti-DoS
c
< said:
> Working with Sun JDK network code I have realized a need to provide some
> range checking wrapper for setsockopt() in SO_{SND,RCV}BUF cases. Short
> walk over documentation shown that maximum buffer size is exported via
> kern.ipc.maxsockbuf sysctl. But attempt to use this value as max
101 - 200 of 247 matches
Mail list logo
