RE: Kernel hacking questions
On 10-Jun-2002 Arun Sharma wrote: 1. Can I use a SMP kernel and bring it up with just one CPU on a two CPU machine ? Hmm, on alpha you can, I don't think we support that on i386, but it would be easy enough to tweak. 2. How do I trace back funcname+offset to a particular line of C code ? I tried objdump -d and gcc -S, but it's not easy to read. I thought there was a way to get gcc to interleave the C code and the generated assembly. gdb's 'l *foo+0x34' works wonders. :) If you are stuck with a kernel.debug on current that gdb doesn't grok, you can use nm to extract the address of the function, add the offset, and use 'addr2line -e kernel.debug 0xc0yy'. I have a suspicion that in kern_mutex.c:510, if (td1-td_priority td-td_priority) there may be circumstances in which td1 could be pointing to memory that has been freed. I've got a bunch of panics which result in kernel mode page faults at 0xdead. That would certainly be interesting. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: kernel thread
I asked a very similar question a while ago (within at most two months I think). Try search for subject kernel daemon cleanup. -Zhihui On Tue, 11 Jun 2002, John Baldwin wrote: On 10-Jun-2002 Ferruccio Vitale wrote: Hi, how can I destroy a kernel thread that I previously created? Regards, You need to signal the kthread (kproc) somehow and have it call kthread_exit() to commit suicide. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kernel thread
Hiten Pandya wrote:
Ok, I cant find any man page called shutdown_kproc in either 4.3 or 4.4.
Anyway, he wants to destroy a thread, and not an internal daemon/process.
To destroy a kernel thread, you need to make use of the kthread_exit()
operation. It is prototyped as follows:
void kthread_exit(ecode);
The *ecode* arg to kthread_exit() is used to specify the return code of
the thread which you are going to terminate.
Additonal Information can be found from:
kthread(9) -- (available in FreeBSD 5.0)
sys/kthread.h
HTH.
Hiten
[EMAIL PROTECTED], [EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Ok, I found the way! :-)
On loading my kernel module, I call kthread_create to create the thread
(kproc_start is only a wrapper to it). Doing this, I also obtain the pid of new
process: this one enters in a loop as shown below:
while (var == 0) {
kproc_suspend_loop(procp);
.
tsleep(procp, PUSER, procslp, hz);
}
kthread_exit(0);
On unloading this module, I set to 1 'var' and let the thread exits.
I hope this the right way to do it.
Thanx to everyone, guy :-)
Ferruccio
PS: oohh my english..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
ASUS A7n266-E, nVidia nForce IGP-128 and SMBus
I moved this discussion to -hackers, as suggested. I tried -hardware, but, no response. I have an ASUS A7N266-E motherboard with the nVidia nForce IGP-128 Northbridge chip, nVidia nForce MCP Southbridge chip, and AMD XP 1800. # uname -a FreeBSD asus 4.6-RC FreeBSD 4.6-RC #8: Mon Jun 10 19:11:16 PDT 2002 \ root@asus:/usr/src/sys/compile/ASUS i386 The nVidia chip is not supported. I want to access the SMBus to add some devices. Of course, ASUS and nVidia will not provide the information necessary to do this easily! I have attached the output of pciconf -lv and dmesg w/ bootverbose. From a previos discussion, the smbus drivers provide the smbus attached to one of several busses, iicsmb, bti2c, intsmb, alsmb, ichsmb, amdsmb, or viapropm. The nearest one to my motherboard is: pci---amdpm---amdsmb---smbus---smb The nVidia chip is similar to the definitions in sys/pci/pcireg.h and from lm-sensors, rumored to be similar to the AMD-758 chipset. I tried patching sys/pci/amdpm.c to recognize the nVidia chip. No glory. The maps are at 0x10. Amdpm.c uses a map from 0x58 for the power management stuff. I guess, see below, the proper map is at 0x18. # pciconf -r pci0:1:1 0x00:0xff 0x01b410de 0x00b1 0x0c0500c1 0x0080 0x5001 0x5501 0x5101 0x 0x 0x 0x 0x0c111043 0x 0x0044 0x 0x01030105 0x0c111043 0xc0020001 0x 0x 0x 0x 0x 0x ... 0x 0x 0x 0x The chip has 3 map registers containing 0x5001, 0x5501, and 0x5101, respectively. These are map pointers. I assume these are physical addresses? How do I determine the block sizes? What is in these memory blocks? I cobbled together a kld from amdpm, smbus, etc. Loading it produced some information. But, I could not unload it and it did nothing... Also, the 0x5500 memory block was duplicated by some of the underlying code... One line from the console: SMBus0: NVidia nForce Power Management Controller port 0x5500-0x550f,0x5100-0x511f,0x5500-0x550f,0x5000-0x500f irq 5 at device 1.1 on pci0 I think the blocks are 5000:501f, 5500:550f, and 5100:511f. From sizes, I think the 5100:511f block is power management. If so, I can guess at some of the definitions. The PCIR_HEADERTYPE is 0x80. What is PCIM_MFDEV? Modified Device? The header appears to be a type 0 with PCIR_SUBVEND_2 and PCIR_SUBDEV_2 from the type 2 header. PCIR_CAP_PTR is the start of the capaility list, the the only capability lword being 0xc0020001. Where do I get the definition of this lword? tomdean pciconf -lv == chip0@pci0:0:0: class=0x06 card=0x chip=0x01a410de rev=0xb2 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce AGP Controller' class= bridge subclass = HOST-PCI none0@pci0:0:1: class=0x05 card=0x0c111043 chip=0x01ac10de rev=0xb2 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce 220/420 Memory Controller' class= memory subclass = RAM none1@pci0:0:2: class=0x05 card=0x0c111043 chip=0x01ad10de rev=0xb2 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce 220/420 Memory Controller' class= memory subclass = RAM none2@pci0:0:3: class=0x05 card=0x0c111043 chip=0x01ab10de rev=0xb2 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce 420 Memory Controller (DDR)' class= memory subclass = RAM isab0@pci0:1:0: class=0x060100 card=0x0c111043 chip=0x01b210de rev=0xc3 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce HUB Interface' class= bridge subclass = PCI-ISA none3@pci0:1:1: class=0x0c0500 card=0x0c111043 chip=0x01b410de rev=0xc1 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce SMBus Controller' class= serial bus subclass = SMBus ohci0@pci0:2:0: class=0x0c0310 card=0x0c111043 chip=0x01c210de rev=0xc3 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce OHCI USB Controller' class= serial bus subclass = USB ohci1@pci0:3:0: class=0x0c0310 card=0x0c111043 chip=0x01c210de rev=0xc3 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce OHCI USB Controller' class= serial bus subclass = USB pcib1@pci0:8:0: class=0x060400 card=0x0044 chip=0x01b810de rev=0xc2 hdr=0x01 vendor = 'Nvidia Corporation' device = 'nForce PCI Bridge' class= bridge subclass = PCI-PCI atapci0@pci0:9:0: class=0x01018a card=0x0c111043 chip=0x01bc10de rev=0xc3 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce ATA Controller' class= mass storage subclass = ATA pcib2@pci0:30:0:class=0x060400 card=0x chip=0x01b710de rev=0xb2 hdr=0x01 vendor = 'Nvidia Corporation' device = 'nForce AGP Host to PCI Bridge' class= bridge subclass = PCI-PCI rl0@pci1:2:0:
ptrace problem
Hi!
there is a problem in ptrace code or my understanding of how
it should work. man page says taht PT_DETACH acts same way
PT_CONTIUNE does, but when i try to detach from process with
PT_DETACH delayed? sigstop is delivered, and process becomes
suspended. Valid solution/workaround seems to be in calling
PT_CONTINUE with sigcont, and PT_DETACH after it.
Example is attached. Please cc me a reply:)
Thanks
#include stdio.h
#include unistd.h
#include sys/types.h
#include sys/ptrace.h
#include machine/reg.h
#include sys/wait.h
#include signal.h
#include errno.h
#include err.h
#define SIG(x) [SIG##x] SIG#x
char *sigtable[] = {
SIG(HUP), SIG(INT), SIG(QUIT), SIG(ILL),
SIG(ABRT), SIG(FPE), SIG(KILL), SIG(SEGV),
SIG(PIPE), SIG(ALRM), SIG(TERM), SIG(USR1),
SIG(USR2), SIG(CHLD), SIG(CONT), SIG(STOP),
SIG(TSTP), SIG(TTIN), SIG(TTOU), SIG(BUS),
SIG(XCPU), SIG(XFSZ)
};
void show (int status)
{
if (WIFEXITED (status))
printf (ex %d\n, WEXITSTATUS(status));
else if (WIFSIGNALED (status))
printf (ts %s\n, sigtable[WTERMSIG(status)]);
else if (WIFSTOPPED (status))
printf (ss %s\n, sigtable[WSTOPSIG(status)]);
return;
}
int main (int argc, char *argv[])
{
struct reg regs;
int status;
pid_t pid;
if (argc != 2) exit(1);
pid = atoi (argv[1]);
if (ptrace (PT_ATTACH, pid, 0, SIGCONT))
err (1, ptrace attach);
while (wait4(-1, status, WUNTRACED, NULL) != pid);
show (status);
if (ptrace (PT_GETREGS, pid, regs, NULL))
err (1, ptace getregs);
printf (attach ok, pc: %#lx\n, regs.r_eip);
/* uncomment this , it will wokr
ptrace (PT_CONTINUE, pid, 1, 17);
while (wait4(-1, status, WUNTRACED, NULL) != pid);
show (status);
*/
if (ptrace (PT_DETACH, pid, 1, 0))
err (1, ptrace detach);
else
printf (detach ok\n);
exit (1);
}
[no subject]
subscribe end -- Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] | Snail: PO Box 370 [EMAIL PROTECTED]|Belconnen ACT 2616 Web:http://www.andymac.org/|Australia To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
gif(4) tunnel through MSN DSL modem
Hi folks,
I tried this on -questions without any luck, so I'm hoping for a better
response here . :)
I remotely administer a FreeBSD 4.5 machine that is connected to the
internet through and MSN DSL modem. This modem does NAT (for a single
client) rather than bridging the connection. So the FreeBSD machine thinks
its public address is 192.168.1.2 (when in reality the modem is the only
device with a public address). This machine is itself doing NAT, acting as
a firewall and gateway for a private network.
I would like to establish a gif(4) tunnel between this machine and my
firewall here in order to link the two private networks into one virtual
network. I have done this before with two machines that were directly
connected to the internet, but in this case the DSL modem on the far end
seems to be fouling things up. The modem seems to be passing everything
through, but I haven't gotten gif to work.
Any ideas? Here's what I've tried--this is how I'd set it up if the DSL
modem weren't in the way.
[excerpts from rc.conf on far (DSL) end]
# Private interface
ifconfig_xl0=inet 192.168.6.1 netmask 255.255.255.0
# Public interface -- 192.168.1.2 netmask 255.255.255.252
ifconfig_ed0=DHCP
gif_interfaces=gif0
gifconfig_gif0=DSL.public.ip myend.public.ip
ifconfig_gif0=192.168.6.1 192.168.0.1
static_routes=john
route_john=-net 192.168.0 -interface gif0
[excerpts from rc.conf on this {my) end]
# Private interface
ifconfig_ep0=inet 192.168.0.1 netmask 255.255.255.0
# Public interface
ifconfig_ed0=DHCP
gif_interfaces=gif0
gifconfig_gif0=myend.public.ip DSL.public.ip
ifconfig_gif0=192.168.0.1 192.168.6.1
static_routes=DSL
route_DSL=-net 192.168.6 -interface gif0
I've tried both the modem's (real) public address and 192.168.1.1 (the
public interface's address) for DSL.public.ip, but neither seems to work.
Can this be made to work? Can gif be hacked so it will work?
I can't justify switching to a more expensive provider just so this tunnel
will work, since it will mostly be a convenience for me and not the client.
As far as I know, there's no way to modify any settings on the DSL modem
itself. I do have full access to both FreeBSD machines. Again, any
suggestions or even a detailed description of why this won't work would be
appreciated.
Thanks,
JN
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ptrace problem
silent wrote: Hi! there is a problem in ptrace code or my understanding of how it should work. man page says taht PT_DETACH acts same way PT_CONTIUNE does, but when i try to detach from process with PT_DETACH delayed? sigstop is delivered, and process becomes suspended. Valid solution/workaround seems to be in calling PT_CONTINUE with sigcont, and PT_DETACH after it. Example is attached. Please cc me a reply:) Thanks Does the patch in kern/35175 fix the problem? -- Peter Edwards, Openet Telecom. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gif(4) tunnel through MSN DSL modem
On Tue, 11 Jun 2002, John Nielsen wrote:
Hi folks,
I tried this on -questions without any luck, so I'm hoping for a better
response here . :)
I remotely administer a FreeBSD 4.5 machine that is connected to the
internet through and MSN DSL modem. This modem does NAT (for a single
client) rather than bridging the connection. So the FreeBSD machine
thinks its public address is 192.168.1.2 (when in reality the modem is
the only device with a public address). This machine is itself doing
NAT, acting as a firewall and gateway for a private network.
Why run nat on the internal machine? No need to do nat
twice. Just do basic routing between interfaces unless you need
this functionality.
I would like to establish a gif(4) tunnel between this machine and my
firewall here in order to link the two private networks into one
virtual network. I have done this before with two machines that were
directly connected to the internet, but in this case the DSL modem on
the far end seems to be fouling things up. The modem seems to be
passing everything through, but I haven't gotten gif to work.
Any ideas? Here's what I've tried--this is how I'd set it up if the
DSL modem weren't in the way.
Are you receiving any packets on the remote BSD machine that are
of type ipencap? Either log it via ipfw log or use a packet
sniffer (like tcpdump or snort) to evaluate these packets.
[excerpts from rc.conf on far (DSL) end]
# Private interface
ifconfig_xl0=inet 192.168.6.1 netmask 255.255.255.0
# Public interface -- 192.168.1.2 netmask 255.255.255.252
ifconfig_ed0=DHCP
gif_interfaces=gif0
gifconfig_gif0=DSL.public.ip myend.public.ip
ifconfig_gif0=192.168.6.1 192.168.0.1
static_routes=john
route_john=-net 192.168.0 -interface gif0
[excerpts from rc.conf on this {my) end]
# Private interface
ifconfig_ep0=inet 192.168.0.1 netmask 255.255.255.0
# Public interface
ifconfig_ed0=DHCP
gif_interfaces=gif0
gifconfig_gif0=myend.public.ip DSL.public.ip
ifconfig_gif0=192.168.0.1 192.168.6.1
static_routes=DSL
route_DSL=-net 192.168.6 -interface gif0
I've tried both the modem's (real) public address and 192.168.1.1 (the
public interface's address) for DSL.public.ip, but neither seems to
work. Can this be made to work? Can gif be hacked so it will work?
You will need to use the DSL's public IP probably.
I can't justify switching to a more expensive provider just so this
tunnel will work, since it will mostly be a convenience for me and not
the client. As far as I know, there's no way to modify any settings on
the DSL modem itself. I do have full access to both FreeBSD machines.
Again, any suggestions or even a detailed description of why this
won't work would be appreciated.
My best guess would be that the modem is doing some anti-spoofing
between it's interfaces to prevent packets coming from the inside
having it's outside IP. You will be able to tell if NO ipencap
packets are received on the remote BSD machine.
On the other hand, If you are receiving these ipencap packets on
the remote side, something else is going on (like nat
interrupting).
Nick Rogness [EMAIL PROTECTED]
- Don't mind me...I'm just sniffing your packets
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Çѹ¹Õé¤Ø³´ÙáÅÊØ¢ÀÒ¾áÅéÇËÃ×ÍÂѧ
á¹Ð¹Óâ»Ãá¡ÃÁ¤Çº¤ØÁ¹éÓ˹ѡ à¾ÔèÁ¹éÓ˹ѡ ÃÑ¡ÉÒÊØ¢ÀÒ¾ ¤Ø³ËÃ×ͤ¹·Õè¤Ø³ÃÑ¡¡ÓÅѧÁͧËÒÇÔ¸Õ´ÙáÅÊØ¢ÀÒ¾·Õèà»ç¹¸ÃÃÁªÒµÔÍÂÙèãªèäËÁ? ËÒ¡¤Ø³àº×èÍ˹èÒ¡Ѻ¤ÇÒÁ¾ÂÒÂÒÁ·ÕèäÁè»ÃÐʺ¤ÇÒÁÊÓàÃ稤ÃÑé§áÅéǤÃÑé§àÅèÒ ã¹¡ÒôÙáÅÊØ¢ÀÒ¾à¾×èÍÃÙ»ÃèÒ§·Õè´Õ àÃÒÁÕâ»Ãá¡ÃÁâÀª¹Ò¡ÒÃà¾×èÍÊØ¢ÀÒ¾ ·ÕèªèǤسä´é ÊÓËÃѺ¼Ùé·ÕèÁÕ»ÑËÒ ¹éÓ˹ѡà¡Ô¹ËÃ×ÍÍéǹ, ¼ÍÁà¡Ô¹ä», ÁÕ»ÑËÒÊØ¢ÀÒ¾ (¼ÍÁáËé§áç¹éÍÂ, ¾Ø§ËéÍÂÍ×´ÍÒ´, ¢Ò´¤ÇÒÁÁÑè¹ã¨, âäÀѶÒÁËÒ,ãºË¹éÒà»ç¹ÊÔÇ, ¼ÔǾÃóàËÕèÂÇÂè¹, ¤¹àÅ蹡ÕÌÒ, ¤Ø³»éÒÇÑ·ͧ, ¤Ø³¹éÍ§æ ·ÕèÍÂÒ¡ÊÇÂ)à»ç¹¼ÅÔµÀѳ±ì¨Ò¡¸ÃÃÁªÒµÔ 100 % äÁèãªèÂÒ äÁèµéͧʹÍÒËÒà äÁèÁռŢéÒ§à¤Õ§ äÁèµéͧÍÍ¡¡ÓÅѧ¡Ò ¿Ñ§´ÙäÁè¹èÒàª×èÍáµè¡çµéͧàª×èÍà¾ÃÒмèÒ¹ ÍÂ.·Ø¡»ÃÐà·È·Õèà¢éÒ仢ÒÂâ´Â੾ÒлÃÐà·Èä·ÂáÅÐÍàÁÃÔ¡Ò ãËéÊÒÃÍÒËÒäú¶éǹ »ÃѺÊÁ´ØŢͧÃèÒ§¡ÒÂÅ´ä¢ÁѹÊèǹà¡Ô¹ ÃѺÃͧ¼ÅÀÒÂã¹30Çѹ´éÇÂÃкº¤×¹à§Ô¹100%(á¾·Âì¼Ùé¤Ô´¤é¹ÍÒËÒÃÊٵùÕé¤×ͤ¹·Õè¤Ô´¤é¹ÍÒËÒÃãËé¹Ñ¡ºÔ¹ÍÇ¡ÒÈͧ¤ì¡ÒùҫèÒ) ʹ㨠¢Í¤Óá¹Ð¹Óà¾ÔèÁàµÔÁä´é·Õè ¤Ø³ÊÔÃÔ 01-8901701¾º¤ÓµÍºÊØ´·éÒ¢ͧ¤Ø³ä´é·Õè¹Õè http://www.smartslender.com/foodforhealth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: raidframe
On 6/10/02 6:07 PM, Terry Lambert [EMAIL PROTECTED] wrote: David O'Brien wrote: You quite speak for yourself. I've seen the FreeBSD community more split 50%-50% in their love-hate of Vinum. Many of us still use ccd(4) because Vinum did not meet our needs. Alfred Perlsteing claims Vinum comes from the universe where Spock has a beard (sorry, Greg!). Haha. :) I've had a similar love-hate relationship with vinum. Scott Long had just about ported RAIDframe to FreeBSD, when the bits got lost in a disk crash. So the rumor goes. In any case, it's not like an obscene amount of work had to have been invested by Scott Long to make the thing work, so duplicating it is not tantamount to searching for The Rosetta Stone. I still have Scott's work against -STABLE, I located a few bugs while he was working on it. I have a set of diffs that I maintain for servers here that runs under RELENG_4_5. In fact they also boot root off raidframe: /dev/raid0a 498M 230M 227M50%/ /dev/raid1e47G22G21G52%/usr I have had the time to see if they still work on the mainline stable branch, but I can probably bring them up-to-date. I've been meaning to merge in some of the more recent changes to raidframe from the NetBSD camp. Feel free to drop me a line and I'll let you poke at the patches, they seem pretty stable, I could always submit them as a PR too, but I shudder to think of the sort of flaming that would incur. -- William Carrel | Sr. Systems Engineer | [EMAIL PROTECTED] InfoSpace INC 601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Çѹ¹Õé¤Ø³´ÙáÅÊØ¢ÀÒ¾áÅéÇËÃ×ÍÂѧ
á¹Ð¹Óâ»Ãá¡ÃÁ¤Çº¤ØÁ¹éÓ˹ѡ à¾ÔèÁ¹éÓ˹ѡ ÃÑ¡ÉÒÊØ¢ÀÒ¾ ¤Ø³ËÃ×ͤ¹·Õè¤Ø³ÃÑ¡¡ÓÅѧÁͧËÒÇÔ¸Õ´ÙáÅÊØ¢ÀÒ¾·Õèà»ç¹¸ÃÃÁªÒµÔÍÂÙèãªèäËÁ? ËÒ¡¤Ø³àº×èÍ˹èÒ¡Ѻ¤ÇÒÁ¾ÂÒÂÒÁ·ÕèäÁè»ÃÐʺ¤ÇÒÁÊÓàÃ稤ÃÑé§áÅéǤÃÑé§àÅèÒ ã¹¡ÒôÙáÅÊØ¢ÀÒ¾à¾×èÍÃÙ»ÃèÒ§·Õè´Õ àÃÒÁÕâ»Ãá¡ÃÁâÀª¹Ò¡ÒÃà¾×èÍÊØ¢ÀÒ¾ ·ÕèªèǤسä´é ÊÓËÃѺ¼Ùé·ÕèÁÕ»ÑËÒ ¹éÓ˹ѡà¡Ô¹ËÃ×ÍÍéǹ, ¼ÍÁà¡Ô¹ä», ÁÕ»ÑËÒÊØ¢ÀÒ¾ (¼ÍÁáËé§áç¹éÍÂ, ¾Ø§ËéÍÂÍ×´ÍÒ´, ¢Ò´¤ÇÒÁÁÑè¹ã¨, âäÀѶÒÁËÒ,ãºË¹éÒà»ç¹ÊÔÇ, ¼ÔǾÃóàËÕèÂÇÂè¹, ¤¹àÅ蹡ÕÌÒ, ¤Ø³»éÒÇÑ·ͧ, ¤Ø³¹éÍ§æ ·ÕèÍÂÒ¡ÊÇÂ)à»ç¹¼ÅÔµÀѳ±ì¨Ò¡¸ÃÃÁªÒµÔ 100 % äÁèãªèÂÒ äÁèµéͧʹÍÒËÒà äÁèÁռŢéÒ§à¤Õ§ äÁèµéͧÍÍ¡¡ÓÅѧ¡Ò ¿Ñ§´ÙäÁè¹èÒàª×èÍáµè¡çµéͧàª×èÍà¾ÃÒмèÒ¹ ÍÂ.·Ø¡»ÃÐà·È·Õèà¢éÒ仢ÒÂâ´Â੾ÒлÃÐà·Èä·ÂáÅÐÍàÁÃÔ¡Ò ãËéÊÒÃÍÒËÒäú¶éǹ »ÃѺÊÁ´ØŢͧÃèÒ§¡ÒÂÅ´ä¢ÁѹÊèǹà¡Ô¹ ÃѺÃͧ¼ÅÀÒÂã¹30Çѹ´éÇÂÃкº¤×¹à§Ô¹100%(á¾·Âì¼Ùé¤Ô´¤é¹ÍÒËÒÃÊٵùÕé¤×ͤ¹·Õè¤Ô´¤é¹ÍÒËÒÃãËé¹Ñ¡ºÔ¹ÍÇ¡ÒÈͧ¤ì¡ÒùҫèÒ) ʹ㨠¢Í¤Óá¹Ð¹Óà¾ÔèÁàµÔÁä´é·Õè ¤Ø³ÊÔÃÔ 01-8901701¾º¤ÓµÍºÊØ´·éÒ¢ͧ¤Ø³ä´é·Õè¹Õè http://www.smartslender.com/foodforhealth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gif(4) tunnel through MSN DSL modem
John Nielsen wrote: [excerpts from rc.conf on far (DSL) end] # Private interface ifconfig_xl0=inet 192.168.6.1 netmask 255.255.255.0 # Public interface -- 192.168.1.2 netmask 255.255.255.252 ifconfig_ed0=DHCP gif_interfaces=gif0 gifconfig_gif0=DSL.public.ip myend.public.ip ifconfig_gif0=192.168.6.1 192.168.0.1 static_routes=john route_john=-net 192.168.0 -interface gif0 The problem (one part, at least) is that you use the same IP address (192.168.6.1) on your xl0 and gif0 interfaces (on both ends). You'll want the tunnel addresses to be in a different subnet. Also, the netmask in the infconfig_xl0 line doesn't match the comment, which one is wrong? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: gif(4) tunnel through MSN DSL modem
- Original Message - From: Lars Eggert [EMAIL PROTECTED] To: John Nielsen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 11, 2002 4:13 PM Subject: Re: gif(4) tunnel through MSN DSL modem John Nielsen wrote: [excerpts from rc.conf on far (DSL) end] # Private interface ifconfig_xl0=inet 192.168.6.1 netmask 255.255.255.0 # Public interface -- 192.168.1.2 netmask 255.255.255.252 ifconfig_ed0=DHCP gif_interfaces=gif0 gifconfig_gif0=DSL.public.ip myend.public.ip ifconfig_gif0=192.168.6.1 192.168.0.1 static_routes=john route_john=-net 192.168.0 -interface gif0 The problem (one part, at least) is that you use the same IP address (192.168.6.1) on your xl0 and gif0 interfaces (on both ends). You'll want the tunnel addresses to be in a different subnet. I have another tunnel set up this way and it works fine. Why should the tunnel addresses be on a different subnet? Also, the netmask in the infconfig_xl0 line doesn't match the comment, which one is wrong? The public interface (ed0) always gets the same address from the DSL modem, even though it's using DHCP. I think you associated the comment with the wrong ifconfig line (I've added a break between them to clarify). I'm starting to think that it would be easier to use ppp/tun and ssh rather than gif in this instance, even though I'm less familiar with that arrangement. JN To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gif(4) tunnel through MSN DSL modem
John Nielsen wrote: # Public interface -- 192.168.1.2 netmask 255.255.255.252 ifconfig_ed0=DHCP gif_interfaces=gif0 gifconfig_gif0=DSL.public.ip myend.public.ip ifconfig_gif0=192.168.6.1 192.168.0.1 static_routes=john route_john=-net 192.168.0 -interface gif0 The problem (one part, at least) is that you use the same IP address (192.168.6.1) on your xl0 and gif0 interfaces (on both ends). You'll want the tunnel addresses to be in a different subnet. I have another tunnel set up this way and it works fine. Why should the tunnel addresses be on a different subnet? Because your routing table will have an entry that says to reach net X use gateway Y, and there will appear to be multiple ways to reach gateway Y if you have multiple addresses attached to the same subnet. Also, assigning the same IP address to multiple interfaces is usually a bad idea. (It is useful in some setups, but this ain't one.) Add encapsulation, and you've a fine example of black hole due to infinite encapsulation. Also, the netmask in the infconfig_xl0 line doesn't match the comment, which one is wrong? The public interface (ed0) always gets the same address from the DSL modem, even though it's using DHCP. I think you associated the comment with the wrong ifconfig line (I've added a break between them to clarify). Oh, you're right, sorry. But then you're assigning the same IP address to THREE interfaces! I'm starting to think that it would be easier to use ppp/tun and ssh rather than gif in this instance, even though I'm less familiar with that arrangement. I'm willing to bet a beer that these problems will dissappear if you pick different subnets and IP addresses for your interfaces. This is a pretty straightforward setup. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
FreeBSD dev summit and USENIX photos available
I brought my camera to USENIX this year so I will be putting up photos as the conference goes on. No commentary this time, sorry, I only have two hands :-) The URL is: http://apollo.backplane.com/USENIX2002/ You can click on the photos for the full-sized version but be warned the full-sized photos are 2MB ea. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
