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
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.
Good day, the freebsd-net readers.
Perhaps someone can look at the kern/109815 and provide some
feedback. Citing my PR:
> >When if_bridge is used to gather multiple vlan interfaces that have
> >the same physical parent (I will call such vlan interfaces the 'vlan
> >group') the interface identifie
On 2007/03/02, at 21:59, Randall Stewart wrote:
Well it might meet some of them.. I need to know when DAD is done, but
also if a interface detaches.. aka stops hearing the RT adverts.. and
then later starts hearing them again..
I was thinking of all the various states V6 addresses go through..
On Sat, 3 Mar 2007, Alexander Motin wrote:
> Ian Smith wrote:
> > When started the first time, before there's any ng0 interface, mpd logs
> > the following two lines then immediately exits without further ado:
> >
> > paqi# /usr/local/etc/rc.d/mpd4.sh start
>
> Try to run mpd from console
Ian Smith wrote:
mpd4 -b syslogs the intro line, then sometimes another one, maybe two:
Mar 4 20:03:16 paqi mpd: process 39879 started, version 4.1 ([EMAIL PROTECTED]
20:51 3-Mar-2007)
Mar 4 20:03:16 paqi mpd: CONSOLE: listening on 127.0.0.1 5005
Mar 4 20:03:16 paqi mpd: [b_PPPoE] exec: /s
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 analog
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)
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
On 3/5/07, Bruce M Simpson <[EMAIL PROTECTED]> wrote:
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 wit
On Sat, 3 Mar 2007, Peter Jeremy wrote:
First problem: FreeBSD appears to be re-using source ports too
rapidly. My understanding is that a TCP socket ({src IP, src port,
dst IP, dst port} tuple) should not be re-used for 120 seconds after
teardown. Sample tcpdumps and IPfilter whinges below
On Sat, 3 Mar 2007, Peter Jeremy wrote:
Disabling net.inet.ip.portrange.randomized appears to work around this
but is undesirable for other reasons.
I should add that in the short term, that does seem to be the only
solution.
Fernando Gont has some ideas on how to make port reuse happen le
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
13 matches
Mail list logo
