Re: Mpd with a large number, 200+ , of bundles
> > Hmm.. well, we should try to pick this apart one problem at a time. > > If you can get mpd into a state where "kill -9" doesn't kill it, > then that seems like a kernel bug to me, and so we should probably > hone in on that first.. maybe we can come up with a simple test > case, e.g. using the event library debug output, write a program > that opens the same number of file descriptors, pipes, etc. and > registers the same event handlers, etc.. > I think I've got a solution, insert '#define FD_SETSIZE 2048' at the top of 'event.c', over '#include '. This seems to solve the problem for me, for now :) Trond To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: SecureID (was 802.1x)
> > > > This one is pretty critical. If you can't support SecurID passwords > > (60sec lifetime) then there are lots of sites that won't be > able to work > > with the system at all. We've already seen this problem > with the Cisco > > LEAP stuff. > > Does anyone else have secureID fobs running in FreeBSD based systems? > (if so I'd like to chat) That's exactly what I would like to achieve - I even fond on their web a note about supporting library for FreeBSD 2.2 with an offer for later version as "consulting service from RSA(labs)" (probably just to recompile). I would like to chat too, Thanks in advance, Milon -- [EMAIL PROTECTED] # ... speaking on my own! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: SecureID (was 802.1x)
We are running the SecureID clients on freeBSD 4.4 I don't think they have the server running on FreeBSD but we are just using a sun for that. The radiusd code has the option to link with their libraries so we did that.. that gives us a freebsd SecureID based radiusd. (it's the ascend radiusd) then we use the PAM pam_radius module to make everything else ask the radiusd for authentication... (therefore secureID ssh connections without changing any code.. or in fact any PAMified or radius capable server). Since they include the library in their FreeBSD package, I am thinking of making a direct SecureID PAM module so we can cut out the radiusd middleman. Julian On Wed, 14 Nov 2001, Milon Papezik wrote: > > > > > > This one is pretty critical. If you can't support SecurID passwords > > > (60sec lifetime) then there are lots of sites that won't be > > able to work > > > with the system at all. We've already seen this problem > > with the Cisco > > > LEAP stuff. > > > > Does anyone else have secureID fobs running in FreeBSD based systems? > > (if so I'd like to chat) > > That's exactly what I would like to achieve - I even fond on their web > a note about supporting library for FreeBSD 2.2 with an offer for later > version as "consulting service from RSA(labs)" (probably just to recompile). > > I would like to chat too, > > Thanks in advance, > Milon > -- > [EMAIL PROTECTED] > # ... speaking on my own! > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
tunneling with ipsec
hi, how can I setup tunneling firewall using ipsec or something alike? (need to use some ports which are prohibited). Do I have to have some computer behind firewall (unfirewalled) and some programs running on it also? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RFC: ipfirewall_forward patch
The following patch is expected to allow the forwarding of INCOMING packets to an arbitrary next hop controlled by the ipfw fwd command.. Ipfw 'fwd' at present has teh following restriction: only packets already leaving the system can be hijacked and forwarded to a 2nd machine. Incoming packets can only be forwarded to local addresses/port combinations. This patch would allow a sequence of mchines to hijack a particular conforming packet and pass it allong a chain of these machine sot make it fall out somewhere else.. the particular example I have in mind: [internet]---[A.b.c.d]---[10.2.3.4] \-[10.2.3.5] \-[10.2.3.6] \-[10.2.3.7] on A.b.c.d: ipfw add 1000 fwd 10.2.3.4 tcp from 0.0.0.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 ipfw add 1000 fwd 10.2.3.5 tcp from 0.0.1.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 ipfw add 1000 fwd 10.2.3.6 tcp from 0.0.2.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 ipfw add 1000 fwd 10.2.3.7 tcp from 0.0.3.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 and on each of the four machines: ipfw add 1000 fwd localhost tcp from any to A.b.c.d 80 in recv fxp0 this is a 4 -way load sharing setup sharing http load across 4 machines (in our case proxies) implemented in 5 lines of ipfw. To the external world it would look as if all requests are being satisfied by A.b.c.d:80. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: RFC: ipfirewall_forward patch
Oops forgot the patch.. here it is...
Julian Elischer wrote:
>
> The following patch is expected to
> allow the forwarding of INCOMING packets to an arbitrary next hop
> controlled by the ipfw fwd command..
>
> Ipfw 'fwd' at present has teh following restriction:
>
> only packets already leaving the system can be hijacked and forwarded
> to a 2nd machine. Incoming packets can only be forwarded to local
> addresses/port combinations.
>
> This patch would allow a sequence of mchines to hijack
> a particular conforming packet and pass it allong a chain of
> these machine sot make it fall out somewhere else..
>
> the particular example I have in mind:
>
> [internet]---[A.b.c.d]---[10.2.3.4]
>\-[10.2.3.5]
>\-[10.2.3.6]
>\-[10.2.3.7]
>
> on A.b.c.d:
> ipfw add 1000 fwd 10.2.3.4 tcp from 0.0.0.0:0.0.3.0 to A.b.c.d 80 in
> recv fxp0
> ipfw add 1000 fwd 10.2.3.5 tcp from 0.0.1.0:0.0.3.0 to A.b.c.d 80 in
> recv fxp0
> ipfw add 1000 fwd 10.2.3.6 tcp from 0.0.2.0:0.0.3.0 to A.b.c.d 80 in
> recv fxp0
> ipfw add 1000 fwd 10.2.3.7 tcp from 0.0.3.0:0.0.3.0 to A.b.c.d 80 in
> recv fxp0
>
> and on each of the four machines:
> ipfw add 1000 fwd localhost tcp from any to A.b.c.d 80 in recv fxp0
>
> this is a 4 -way load sharing setup sharing
> http load across 4 machines (in our case proxies)
>
> implemented in 5 lines of ipfw.
>
> To the external world it would look as if all requests are being
> satisfied
> by A.b.c.d:80.
diff -u ./ip_input.c /sys/netinet/ip_input.c
--- ./ip_input.cWed Aug 29 14:41:37 2001
+++ /sys/netinet/ip_input.c Wed Nov 14 15:41:20 2001
@@ -1587,21 +1587,29 @@
int error, type = 0, code = 0;
struct mbuf *mcopy;
n_long dest;
+ struct in_addr pkt_dst;
struct ifnet *destifp;
#ifdef IPSEC
struct ifnet dummyifp;
#endif
dest = 0;
+ /*
+* Cache the destination address of the packet; this may be
+* changed by use of 'ipfw fwd'.
+*/
+ pkt_dst = ip_fw_fwd_addr == NULL ?
+ ip->ip_dst : ip_fw_fwd_addr->sin_addr;
+
#ifdef DIAGNOSTIC
if (ipprintfs)
printf("forward: src %lx dst %lx ttl %x\n",
- (u_long)ip->ip_src.s_addr, (u_long)ip->ip_dst.s_addr,
+ (u_long)ip->ip_src.s_addr, (u_long)pkt_dst.s_addr,
ip->ip_ttl);
#endif
- if (m->m_flags & (M_BCAST|M_MCAST) || in_canforward(ip->ip_dst) == 0) {
+ if (m->m_flags & (M_BCAST|M_MCAST) || in_canforward(pkt_dst) == 0) {
ipstat.ips_cantforward++;
m_freem(m);
return;
@@ -1620,14 +1628,14 @@
sin = (struct sockaddr_in *)&ipforward_rt.ro_dst;
if ((rt = ipforward_rt.ro_rt) == 0 ||
- ip->ip_dst.s_addr != sin->sin_addr.s_addr) {
+ pkt_dst.s_addr != sin->sin_addr.s_addr) {
if (ipforward_rt.ro_rt) {
RTFREE(ipforward_rt.ro_rt);
ipforward_rt.ro_rt = 0;
}
sin->sin_family = AF_INET;
sin->sin_len = sizeof(*sin);
- sin->sin_addr = ip->ip_dst;
+ sin->sin_addr = pkt_dst;
rtalloc_ign(&ipforward_rt, RTF_PRCLONING);
if (ipforward_rt.ro_rt == 0) {
@@ -1674,7 +1682,7 @@
if (rt->rt_ifp == m->m_pkthdr.rcvif &&
(rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 &&
satosin(rt_key(rt))->sin_addr.s_addr != 0 &&
- ipsendredirects && !srcrt) {
+ ipsendredirects && !srcrt && !ip_fw_fwd_addr) {
#defineRTA(rt) ((struct in_ifaddr *)(rt->rt_ifa))
u_long src = ntohl(ip->ip_src.s_addr);
@@ -1683,7 +1691,7 @@
if (rt->rt_flags & RTF_GATEWAY)
dest = satosin(rt->rt_gateway)->sin_addr.s_addr;
else
- dest = ip->ip_dst.s_addr;
+ dest = pkt_dst.s_addr;
/* Router requirements says to only send host redirects */
type = ICMP_REDIRECT;
code = ICMP_REDIRECT_HOST;
diff -u ./ip_output.c /sys/netinet/ip_output.c
--- ./ip_output.c Wed Jul 18 23:37:26 2001
+++ /sys/netinet/ip_output.cWed Nov 14 15:41:14 2001
@@ -135,6 +135,7 @@
struct sockaddr_in *dst;
struct in_ifaddr *ia = NULL;
int isbroadcast, sw_csum;
+ struct in_addr pkt_dst;
#ifdef IPSEC
struct route iproute;
struct socket *so = NULL;
@@ -154,6 +155,9 @@
divert_cookie = 0;
#endif
+ pkt_dst = ip_fw_fwd_addr == NULL
+ ? ip->ip_dst : ip_fw_fwd_addr->sin_addr;
+
#if defined(IPFIREWALL) && defined(DUMMYNET)
/*
* dummynet packet are prepended a vestigial mbuf with
@@ -227,14 +231,14 @@
* and is still up. If not, free it and try again.
*/
Re: RFC: ipfirewall_forward patch
Julian Elischer wrote (on Nov 15): > Oops forgot the patch.. here it is... I almost replied to the first - too quick off the mark! > Julian Elischer wrote: > > Ipfw 'fwd' at present has teh following restriction: > > > > only packets already leaving the system can be hijacked and forwarded > > to a 2nd machine. Incoming packets can only be forwarded to local > > addresses/port combinations. My fault. I was being lazy when I wrote it. :) > > This patch would allow a sequence of mchines to hijack > > a particular conforming packet and pass it allong a chain of > > these machine sot make it fall out somewhere else.. It looks good. The ipfw syntax doesn't quite make sense to me. Also, are you requiring that they all be on the same ipfw rule number? Writing a script to probe a serving host and alter ipfw rules could be done seamlessly if they were on seperate ipfw rules. With a similar trick to move aliases around on a primary ether port, it's going to be a doddle to setup a clustered-transparent loadbalancer in FreeBSD now. Neat. :) Cheers, Chris. -- == [EMAIL PROTECTED]T: +44 845 333 0122 == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: RFC: ipfirewall_forward patch
Excuse me feollowing up to myself, but... Chrisy Luke wrote (on Nov 15): > It looks good. The ipfw syntax doesn't quite make sense to me. > Also, are you requiring that they all be on the same ipfw rule number? Ignore this. Just occured to me you're sharing load based on a netmask. A small state cache and we could do this dynamically, based on some metric. hmm. I'll go to sleep now. Chris. -- == [EMAIL PROTECTED]T: +44 845 333 0122 == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: RFC: ipfirewall_forward patch
On Thu, 15 Nov 2001, Chrisy Luke wrote: > > > only packets already leaving the system can be hijacked and forwarded > > > to a 2nd machine. Incoming packets can only be forwarded to local > > > addresses/port combinations. > > My fault. I was being lazy when I wrote it. :) Ah it WAS you I committed it for wasn't it? :-) > > > > This patch would allow a sequence of mchines to hijack > > > a particular conforming packet and pass it allong a chain of > > > these machine sot make it fall out somewhere else.. > > It looks good. The ipfw syntax doesn't quite make sense to me. They all have different bits masked by the netmask.. > Also, are you requiring that they all be on the same ipfw rule number? No, I was lazy.. (cut'n'pasted the rules) > > Writing a script to probe a serving host and alter ipfw rules could be > done seamlessly if they were on seperate ipfw rules. well sure.. it's the mechanism not the details I was looking at.. Can you check my logic on the changes.? I'll be testing it more tonight.. > > With a similar trick to move aliases around on a primary ether port, > it's going to be a doddle to setup a clustered-transparent loadbalancer > in FreeBSD now. Neat. :) that's the theory.. Why make a huge complicated program to do it when you can do it with ipfw :-) > > Cheers, > Chris. > -- > == [EMAIL PROTECTED]T: +44 845 333 0122 > == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Mpd with a large number, 200+ , of bundles
Trond Davidsen writes: > > If you can get mpd into a state where "kill -9" doesn't kill it, > > then that seems like a kernel bug to me, and so we should probably > > hone in on that first.. maybe we can come up with a simple test > > case, e.g. using the event library debug output, write a program > > that opens the same number of file descriptors, pipes, etc. and > > registers the same event handlers, etc.. > > I think I've got a solution, insert '#define FD_SETSIZE 2048' at the top > of 'event.c', over '#include '. This seems to solve the > problem for me, for now :) Ah, good sleuthing! You might also want to apply the patch below as a safety measure. Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: event.c === RCS file: /home/cvs/archie/mpd/src/event.c,v retrieving revision 1.2 diff -u -r1.2 event.c --- event.c 2001/06/16 05:07:55 1.2 +++ event.c 2001/11/14 21:04:24 @@ -444,6 +444,8 @@ case EVENT_READ: case EVENT_WRITE: case EVENT_EXCEPTION: + bad = (val < 0) || val >= FD_SETSIZE; + break; case EVENT_TIMEOUT: bad = (val < 0); break; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
