UltraVNC on freebsd
Hi to all, i've this scenario: one machine in a private network one machine with a public machine i need to control with vnc the machine with private ip by the machine with public ip. This is possibile installing ultravnc on the private machine (with freebsd) so i can start the communication with public machine and control the private machine? Which VNC? thanks in advance ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tap(4) should go UP if opened
I want to diskuss the tap(4) behaviour before I create a PR:
The tap(4) interface does not go automatically in UP state (IFF_UP) when opened
by a
process. Therefore an additional command "ifconfig tapx up" is necessary, which
can
execute root only. On the other site the interface goes down automatically when
closed.
I propose that tap(4) is set to UP when opened by an user process. This can be
achieved
with the following patch (on FreeBSD 6.2-STABLE-200703081613):
--- sys/net/if_tap.c.orig Thu Mar 8 19:10:59 2007
+++ sys/net/if_tap.cFri Mar 9 10:05:57 2007
@@ -501,6 +501,7 @@
s = splimp();
ifp->if_drv_flags |= IFF_DRV_RUNNING;
ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
+ ifp->if_flags |= IFF_UP;
splx(s);
TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, minor(dev));
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
address, so
setting it up on open is IMHO the best solution.
Sound this reasonable or how should I handle the tap(4) open by an user
process, when this
process does not run as root?
Regards,
Frank
--
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em problems on supermicro 5015M-MT+
On Friday 09 March 2007 01:50, Jack Vogel wrote: > On 3/8/07, Sven Petai <[EMAIL PROTECTED]> wrote: > > I am not sure why the 32/64 bit architecture is making a difference, > however, you have the 573 NIC, so before doing anything else run this DOS > app, it will patch your eeprom if needed, the problem is a misprogramed > MANC register that tends to eat packets when it shouldnt. the utility said the fix was not needed and symptoms didn't change either. > > Please let me know if that helps. > Oh, you arent using TSO by some chance are you? no ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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 address, so setting it up on open is IMHO the best solution. This isn't consistent with the other software cloneable interfaces which emulate certain layer 2 semantics, e.g. bridge, trunk, vlan; see below. Sound this reasonable or how should I handle the tap(4) open by an user process, when this process does not run as root? I recently committed Landon Fuller's code which makes tap and tun cloneable interfaces which may then be created via 'ifconfig tap0 create'. Automatically setting the interface to IFF_UP is not consistent with the semantics for other network interfaces; it requires specific privileges (usually super-user or PRIV_NET_SETIFFLAGS in -CURRENT) to do. However, we also support the creation of tap/tun instances by non-super-users, so there is motivation for the change. Configuring a tap interface to up by a non-superuser should only be permitted if the interface itself was created by a non-superuser, and if net.link.tap.user_open is set to 1. A more involved patch is needed to do this right for all cases -- we should not do this by default. Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tap(4) should go UP if opened
Bruce, thanks for your answer!
Bruce M. Simpson <[EMAIL PROTECTED]> wrote on 9 Mar 2007 12:30:
> 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 address, so
> > setting it up on open is IMHO the best solution.
> >
> This isn't consistent with the other software cloneable interfaces which
> emulate certain layer 2 semantics, e.g. bridge, trunk, vlan; see below.
May be, but we have for tap(4) the possibility to attach a non root user
process.
> I recently committed Landon Fuller's code which makes tap and tun
> cloneable interfaces which may then be created via 'ifconfig tap0 create'.
I appreciate that. :-) It was the reason to build a new 6.2 kernel and to try
to run the attached
process not as root.
> Automatically setting the interface to IFF_UP is not consistent with the
> semantics for other network interfaces; it requires specific privileges
> (usually super-user or PRIV_NET_SETIFFLAGS in -CURRENT) to do.
My idea is to set it to IFF_UP when the process _opens_ the interface. It can
happen only if
1. the process has root provileges OR
2. net.link.tap.user_open=1 AND special rights are set on /dev/tapx
> A more involved patch is needed to do this right for all cases -- we
> should not do this by default.
But when it is useful to open a tap device by a non root process, when the tap
is not IFF_UP?
May be my patch had not enough context to see immediately, where it fits into
the game. To
make it easier for the reviewers I show the complete function:
/*
* tapopen
*
* to open tunnel. must be superuser
*/
static int
tapopen(struct cdev *dev, int flag, int mode, struct thread *td)
{
struct tap_softc*tp = NULL;
struct ifnet*ifp = NULL;
int error, s;
if (tapuopen == 0) {
error = suser(td);
if (error != 0)
return (error);
}
if ((dev2unit(dev) & CLONE_UNITMASK) > TAPMAXUNIT)
return (ENXIO);
tp = dev->si_drv1;
mtx_lock(&tp->tap_mtx);
if (tp->tap_flags & TAP_OPEN) {
mtx_unlock(&tp->tap_mtx);
return (EBUSY);
}
bcopy(IFP2ENADDR(tp->tap_ifp), tp->ether_addr, sizeof(tp->ether_addr));
tp->tap_pid = td->td_proc->p_pid;
tp->tap_flags |= TAP_OPEN;
ifp = tp->tap_ifp;
mtx_unlock(&tp->tap_mtx);
s = splimp();
ifp->if_drv_flags |= IFF_DRV_RUNNING;
ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
ifp->if_flags |= IFF_UP;/* --- new line -- */
splx(s);
TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, minor(dev));
return (0);
} /* tapopen */
Regards,
Frank
--
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Assign IP address to which interface when using if_bridge(4)?
I see some problems with if_bridge(4) and want to investigate this further. But before I make further tests I want to be sure to have the right setup. I could not find any hints in the documentation including FreeBSD handbook. I have an ethernet device xl0 and want to create a if_bridge(4) to tap(4): ifconfig bridge0 create ifconfig bridge0 addm xl0 addm tap0 up Now I have 3 interfaces, to which of them should I assign the ip address? When searching for information I found both possibilities: 1. Assign the IP address to child interface (e.g. xl0) and use this also for routing setup. 2. Assign the address to bridge interface (bridge0) and use this as reference interface. I assume 1. is the right solution, because the bridge0 does not even create link-local addresses. Am I right? Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
malformed / oversized frame leads to loss of connectivity
(previously posted on freebsd-questions, but with no resolution) I get this error quite frequently on my pf firewall running 6.2 and it leads to loss of internet access. kernel: vr0: discard oversize frame (ether type 710a flags 3 len 1532 max 1514) vr0 is connected to my ISPs cable modem, ip address is provided by DHCP. Whenever I get this oversized (or maybe malformed) packet I need to reboot my machine to get back online, though sometimes just resetting (down, then up) the ethernet port works also. I get the same problem with rl network cards (previously reported by Jeremy Tay: "misc/63190: Realtek driver halts on oversized frame" , FreeBSD 5.1-RELEASE , http://lists.freebsd.org/pipermail/freebsd-bugs/2004-February/005534.html ) Reports with other ethernet cards: xl http://angel.kafazov.com/blog/?p=41 FreeBSD 6.1 sk : http://lists.freebsd.org/pipermail/freebsd-bugs/2004-September/008784.html 6.0 kern/71229 sis: http://lists.soekris.com/pipermail/soekris-tech/2006-January/009829.html 6.0 bge : http://www.mail-archive.com/freebsd-net@freebsd.org/msg21324.html sai ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wireless serer card that can handle multi-users
On Fri, 9 Mar 2007 14:10:45 +1100, Sam Wun wrote > Hi, > > About half year ago, I tested a mini wireless server card with > FreeBSD 6. The connection runs very fast if only myself using it, > but when there are more than 1 user connected to it, the second > user will suffer extremely slow wireless network connection. My > colleague also told me he also experienced that problem for his > clients. So he purchased a cheap D-Link Wireless access point for > his client rather than bundle the wireless access point > (card) in the freebsd router box. > > Can anyone tell me which wifi server card don't have that problem > when configured with freebsd? Assuming that you're talking about MiniPCI cards, you can use any based on the Atheros chipset. I believe most if not all currently shipping Atheros cards are supported in FreeBSD 6.2. I have personally been using Wistron CM9 for nearly a year now. As far as the problem you described, you could have been running mixed b/g mode causing protection bit to be set which effectively reduces the throughput of your wireless LAN. Yuri ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPv6 Book - Volume II
Hi, Last October we published a book on the KAME implementation and on IPv6 in general. The book is titled "IPv6 Core Protocols Implementation". We recently published Volume-II of this two-book series. Volume-II is titled "IPv6 Advanced Protocols Implementation". It is published by Morgan Kaufmann, ISBN 0123704790. The link is http://www.mkp.com. This book engages the readers in advanced topics such as IPv6 unicast routing, IPv6 multicasting, DNS, DHCPv6, Mobile IPv6, and security. Just like Volume-I, this book contains in-depth coverage on the specifications as well as line-by-line code walkthrough, which is similar in style to Steven's TCP/IP Illustrated Volume II. We would like to thank the FreeBSD community for helping making this book possible. In particular, we'd like to thank the developers Suzuki Shinsuke, David Borman, Daniel Hartmeier, Jeffrey Hsu, and George V. Neville-Neil for being our reviewers. We hope this book could become another useful contribution to the FreeBSD community. Thank you. -- Qing Li, JINMEI Tatuya, SHIMA Keiichi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em problems on supermicro 5015M-MT+
On Friday 09 March 2007 13:42, Sven Petai wrote: > On Friday 09 March 2007 01:50, Jack Vogel wrote: > > On 3/8/07, Sven Petai <[EMAIL PROTECTED]> wrote: > > > > I am not sure why the 32/64 bit architecture is making a difference, > > however, you have the 573 NIC, so before doing anything else run this DOS > > app, it will patch your eeprom if needed, the problem is a misprogramed > > MANC register that tends to eat packets when it shouldnt. > > the utility said the fix was not needed and symptoms didn't change either. > > > Please let me know if that helps. > > Oh, you arent using TSO by some chance are you? > > no damn I feel so stupid right now... it turns out that datacenter guys had just connected the 32 bit box to other switch than the 64 bit boxes and it never really occured to me to doublecheck that part of the story. It was really just the connection between the switches that was broken. sorry for the misinformation. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netisr_direct
On Thu, 8 Mar 2007, Dave Baukus wrote: What's the word on netisr_direct ? Do people typically enable this feature ? I always enable it, but have never measured it doing anything useful. Under light loads, it should reduce network latency and overheads by a microsecond or two (whatever it takes to do 2 context switches (hopefully the bug that made it take 4 context switches is fixed)), but then the latency is still much larger than a microsecond or two (50 uS is unusually good and 100's of uS are common) and the overhead doesn't matter. Under heavy loads, not using it is potentially better since not using it allows queue lengths to grow longer so that the queues get processed more efficiently in bursts. However, I think there is no explicit management of queue lengths or latencies now, so machines that are too fast probably gain by doing direct dispatch if possible, since with indirect dispatch they would do the context switches to and from the netisr fast enough to keep queue lengths usually <= 1. Bruce ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netisr_direct
On 3/8/07, Dave Baukus <[EMAIL PROTECTED]> wrote: What's the word on netisr_direct ? Do people typically enable this feature ? It really varies with workload. For a small number of streams I get much better throughput with it enabled for a 10GigE link. -Kip ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netisr_direct
University of Cambridge
On Thu, 8 Mar 2007, Dave Baukus wrote:
What's the word on netisr_direct ? Do people typically enable this feature ?
Direct dispatch is the default configuration for the network stack in FreeBSD
7.x. Many users have reported performance improvements, especially in high
packets-per-second receive environments. However, some users have reported
performance loss on some SMP systems with some workloads. Direct dispatch
will generally significantly lower the overhead of in-bound packet processing
in the network stack by avoiding context switches. It also introduces
parallelism in the in-bound network layer processing path by allowing
processing to occur in more than one thread at a time. However, you can see
reduced parallelism in some environments as the ithread no longer run
concurrently with the netisr. I would not use net.isr.direct in versions of
FreeBSD before 6.1, but it should be pretty safe for 6.1 and later.
Robert N M Watson
Computer Laboratory
University of Cambridge
net/netisr.c:
static int netisr_direct = 0;
SYSCTL_INT(_net_isr, OID_AUTO, direct, CTLFLAG_RW,
&netisr_direct, 0, "enable direct dispatch");
TUNABLE_INT("net.isr.direct", &netisr_direct);
/*
* Do direct dispatch only for MPSAFE netisrs (and
* only when enabled). Note that when a netisr is
* marked MPSAFE we permit multiple concurrent instances
* to run. We guarantee only the order in which
* packets are processed for each "dispatch point" in
* the system (i.e. call to netisr_dispatch or
* netisr_queue). This insures ordering of packets
* from an interface but does not guarantee ordering
* between multiple places in the system (e.g. IP
* dispatched from interfaces vs. IP queued from IPSec).
*/
if (netisr_direct && (ni->ni_flags & NETISR_MPSAFE)) {
isrstat.isrs_directed++;
/*
* NB: We used to drain the queue before handling
* the packet but now do not. Doing so here will
* not preserve ordering so instead we fallback to
* guaranteeing order only from dispatch points
* in the system (see above).
*/
ni->ni_handler(m);
--
Dave Baukus
[EMAIL PROTECTED]
972-479-2491
Fujitsu Network Communications
Richardson, Texas
USA
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: what is wrong with ipv6_defaultrouter ?
Jason Arnaute wrote: > --- "Bruce A. Mah" <[EMAIL PROTECTED]> wrote: > >> If memory serves me right, Jason Arnaute wrote: >>> (FreeBSD 6.2-RELEASE) >>> >>> I have two ipv6 related lines in my /etc/rc.conf: >>> >>> ifconfig_em0_alias0="inet6 XXX::2/48" >>> ipv6_defaultrouter="XXX::1" >>> >>> When I boot like this, I do not get a default ipv6 >>> route in my routing table. 'netstat -rn' shows me >> a >>> default route for ipv4, but no default route for >> ipv6. >> >> You probably want to replace that first line with: >> >> ipv6_ifconfig_em0="XXX::2/48" >> >> Also make sure to set ipv6_enable="YES". > > > But the ipv6 ifconfig and the ipv6 networking all work > fine without either of those changes. I'd prefer not > to fix anything that isn't broken ... There is a difference between "what I need to type after the system is up" and "what I need to add to rc.conf so that the boot scripts understand what I'm trying to do." Read the rc.conf man page, and particularly the ipv6_network_interfaces entry. > Are you suggesting that one or both of those changes > will cause the ipv6_defaultrouter declaration to > suddenly begin working ? You can't have a default route for an interface that isn't up, and you can't do IPv6 at boot without ipv6_enable, so yes, both are required. hth, Doug -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
