Looking for networking solution.
Hi guys. I am looking for solution I could implement on a link with a huge latency when ping replies can go up to a few hundred miliseconds, e.g sateliete links. What I was thinking about is some kind of virtual interface which could translate tcp to udp in one of the pears of the link and push the data it received from a 'normal' interface through the virtual interface without bothering about ack-timing. The receiving end would have a similar interface which would translate the udp data stream to tcp and then route it out to the internet. (normal network)tcp<-->virtual udp interface<>virtual udp interface<-->tcp(normal network) Is there something avaliable on FreeBSD that can be used for that purpose? Maybe someone is working on such a thing in CURRENT ? Any thoughts about that? Any sugestions for a solution? Regards, Marcin Jessa. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for networking solution.
Marcin, What is it you are trying to accomplish and/or solve here? Switching between UDP and TCP isn't going to have much impact on your problem if it is a function of a lower network layer. In a case where you have a questionable connection, TCP is really what you want, because UDP has a habit of saying "oh, can't get this packet to ya, sorry, see ya later, drop packet". In other words, UDP is more a hope for the best sort of situation, whereas TCP has built in retranmission, error checking, etc. Again, I'm not sure what exactly you are trying to accomplish with this idea? Ray At 11:45 AM 6/15/2005 +0200, Marcin Jessa wrote: | Hi guys. | | I am looking for solution I could implement on a link with a huge latency when ping replies can go up to a few hundred miliseconds, e.g sateliete links. | What I was thinking about is some kind of virtual interface which could translate tcp to udp in one of the pears of the link and push the data it received from a 'normal' interface through the virtual interface without bothering about ack-timing. | The receiving end would have a similar interface which would translate the udp data stream to tcp and then route it out to the internet. | (normal network)tcp<-->virtual udp interface<>virtual udp interface<-->tcp(normal network) | | Is there something avaliable on FreeBSD that can be used for that purpose? | Maybe someone is working on such a thing in CURRENT ? | Any thoughts about that? Any sugestions for a solution? | | | Regards, | Marcin Jessa. | | ___ | 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: Looking for networking solution.
On Thu, 16 Jun 2005 02:35:27 -0700 [EMAIL PROTECTED] wrote: > Marcin, > > What is it you are trying to accomplish and/or solve here? Switching > between > UDP and TCP isn't going to have much impact on your problem if it is a > function > of a lower network layer. > > In a case where you have a questionable connection, TCP is really what you > want, because UDP has a habit of saying "oh, can't get this packet to ya, > sorry, > see ya later, drop packet". In other words, UDP is more a hope for the best > sort of situation, whereas TCP has built in retranmission, error checking, > etc. > > Again, I'm not sure what exactly you are trying to accomplish with this > idea? I want to just dump all the packets between two satelite links without checking for ack back and forth which creates latency and long ping times. For that I want both the peers between satelite links to take care of that and be able to deal with routing the traffic flow out again. I am not sure what solution would be appropriate for that problem and I am very open for suggestions. What I want is a solution which does not requires 3.rd party software/hardware (I am aware of the existing ones). I want it to be able to run on FreeBSD. > > > At 11:45 AM 6/15/2005 +0200, Marcin Jessa wrote: > | Hi guys. > | > | I am looking for solution I could implement on a link with a huge latency > when > ping replies can go up to a few hundred miliseconds, e.g sateliete links. > | What I was thinking about is some kind of virtual interface which could > translate tcp to udp in one of the pears of the link and push the data it > received from a 'normal' interface through the virtual interface without > bothering about ack-timing. > | The receiving end would have a similar interface which would translate the > udp > data stream to tcp and then route it out to the internet. > | (normal network)tcp<-->virtual udp interface<>virtual udp > interface<-->tcp(normal network) > | > | Is there something avaliable on FreeBSD that can be used for that purpose? > | Maybe someone is working on such a thing in CURRENT ? > | Any thoughts about that? Any sugestions for a solution? > | > | > | Regards, > | Marcin Jessa. > | > | ___ > | 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]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPC between vimage instances?
Julian Elischer wrote: Being able to remove interfaces would be really great. Then I could create extra logging interfaces in each vimage and not worry about the cleanup nightmare afterwards. Right now, I have a lot of script code just to find and reuse old ngeth interfaces sitting around in the default vimage and if I'm to have two types of those interfaces (one for logging, that has one underlying netgraph tree structure, and one for test traffic, using another netgraph tree structure) it would likely be at least twice as much trouble. That's why I was looking for some other way of communicating between different vimages. "use the source Luke" I know it seems like a lot but the netgraph code and the networking interface code are relatively simple.. Well, I'm tempted to do that but I'm a bit scared it will turn out to be a major task - I mean, being able to remove network interfaces is a pretty useful feature so why hasn't it been implemented? Or has it really just not been high enough priority for anyone to bother with? >interface removal in 4.x was nt quite "finished" >there are several viewpoints from which th einterface is not quite removed. >(as you have found) >I can not remember the details as It all changed in 5.x Anyone else who can fill me in on the basic problem with interface removal under 4.x? What is it that doesn't work, what code (files) should I look at if I want to try and fix it? Regards, /Ragnar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64
On Wed, 15 Jun 2005, Marcel Moolenaar wrote:
On Jun 15, 2005, at 1:42 PM, Daniel Hartmeier wrote:
If I understand the problem correctly, there is an underlying
network-generic question I'd like to ask here.
When a function in the kernel gets passed a struct ip pointer, can it
assume that the struct ip object pointed to is properly aligned? Or
should it assume that this is not the case, and extract members more
carefully?
Yes. A struct ip pointer points, by definition, to a struct ip. All
structs are sufficiently aligned in C.
That entirely depends. If a struct ip pointer is constructed without
any form of casting, then one can assume that alignment is guaranteed.
The compiler guarantees to do so, except of course in this case:
the structure is defined as a packed structure. We, as the developers,
have told the compiler to *NOT* guarantee alignment of fields. We're
on our own and we miserably fail being on our own.
This case is not really different. Packed structs are, by definition,
still structs. All structs are sufficiently aligned in C. "Sufficiently"
just means that valid accesses to the struct are sufficiently aligned.
For arches with strict alignment requirements like ia64, this means
laboriously accessing the struct 1 byte at a time and combining the
results. So declaring a struct as packed when it doesn't need to be,
is mostly just a pessimization. For struct ip, this pessimization was
implemented in rev.1.20 of netinet/ip.h.
We can fix the access in pf of course, but if other functions rightfully
count on struct ip objects being properly aligned, this might simply
crash outside of pf, too.
I suppose the problems are that:
- pf makes invalid accesses like:
void foo(struct in_addr *iap); /* use *iap */
struct ip *ip;
foo(&ip->ip_src);
- the compiler doesn't diagnose the invalid access in the above. Since
*ip is packed, ip->ip_src in it isn't actually a struct in_addr -- it
is a packed struct in_addr, so it might not have sufficent alignment
to be a struct in_addr.
True. But since struct ip is defined as packed, nobody can assume proper
alignment of multi-byte fields and all code needs to be fixed if such
assumptions are being made.
This is a reason why packed structs should never be used. Programming is
too hard if &ip->ip_src doesn't work, and even if it did work it would
export the pessimal packing.
If ia64 is different from other 64-bit
architectures (of which I only know amd64, sparc64 and alpha), please
explain what alignment rules there are for u_int32_t.
ia64 is not different in this respect. That's why the bug is not
specific to ia64. Note that amd64 may not be a perfect reference
in this case because it's too much like i386, which does unaligned
loads and stores.
ia64 is different in that it actually traps misaligned accesses.
i486+'s can trap all misaligned accesses too, at least in user mode, but
alignment checking is rarely turned on and gcc has never supported it.
E.g., gcc has always copying structs like "struct foo { short x[16]; };".
This struct is only guaranteed to be 16-bit aligned, but gcc now uses
only 32-bit accesses to copy it. So it is an ABI requirement in practice
at least for alignment checking to not be enabled. gcc also exploits
this to not generate different code to access struct ip's when struct ip is
bogusly packed.
Bruce
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for networking solution.
On Wed, 2005-06-15 at 11:45 +0200, Marcin Jessa wrote: > I am looking for solution I could implement on a link with a huge latency > when ping replies can go up to a few hundred miliseconds, e.g sateliete links. > What I was thinking about is some kind of virtual interface which could > translate tcp to udp in one of the pears of the link and push the data it > received from a 'normal' interface through the virtual interface without > bothering about ack-timing. > The receiving end would have a similar interface which would translate the > udp data stream to tcp and then route it out to the internet. > (normal network)tcp<-->virtual udp interface<>virtual udp > interface<-->tcp(normal network) > > Is there something avaliable on FreeBSD that can be used for that purpose? > Maybe someone is working on such a thing in CURRENT ? > Any thoughts about that? Any sugestions for a solution? You want SCPS (the Space Communications Protocols Specification) software. Briefly, it fakes local TCP on either end while talking its own protocol over the high-latency link. I don't know if there is any open-source package available but there are certainly commercial solutions out there. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64
On Thu, 16 Jun 2005, Daniel Hartmeier wrote:
'packed', as I understand it, prohibits the compiler from inserting any
padding anywhere in the struct. That is, it guarantees that the total
size of a struct object equals the sum of the sizes of its members.
It also requires the complier to generate specially pessimized code to
access the struct. Otherwise even direct references like ip->ip_src
might trap.
As a consequence, individual members can't be aligned properly if that
would require padding in front of them. The compiler can (and must?)
still align the first member, i.e. the beginning of the struct object,
though, no?
No. This wouldn't be very useful, and wouldn't work right for things
like arrays of packed structs -- the individual structs would have to
be padded at the end since there can be no space between array elements,
but packed structs are supposed to be unpadded at the end too. You can
see that there is no alignment requirement for packed structs as a whole
by looking at assembler output -- for a packed struct ip there is a
.comm..,1 where the 1 says 1-byte alignment.
The IP header and the struct that represents it are defined very
^^^ were ...
carefully. It's no coincidence that ip_src/dst are placed where they
are:
struct ip {
u_int ip_hl:4,/* header length */
ip_v:4; /* version */
u_char ip_tos; /* type of service */
u_short ip_len; /* total length */
u_short ip_id; /* identification */
u_short ip_off; /* fragment offset field */
u_char ip_ttl; /* time to live */
u_char ip_p; /* protocol */
u_short ip_sum; /* checksum */
struct in_addr ip_src,ip_dst; /* source and dest address */
} __packed;
^^ ... before this bug
This guarantees that
struct ip h;
&h.ip_src == (char *)&h + 12
&h.ip_dst == (char *)&h + 16
i.e. they are both on 32-bit aligned if h itself is 32-bit aligned.
If you look at any example in sys/netinet where struct ip members are
accessed, you see direct access to both u_short and uint32_t members.
Nowhere does anyone memcpy, bcopy or char-wise-copy ip_src/dst, for
instance.
Except the compiler does this.
The issue also involves how the IP header is aligned within mbufs.
Functions usually get passed an mbuf pointer, and do
struct mbuf *m;
struct ip *ip = mtod(m, struct ip *);
and then happily access ip_src/dst without further alignment checks.
mtod() just does a dubious cast. It depends on the data already being
sufficiently aligned. For non-bogusly-packed IP headers this means
32-bit alignment (for the in_addr's).
It's not clear where the misaligned headers come from. At least with
gcc-3.3.3, I couldn't get a non-32-bit-aligned struct ip as a local
variable by putting a char variable or char array before or after it.
gcc has obscure rules for reordering local variables to pack them
better, and this helps here. Padded structs withing (even unpadded)
structs can easily be misaligned depending on what is before them, but
struct ip's within structs seem to be rare. The one in ip_icmp.h is OK.
Bruce
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for networking solution.
On Thu, 16 Jun 2005 05:37:18 -0700 Frank Mayhar <[EMAIL PROTECTED]> wrote: > On Wed, 2005-06-15 at 11:45 +0200, Marcin Jessa wrote: > > I am looking for solution I could implement on a link with a huge latency > > when ping replies can go up to a few hundred miliseconds, e.g sateliete > > links. > > What I was thinking about is some kind of virtual interface which could > > translate tcp to udp in one of the pears of the link and push the data it > > received from a 'normal' interface through the virtual interface without > > bothering about ack-timing. > > The receiving end would have a similar interface which would translate the > > udp data stream to tcp and then route it out to the internet. > > (normal network)tcp<-->virtual udp interface<>virtual udp > > interface<-->tcp(normal network) > > > > Is there something avaliable on FreeBSD that can be used for that purpose? > > Maybe someone is working on such a thing in CURRENT ? > > Any thoughts about that? Any sugestions for a solution? > > You want SCPS (the Space Communications Protocols Specification) > software. Briefly, it fakes local TCP on either end while talking its > own protocol over the high-latency link. I don't know if there is any > open-source package available but there are certainly commercial > solutions out there. > -- Correct. That's why I asked about this problem here. I was in doubt something like that existed for FreeBSD. We are willing to pay someone to develop such a solution for FreeBSD. I'd love to get in touch with someone willing to pick up that challenge. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
port 80 listening than root user
Hello i want to know how can the www user listen on the port 80 rather than root or what is the the step or commade to take that allow the www user listen on port 80 i'm tryin to run my webserver (aolserver)for www from root but i keep the message cannot listen to port 80 permission denied. Please help , Thanks _ MSN Hotmail : antivirus et antispam intégrés http://www.msn.fr/newhotmail/Default.asp?Ath=f ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for networking solution.
> On Thu, 16 Jun 2005 05:37:18 -0700 > Frank Mayhar <[EMAIL PROTECTED]> wrote: > >> On Wed, 2005-06-15 at 11:45 +0200, Marcin Jessa wrote: >> > I am looking for solution I could implement on a link with a huge >> latency when ping replies can go up to a few hundred miliseconds, e.g >> sateliete links. >> > What I was thinking about is some kind of virtual interface which >> could translate tcp to udp in one of the pears of the link and push >> the data it received from a 'normal' interface through the virtual >> interface without bothering about ack-timing. >> > The receiving end would have a similar interface which would translate >> the udp data stream to tcp and then route it out to the internet. >> > (normal network)tcp<-->virtual udp interface<>virtual udp >> interface<-->tcp(normal network) >> > >> > Is there something avaliable on FreeBSD that can be used for that >> purpose? >> > Maybe someone is working on such a thing in CURRENT ? >> > Any thoughts about that? Any sugestions for a solution? >> >> You want SCPS (the Space Communications Protocols Specification) >> software. Briefly, it fakes local TCP on either end while talking its >> own protocol over the high-latency link. I don't know if there is any >> open-source package available but there are certainly commercial >> solutions out there. >> -- > > Correct. That's why I asked about this problem here. > I was in doubt something like that existed for FreeBSD. > We are willing to pay someone to develop such a solution for FreeBSD. > I'd love to get in touch with someone willing to pick up that challenge. > > someone forwarded me this link (offlist) and said they have a fbsd implementation of SCPS. I have no other details. http://www.xiplink.com/ jeff > > ___ > 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: Carp Suppression
On Wed, Jun 15, 2005 at 02:32:19PM -0400, Josh Kayse wrote: > On 6/15/05, Gleb Smirnoff <[EMAIL PROTECTED]> wrote: > > > AFAIU, you use PLIP line as some flag that triggers suppression. If > > slave "sees" master via PLIP, it keeps itself in slave mode. May be > > I don't understand you right. > > > > Although the idea is not officially supported, it is interesting. Can you > > please draw your setup, since I don't understand it clearly? > > > __ > em0 ||em1 > | FW1|--- > |_| >xl0(carp0)| | plip0(carp1) > ___|___|___ > em0 | | em1 > ---| FW2 |-- >|__| > > > Bridging is done through em0/em1 which are both monitored by ifstated > for link state only (backported patch from HEAD). > > When one of the bridging ports is disconnected, ifstaded changes the > advskew of carp0 and carp1 to 254 so that the carp interfaces > failover. > > When ifstated see the carp interfaces as BOTH master, the slave > firewall takes over bridging. > > This gives us redundant firewalls, with redundant heartbeat connections. In fact, not all network failures lead to detectable link loss. I can imagine a situation when the switch port FW1-em0 is connected to just hangs and so FW1 is unable to notice the event. If CARP ran on the em0 side of FW1 and FW2, they would notice such an event though due to CARP packets unable to flow between FW1-em0 and FW2-em0 any longer. The advantage of CARP used customarily and not on a separate "heartbeat" interface is that it provides active detection of failures on the very network that should be made fail-safe. -- Yar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: (panic) Lots of network memory needed
>
> I'm fairly sure that you are out of kernel virtual memory.
> Look at kern/kern_malloc.c kmeminit (); you can play w/ VM_KMEM_SIZE_MAX
> or TUNABLE_INT_FETCH("kern.vm.kmem.size", &vm_kmem_size);
>
> /*
> * Try to auto-tune the kernel memory size, so that it is
> * more applicable for a wider range of machine sizes.
> * On an X86, a VM_KMEM_SIZE_SCALE value of 4 is good, while
> * a VM_KMEM_SIZE of 12MB is a fair compromise. The
> * VM_KMEM_SIZE_MAX is dependent on the maximum KVA space
> * available, and on an X86 with a total KVA space of 256MB,
> * try to keep VM_KMEM_SIZE_MAX at 80MB or below.
> *
> * Note that the kmem_map is also used by the zone allocator,
> * so make sure that there is enough space.
> */
> vm_kmem_size = VM_KMEM_SIZE;
> mem_size = cnt.v_page_count * PAGE_SIZE;
Which version do you use? I see the following in my /sys/kern/kern_malloc.c:
vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE;
/*
* Limit kmem virtual size to twice the physical memory.
* This allows for kmem map sparseness, but limits the size
* to something sane. Be careful to not overflow the 32bit
* ints while doing the check.
*/
if (((vm_kmem_size / 2) / PAGE_SIZE) > cnt.v_page_count)
vm_kmem_size = 2 * cnt.v_page_count * PAGE_SIZE;
It's 5.4-p2
>
> #if defined(VM_KMEM_SIZE_SCALE)
> if ((mem_size / VM_KMEM_SIZE_SCALE) > vm_kmem_size)
> vm_kmem_size = mem_size / VM_KMEM_SIZE_SCALE;
> #endif
>
> #if defined(VM_KMEM_SIZE_MAX)
> if (vm_kmem_size >= VM_KMEM_SIZE_MAX)
> vm_kmem_size = VM_KMEM_SIZE_MAX;
> #endif
>
> /* Allow final override from the kernel environment */
> TUNABLE_INT_FETCH("kern.vm.kmem.size", &vm_kmem_size);
>
>
> Karim Fodil-Lemelin wrote:
> > Thanks but the system still crashes (FreeBSD 4.9) with 131072. Here is a
> > backtrace showing just that:
> >
> > Debugger (msg=0xc02b6cdb "panic") at ../../i386/i386/db_interface.c:321
> > 321 }
> > (kgdb) bt
> > #0 Debugger (msg=0xc02b6cdb "panic") at ../../i386/i386/db_interface.c:321
> > #1 0xc016a230 in panic (
> >fmt=0xc02ea380 "pmap_enter: invalid page directory pdir=%#llx,
> > va=%#x\n")
> >at ../../kern/kern_shutdown.c:593
> > #2 0xc0283594 in pmap_enter (pmap=0xc0340460, va=4292141056, m=0xc24b2848,
> >prot=7 '\a', wired=1) at ../../i386/i386/pmap.c:1943
> > #3 0xc023ddd0 in vm_fault (map=0xc033322c, vaddr=4292141056,
> >fault_type=7 '\a', fault_flags=1) at ../../vm/vm_fault.c:841
> > #4 0xc023df0a in vm_fault_wire (map=0xc033322c, start=4292141056,
> >end=4292149248) at ../../vm/vm_fault.c:915
> > #5 0xc0240831 in vm_map_pageable (map=0xc033322c, start=4292141056,
> >real_end=4292149248, new_pageable=0) at ../../vm/vm_map.c:1817
> > #6 0xc023ea25 in kmem_alloc (map=0xc033322c, size=8192)
> >at ../../vm/vm_kern.c:213
> > #7 0xc024a46f in _zget (z=0xdb5c6e80) at ../../vm/vm_zone.c:425
> > #8 0xc024a269 in zalloc (z=0xdb5c6e80) at ../../vm/vm_zone.c:60
> > #9 0xc0196106 in namei (ndp=0xfa489ef4) at ../../kern/vfs_lookup.c:104
> > #10 0xc01614ca in execve (p=0xfa482e00, uap=0xfa489f90)
> >at ../../kern/kern_exec.c:165
> > #11 0xc01590a1 in start_init (dummy=0x0) at ../../kern/init_main.c:543
> > (kgdb) p nmbclusters
> > $1 = 131072
> > (kgdb)
> >
> > Goran Spirovski - MorEl On.net wrote:
> >
> >> AFAIK the number of mbufs (and consequently nmbclusters) has to be a
> >> power
> >> of 2, so you should set it to 131072
> >>
> >> MorEl
> >>
> >> - Original Message - From: "Karim Fodil-Lemelin" <[EMAIL
> >> PROTECTED]>
> >> To:
> >> Sent: Wednesday, June 15, 2005 6:08 PM
> >> Subject: (panic) Lots of network memory needed
> >>
> >>
> >>
> >>
> >>> Hello,
> >>>
> >>> From kernel tuning page
> >>>
> >>
> >> (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kern
> >>
> >>
> >> el-limits.html)
> >>
> >>
> >>> Some sentence about nmbclusters says:
> >>>
> >>> "Under no circumstances should you specify an arbitrarily high value for
> >>>
> >>
> >> this parameter as it could lead to a boot time crash."
> >>
> >>
> >>> Now I want to push the limits where I need 4KB buffer for each of the
> >>>
> >>
> >> 32000 connections I want this server to handle. If I do the math:
> >>
> >>
> >>> (32000 (conns) * 4 (KB/buffer) * 2 (buffer/conn)) / 2048 (KB/cluster)
> >>>
> >>> = 128000 clusters
> >>>
> >>> So I set this arbitrary high value in loader.conf under
> >>>
> >>
> >> (kern.ipc.nmbclusters) and no surprises I get panic: pmap_enter
> >> invalid page
> >> directory pdir=0x3cb063, va=0xfff800
> >>
> >>
> >>> (va has a weird address here)
> >>>
> >>> I know I am pushing the limits here but I have plenty of memory (2GB) on
> >>>
> >>
> >> this system (after all its jus
Re: port 80 listening than root user
On 6/16/05, Mrad James Deane <[EMAIL PROTECTED]> wrote: > Hello i want to know how can the www user listen on the port 80 rather than > root or what is the the step or commade to take that allow the www user > listen on port 80 > i'm tryin to run my webserver (aolserver)for www from root but i keep the > message cannot listen to port 80 permission denied. > Please help , > Thanks > Does not AOLserver run as user nobody and group nobody by default on freebsd? Check the script /usr/local/etc/rc.d/aolserver.sh -- Kind regards Abu Khaled ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for networking solution.
Hi, At 13:47 16/06/2005, Marcin Jessa wrote: On Thu, 16 Jun 2005 05:37:18 -0700 Frank Mayhar <[EMAIL PROTECTED]> wrote: > > You want SCPS (the Space Communications Protocols Specification) > software. Briefly, it fakes local TCP on either end while talking its > own protocol over the high-latency link. I don't know if there is any > open-source package available but there are certainly commercial > solutions out there. > -- Correct. That's why I asked about this problem here. I was in doubt something like that existed for FreeBSD. We are willing to pay someone to develop such a solution for FreeBSD. I'd love to get in touch with someone willing to pick up that challenge. If you haven't done so, you might want to look at http://www.scps.org/scps/Reference_S_W/reference_s_w.html and see whether the reference implementation would be available for porting to FreeBSD. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PPPoE on virtual interfaces inside vimages?
Yet another complex question regarding vimage/netgraph :-) I'm trying to use the ppp program to do PPPoE on an ngeth interface without much luck. I'm using the following Netgraph tree setup: upper---link0 [fxp0] [ng_bridge] link2---ds [ng_vlan] vlan101--- ether [EMAIL PROTECTED] lower---link1 The physical ethernet interface fxp0 has setautosrc=0 configured and the ngeth interface has its own unique MAC address set. Packets sent out are thus tagged with VLAN id 101 and gets a certain MAC address. All of this behaviour is a necessity for the application we run (client simulations - The VLAN node actually has hundreds of upstream VLAN hooks connected to hundreds of ngeth interfaces in hundreds of vimages). Now, the ppp program uses Netgraph to connect to the "orphan" hook of a real ethernet interface, so when I try to run it in a vimage on the ngeth0 interface there it complains that the interface type is wrong (I have patched the kernel so it is possible to create ng_sockets inside any vimage so that's not a problem at least). It wants an ng_ether interface, with an "orphans" hook. Is it possible to have ppp connect to the ng_eiface (ngeth) interface instead of a real physical interface, and how should I do that? Or if not, what would be the best way to be able to do PPPoE inside a vimage, while simultaneously forcing VLAN-tagging and MAC address overwriting? Regards, /Ragnar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vr0 kernel panic
[DO NOT reply to random messages to post on new topics. I nearly missed this message.] On Thu, Jun 16, 2005 at 10:06:01AM +0400, Andrey Smagin wrote: > Hi ALL, > >panic: vr0f0: BUG: if_attach called without if_alloc'd input() > > Kernel panic after load, since about week in current. > Bad but solution: > load if_vr module and configure interface after all (in rc.d/ script). Please read /usr/src/UPDATING. It looks like you updated your kernel, but not modules. vr(4)'s attach routing looks correct by inspection and the interface works here. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp97alw7Opzs.pgp Description: PGP signature
Re: LVS FreeBSD port
On Thu, 16 Jun 2005, dragonfly dragonfly wrote: Recently i did a LVS FreeBSD port, and released 0.4.0 version (http://dragon.linux-vs.org/~dragonfly/htm/lvs_freebsd.htm). It supports LVS/DR and LVS/TUN with all LVS schedulers. Thanks must go to Clement Laforet for committing it to ports/net/ipvs. LVS(http://www.linuxvirtualserver.org/) is a widely used server cluster schedule system, which is be included in Linux official kernel 2.4 and 2.6 release. Tests, bug report and fix, comments are very welcome. Li Wang, This looks like very interesting work. I'm confused, however, by the need for a kernel patch here -- it looks like the changes essentially center on allowing kernel modules to register new socket option handlers for sockets, and that the socket pointer itself isn't handed into the socket option handlers. I don't have a very complete understanding of the LVS kernel code yet, but my impression is that maybe you could simply substitute a sysctl for each of the get and set options, and avoid a patch entirely? Or perhaps the goal here is to minimize modifications to the userland netfilter admin tool? Thanks, Robert N M Watson ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for networking solution.
Marcin Jessa wrote: > Frank Mayhar <[EMAIL PROTECTED]> wrote: ... >> You want SCPS (the Space Communications Protocols Specification) >> software. Briefly, it fakes local TCP on either end while talking >> its own protocol over the high-latency link. I don't know if there >> is any open-source package available but there are certainly >> commercial solutions out there. > > Correct. That's why I asked about this problem here. I was in doubt > something like that existed for FreeBSD. Yesterday I posted a mail about Tellitec. What I forgot to mention is that it runs on FreeBSD too. I'm sure Tellitec has a native FreeBSD binary, but the Linux binary I use at work also runs fine on FreeBSD. However, it is closed source, so : > We are willing to pay someone to develop such a solution for FreeBSD. > I'd love to get in touch with someone willing to pick up that challenge. I'm not sure it is what you're looking for. -- Hans Lambermont Disclaimer: I have a business relation to Tellitec. -- http://hans.dse.nl/ () ASCII-ribbon campaign against vCards, /\ HTML-mail and proprietary formats. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64
Daniel Hartmeier wrote this message on Thu, Jun 16, 2005 at 00:34 +0200: > So, are you really sure we should do differently in pf, instead of > looking for a bridge problem, where bridge constructs an mbuf with the > IP header not properly aligned? > > I.e. if the IP header is properly aligned within the mbuf (on 32-bit > boundaries, I presume), wouldn't ip_src/dst have to be properly aligned > as well, even though __packed is used, because the layout of struct ip > is chosen like that? This is a more general problem.. All of our ethernet drivers that run on aligned platforms have special code to offset by 2 the ethernet packet specificly so that struct ip and friends are properly aligned.. This is because the ethernet header is 14 bytes long, and if the data was left unchanged, the struct ip would start at x mod 4 = 2... of course, this is stupid, and each component that requires alignment when accepting a packet from another interface (i.e. pf taking in an mbuf from another system like bridge, or even the if stack) should use the m_copyup function that I committed a bit back.. This will give you correct alignment, and at the same time, make it continue to work if/when we finally decide to not have the ethernet drivers align packets... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (panic) Lots of network memory needed
I use FreeBSD 4.9. Actually I had to _reduce_ VM_KMEM_SIZE in order to
be able to create that much mnbclusters ...
Somehow it seems that vm_kmem_size cannot go over 1GB without crashing
the system so I had to reduce memory map from other subsystems in order
to get what I needed for network memory. From:
vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE;
Assuming vm_kmem_size has some sort of hard limit, if I reduce VM_KMEM_SIZE I
can get more nmbclusters into the system.
dima wrote:
I'm fairly sure that you are out of kernel virtual memory.
Look at kern/kern_malloc.c kmeminit (); you can play w/ VM_KMEM_SIZE_MAX
or TUNABLE_INT_FETCH("kern.vm.kmem.size", &vm_kmem_size);
/*
* Try to auto-tune the kernel memory size, so that it is
* more applicable for a wider range of machine sizes.
* On an X86, a VM_KMEM_SIZE_SCALE value of 4 is good, while
* a VM_KMEM_SIZE of 12MB is a fair compromise. The
* VM_KMEM_SIZE_MAX is dependent on the maximum KVA space
* available, and on an X86 with a total KVA space of 256MB,
* try to keep VM_KMEM_SIZE_MAX at 80MB or below.
*
* Note that the kmem_map is also used by the zone allocator,
* so make sure that there is enough space.
*/
vm_kmem_size = VM_KMEM_SIZE;
mem_size = cnt.v_page_count * PAGE_SIZE;
Which version do you use? I see the following in my /sys/kern/kern_malloc.c:
vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE;
/*
* Limit kmem virtual size to twice the physical memory.
* This allows for kmem map sparseness, but limits the size
* to something sane. Be careful to not overflow the 32bit
* ints while doing the check.
*/
if (((vm_kmem_size / 2) / PAGE_SIZE) > cnt.v_page_count)
vm_kmem_size = 2 * cnt.v_page_count * PAGE_SIZE;
It's 5.4-p2
#if defined(VM_KMEM_SIZE_SCALE)
if ((mem_size / VM_KMEM_SIZE_SCALE) > vm_kmem_size)
vm_kmem_size = mem_size / VM_KMEM_SIZE_SCALE;
#endif
#if defined(VM_KMEM_SIZE_MAX)
if (vm_kmem_size >= VM_KMEM_SIZE_MAX)
vm_kmem_size = VM_KMEM_SIZE_MAX;
#endif
/* Allow final override from the kernel environment */
TUNABLE_INT_FETCH("kern.vm.kmem.size", &vm_kmem_size);
Karim Fodil-Lemelin wrote:
Thanks but the system still crashes (FreeBSD 4.9) with 131072. Here is a
backtrace showing just that:
Debugger (msg=0xc02b6cdb "panic") at ../../i386/i386/db_interface.c:321
321 }
(kgdb) bt
#0 Debugger (msg=0xc02b6cdb "panic") at ../../i386/i386/db_interface.c:321
#1 0xc016a230 in panic (
fmt=0xc02ea380 "pmap_enter: invalid page directory pdir=%#llx,
va=%#x\n")
at ../../kern/kern_shutdown.c:593
#2 0xc0283594 in pmap_enter (pmap=0xc0340460, va=4292141056, m=0xc24b2848,
prot=7 '\a', wired=1) at ../../i386/i386/pmap.c:1943
#3 0xc023ddd0 in vm_fault (map=0xc033322c, vaddr=4292141056,
fault_type=7 '\a', fault_flags=1) at ../../vm/vm_fault.c:841
#4 0xc023df0a in vm_fault_wire (map=0xc033322c, start=4292141056,
end=4292149248) at ../../vm/vm_fault.c:915
#5 0xc0240831 in vm_map_pageable (map=0xc033322c, start=4292141056,
real_end=4292149248, new_pageable=0) at ../../vm/vm_map.c:1817
#6 0xc023ea25 in kmem_alloc (map=0xc033322c, size=8192)
at ../../vm/vm_kern.c:213
#7 0xc024a46f in _zget (z=0xdb5c6e80) at ../../vm/vm_zone.c:425
#8 0xc024a269 in zalloc (z=0xdb5c6e80) at ../../vm/vm_zone.c:60
#9 0xc0196106 in namei (ndp=0xfa489ef4) at ../../kern/vfs_lookup.c:104
#10 0xc01614ca in execve (p=0xfa482e00, uap=0xfa489f90)
at ../../kern/kern_exec.c:165
#11 0xc01590a1 in start_init (dummy=0x0) at ../../kern/init_main.c:543
(kgdb) p nmbclusters
$1 = 131072
(kgdb)
Goran Spirovski - MorEl On.net wrote:
AFAIK the number of mbufs (and consequently nmbclusters) has to be a
power
of 2, so you should set it to 131072
MorEl
- Original Message - From: "Karim Fodil-Lemelin" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, June 15, 2005 6:08 PM
Subject: (panic) Lots of network memory needed
Hello,
From kernel tuning page
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kern
el-limits.html)
Some sentence about nmbclusters says:
"Under no circumstances should you specify an arbitrarily high value for
this parameter as it could lead to a boot time crash."
Now I want to push the limits where I need 4KB buffer for each of the
32000 connections I want this server to handle. If I do the math:
(32000 (conns) * 4 (KB/buffer) * 2 (buffer/conn)) / 2048 (KB/cluster)
= 128000 clusters
So I set this arbitrary high value in loader.conf under
(kern.ipc.nmbclusters) and no surprises I get panic: pmap_enter
invalid page
directory pdir=0x3cb063, va=0xfff800
(va has a weird address here)
I know I am pushi
Problems with latest freevrrpd.
Hello. I have two FreeBSD 4.11 boxes which have been using freevrrpd for a long time. Today I upgraded from 0.8.7 to 0.9.3 and since then I started having some problems. Specifically I started to see this messages on both boxes: freevrrpd[822]: ip ttl of vrrp packet isn't set to 255. Packet is discar ded ! Strangest thing is that this boxes are both dual-homed, and one side (fxp1 below) was working correctly, the other not (fxp0 below), meaning that both boxed grabbed all configured address (yes, both master and backup). I googled around and found out that someone was having the same problem, but no solution was provided. Since I was in a hurry, I grabbed the sources, commented this test out in vrrp_misc_check_vrrp_packet, and recompiled. Since then everything seems to work correctly, but I didn't have the chance to test failover yet (!!!). Comments and/or suggestions? Furthermore, I'm frequently seeing the following messages: freevrrpd[2188]: all errors are cleared on interface fxp1 freevrrpd[2188]: all errors are cleared on interface fxp0 Is this normal? Or something worth looking at? Here is my conf: [VRID] serverid = 1 interface = fxp1 priority = 255 addr = 192.168.0.4/32 password = x [VRID] serverid = 2 interface = fxp1 priority = 254 addr = 192.168.0.5/32 password = x vridsdep=4 [VRID] serverid=3 interface=fxp0 priority=255 addr=192.168.101.5/32 password=x [VRID] serverid=4 interface=fxp0 priority=254 addr=192.168.101.6/32 password=x vridsdep=1 The one on the other box is just specular, only one interface is fxp0, the other xl0. P.S. Please remove .diesmapper to reply. Sorry I have to do this :( ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for networking solution.
> I want to just dump all the packets between two satelite links > without checking for ack back and forth which creates latency and > long ping times. The latency is created by the satellite transmission delay, not by the ack. ACK suffer from the latency, but do not create it. > Correct. That's why I asked about this problem here. > I was in doubt something like that existed for FreeBSD. > We are willing to pay someone to develop such a solution for FreeBSD. > I'd love to get in touch with someone willing to pick up that challenge. I doubt that anyone will be interested in developping a protocol that do not care about the reliability of transmission. Just saying "drop the ack" is not the way to go. If you are talking about a protocole that does dialogue (like email), suppressing the ack will not help: one end must wait until it receives one question before it can answer, and then the ack is transmitted in the same paket as the answer. If you are talking about a more "one way" protocol (like http for ex. request one file and then wait for the file to flow), a better a pproach would be to allow a bigger chunk of data to get through before the first ack is due (to fill the pipe). That can be done by increading the window size of TCP, without damaging the retransmission capabilities. As the window size change would need to b done in every client and server, we were once considering to put two reverse NAT at each end of the satellite link. The NAT being in charge of changing the window size (I don't remember the full details, but it looked feasible). Olivier ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vr0 kernel panic
Hello Brooks, Thursday, June 16, 2005, 8:51:14 PM, you wrote: BD> [DO NOT reply to random messages to post on new topics. I nearly missed BD> this message.] BD> On Thu, Jun 16, 2005 at 10:06:01AM +0400, Andrey Smagin wrote: >> Hi ALL, >> >>panic: vr0f0: BUG: if_attach called without if_alloc'd input() >> >> Kernel panic after load, since about week in current. >> Bad but solution: >> load if_vr module and configure interface after all (in rc.d/ script). BD> Please read /usr/src/UPDATING. It looks like you updated your kernel, BD> but not modules. vr(4)'s attach routing looks correct by inspection and BD> the interface works here. Ok. I am will check it all more complex. But about year i live on current. By cron every day at 2:30(Moscow) cvsup new sources and automaticaly build and install it. And i not touched configs last few month. Today new build also panic reboots at vr0. Bad news for me that i updated my server, and it also hang's on boot. Server have no vr at all, then because i think that problem not in vr driver. Server have no monitor i can't look point of crash now. Now i use kernel.old. Present some incompatibles with world, but system work anyway. BD> -- Brooks -- Best regards, Andreymailto:[EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
