Re: Linux compatibility and /dev/null
What gives? ls -l /dev/null says: crw-rw-rw- 1 root wheel2, 2 Oct 9 12:45 /dev/null As it should. That's groovy. But what about /compat/linux/dev/null? -rw-r--r-- 1 root wheel 0 Oct 2 17:59 /compat/linux/dev/null Huh??! A _file_??! It should be a device! Hmm??? Doing chmod 666 /compat/linux/dev/null fixes the problem. Temporarily only. A better workaround is rm /compat/linux/dev/null; mknod /compat/linux/dev/null c 2 2 root:wheel. With your solution, that file may fill up with unwanted junk. This looks like a bug in the linux-base port. I'll file a PR. Indeed. Good move. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Linux compatibility and /dev/null
Hi: I was trying to get my linux-mozilla-1.1 to spawn off acroread when I click on PDF links, but I kept getting this: /usr/local/bin/acroread5: /dev/null: Permission denied I played with the acroread5 script and added, at the beginning, echo hi /dev/null and got: + echo hi /home/bwithrow/bin/acroread5: /dev/null: Permission denied What gives? ls -l /dev/null says: crw-rw-rw- 1 root wheel2, 2 Oct 9 12:45 /dev/null That's groovy. But what about /compat/linux/dev/null? -rw-r--r-- 1 root wheel 0 Oct 2 17:59 /compat/linux/dev/null Hmm??? Doing chmod 666 /compat/linux/dev/null fixes the problem. This looks like a bug in the linux-base port. I'll file a PR. -- Robert Withrow, [EMAIL PROTECTED], +1 978 288 8256, ESN 248 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Linux compatibility and /dev/null
On Thu, Oct 17, 2002 at 09:53:37AM -0400, Robert Withrow wrote:
Hmm??? Doing chmod 666 /compat/linux/dev/null fixes the problem.
This looks like a bug in the linux-base port. I'll file a PR.
The port already does this:
#
# Make sure we have a /dev/null in the chrooted environment.
${MKDIR} ${LINUXBASE}/dev
${RM} -f ${LINUXBASE}/dev/null
mknod ${LINUXBASE}/dev/null c 2 2
${CHMOD} 666 ${LINUXBASE}/dev/null
I don't know why yours didnt do that, but it certainly should have.
Kris
msg37623/pgp0.pgp
Description: PGP signature
Help with system panics
Attached are four single system panics.
Thanks for your assistance in this matter.
Frank Pilarcik
TheNETconnection!
build# uname -a
FreeBSD build.dp.net 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Tue Oct 15 15:18:27 EDT 2002
[EMAIL PROTECTED]:/usr/src/sys/compile/MAIL i386
build# gdb -k kernel.debug vmcore.4
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...
IdlePTD at phsyical address 0x00334000
initial pcb at physical address 0x002a68a0
panicstr: privileged instruction fault
panic messages:
---
Fatal trap 1: privileged instruction fault while in kernel mode
instruction pointer = 0x8:0xc019090c
stack pointer = 0x10:0xd79d3c90
frame pointer = 0x10:0xd79d3cd8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 82860 (crashme)
interrupt mask = none
trap number = 1
panic: privileged instruction fault
syncing disks... 12 1
done
Uptime: 12h36m56s
dumping to dev #da/0x20001, offset 7143440
dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492
491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471
470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450
449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429
428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408
407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387
386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366
365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345
344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324
323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303
302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282
281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261
260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240
239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219
218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198
197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177
176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156
155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135
134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114
113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90
89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61
60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../kern/kern_shutdown.c:474
474 ../../kern/kern_shutdown.c: No such file or directory.
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:474
#1 0xc016818b in boot (howto=256) at ../../kern/kern_shutdown.c:313
#2 0xc0168585 in panic (fmt=0xc027924c %s) at ../../kern/kern_shutdown.c:582
#3 0xc0235adf in trap_fatal (frame=0xd79d3c50, eva=0) at ../../i386/i386/trap.c:956
#4 0xc02354c2 in trap (frame={tf_fs = 16, tf_es = -1070923760, tf_ds = -1072300016,
tf_edi = -677560568, tf_esi = -678186368,
tf_ebp = -677561128, tf_isp = -677561220, tf_ebx = 0, tf_edx = -678186368,
tf_ecx = -677560588, tf_eax = 0, tf_trapno = 1,
tf_err = 0, tf_eip = -1072101108, tf_cs = 8, tf_eflags = 66118, tf_esp =
-1072099528, tf_ss = -678186368})
at ../../i386/i386/trap.c:618
#5 0xc019090c in cache_lookup (dvp=0xd79d3d1c, vpp=0xd79d3d2c, cnp=0xc0193fcd) at
../../kern/vfs_cache.c:155
#6 0xc01f2c91 in ufs_vnoperate (ap=0xd79d3d1c) at ../../ufs/ufs/ufs_vnops.c:2423
#7 0xc0193fcd in lookup (ndp=0xd79d3ee0) at vnode_if.h:52
#8 0xc0193ac8 in namei (ndp=0xd79d3ee0) at ../../kern/vfs_lookup.c:153
#9 0xc015f76a in execve (p=0xd799f5e0, uap=0xd79d3f80) at ../../kern/kern_exec.c:165
#10 0xc0235da9 in syscall2 (frame={tf_fs = 571408431, tf_es = -1071382481, tf_ds =
-1042415569, tf_edi = 1787, tf_esi = -1077937492,
tf_ebp = -1077937436, tf_isp = -677560364, tf_ebx = 672044644, tf_edx =
-1077937392, tf_ecx = 7, tf_eax = 59, tf_trapno = 12,
tf_err = 2, tf_eip = 671750128, tf_cs = 31, tf_eflags = 659, tf_esp =
-1077937512, tf_ss = 47}) at
Re: Linux compatibility and /dev/null
Mark Murray wrote: -rw-r--r-- 1 root wheel 0 Oct 2 17:59 /compat/linux/dev/null Huh??! A _file_??! It should be a device! Definitely wrong. Hmm??? Doing chmod 666 /compat/linux/dev/null fixes the problem. Temporarily only. A better workaround is rm /compat/linux/dev/null; mknod /compat/linux/dev/null c 2 2 root:wheel. With your solution, that file may fill up with unwanted junk. Why not just remove it? If you remove it, the device will be looked up in the system directory instead, and it will get the real /dev/null instead of the compat version. There aren't supposed to be semantic differences between FreeBSD and Linux, for /dev/null. It sounds instead like there is a problem with the union of / and /compat/linux for xxx redirects... certain kinds of opens. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Linux compatibility and /dev/null
[EMAIL PROTECTED] said:
:- Why not just remove it?
I re-installed linux_base and that *did* remove it. And, as Terry
suggests, acroread works fine without it. In fact there is no
/compat/linux/dev directory at all after the reinstall.
I don't have a clue how that file got created in the first place, except
to guess that it is a side effect of installing some port.
Also, Kris points out that the Makefile for the linux_base port has
this in the do-install section
# Make sure we have a /dev/null in the chrooted environment.
@${MKDIR} ${LINUXBASE}/dev
@${RM} -f ${LINUXBASE}/dev/null
@mknod ${LINUXBASE}/dev/null c 2 2
@${CHMOD} 666 ${LINUXBASE}/dev/null
But, as I said above, there is no /compat/linux/dev after the install,
so you can color me confused.
--
Robert Withrow, [EMAIL PROTECTED], +1 978 288 8256, ESN 248
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Help with system panics
Frank C Pilarcik wrote:
Attached are four single system panics.
Thanks for your assistance in this matter.
-BEGIN #1
FreeBSD build.dp.net 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Tue Oct 15 15:18:27=
EDT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/MAIL i386
Fatal trap 1: privileged instruction fault while in kernel mode
===
#4 0xc02354c2 in trap (frame=3D{tf_fs =3D 16, tf_es =3D -1070923760, tf_ds=
=3D -1072300016, tf_edi =3D -677560568, tf_esi =3D -678186368,
tf_ebp =3D -677561128, tf_isp =3D -677561220, tf_ebx =3D 0, tf_edx =3D=
-678186368, tf_ecx =3D -677560588, tf_eax =3D 0, tf_trapno =3D 1,
tf_err =3D 0, tf_eip =3D -1072101108, tf_cs =3D 8, tf_eflags =3D=
66118, tf_esp =3D -1072099528, tf_ss =3D -678186368})
at ../../i386/i386/trap.c:618
===
Cause: NMI
Possible root causes:
o power failure NMI
Diagnostics:
o Is system compiled with POWERFAIL_NMI option, or not?
o Did NMI: power fail message appear on console in in
kernel log file?
o Did NMI ... going to debugger appear on console, an
drop you into the kernel debugger?
How to turn this on: Compile kernel with DDB option;
dorpping to the debugger is default on NMI for kernel
with debugger present.
Workaround and/or to get more information:
sysctl machdep.panic_on_nmi=0
Most likely cause: Installation of processor from one vendor in
a motherboard originally intended for use with a processor from
another vendor, without reflashing the BIOS to match the installed
CPU.
o Use of instruction not defined on processor by kernel
Diagnostics:
o Is system running BIOS services for suspend/power
management/etc.?
o Does CPU match BIOS implementation EXACTLY? If not,
this may be a priviledged instruction in code from
the BIOS, which is executing as a result of some
event for which the BIOS supposedly has control.
How to verify:
o Disassmble code at instruction counter at both faul
addresses... the one reported on the console, and the
one reported by GDB.
o Look for one of the following instructions, which are
priviledged instructions which are not available in
older IA-32 processors:
Pentium or better required:
CMPXCHG8B, CPUID, RDTSC, RDMSR, WRMSR, MMX
Pentium Pro or better required:
CMOV, FCMOV, FCOMI, RDPMC, UD2
Most likely cause: use of MMX instructions on non-MMX processor,
due to improper compilation flags (e.g. incorrect -march=
and/or kernel options).
NOTE: May also occur if you are running FreeBSD on an 386, and
you have not gone out of your way to build an 386 kernel, since
the 386 is no longer supported in the FreeBSD default distribution,
since it makes it obvious /dev/random is a crock.
END #1
BEGIN #2
FreeBSD build.dp.net 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Tue Oct 15 15:18:27=
EDT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/MAIL i386
Fatal trap 12: page fault while in kernel mode
===
#3 0xc0235adf in trap_fatal (frame=0xe1148d40, eva=2360299204) at
../../i386/i386/trap.c:956
#4 0xc023578d in trap_pfault (frame=0xe1148d40, usermode=0, eva=2360299204) at
../../i386/i386/trap.c:849
#5 0xc0235333 in trap (frame={tf_fs = -1072234480, tf_es = -1019674608, tf_ds =
-518782960, tf_edi = -518746240, tf_esi = 3,
tf_ebp = -518746328, tf_isp = -518746772, tf_ebx = -604554752, tf_edx =
-604554752, tf_ecx = -518782024, tf_eax = -518746624,
tf_trapno = 12, tf_err = 2, tf_eip = -1071678615, tf_cs = 8, tf_eflags =
66118, tf_esp = -1072302411, tf_ss = -1070934480})
at ../../i386/i386/trap.c:448
#6 0xc01f7b69 in kmem_malloc (map=0xdbf73a00, size=3776221056, flags=672044644)
at ../../vm/vm_kern.c:402
===
Cause: Page fault in kernel mode was not of a type serviceable in
kernel mode, or was, but servicing failed.
Possible root causes:
o Usermode fault in kernel address space (NOT PROBLEM)
NOTE: usermode is '0'
o Usermode fault in user space (UNLIKELY)
NOTE: usermode is '0'
Diagnostic: verify value of KERNBASE is = eva value; if
not, this is your problem.
NOTE: At one point, FreeBSD moved kernbase from 0xc000
to 0x8000; if this kernel is after the move, then you
are fine; otherwise, this is the problem.
o Kernel mode fault in user space (PROBABLE)
Diagnostic: In debugger, check value of 'map' and 'kernel_map';
if they are *not equal*, then this is the problem.
Failure modes:
o Inability to
umass bus scanning (or perhaps just a general prob with CAM?)
I have a usb mass storage device that supports multiple LUNs. It has two (mmc) 'drives' that can be mounted. When I insert the device, the usb subsystem finds the base device, and assigns da1 (da0 exists already) to the lun0 drive in the device. After a bit of experimentation, it turns out that if I manually 'camcontrol rescan 1:0:1 that the second drive is found and I can use it. Does the CAM system normally just assume one LUN and not bother looking for more? is this a problem with just usb devices? I have no multiple-lun scsi devices to test with... It is really not much of an issue now that I know to manually scan for the device after insertion, but well, enquiring minds want to know! Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: umass bus scanning (or perhaps just a general prob with CAM?)
On Thu, 17 Oct 2002, Fred Clift wrote: I have a usb mass storage device that supports multiple LUNs. It has two (mmc) 'drives' that can be mounted. When I insert the device, the usb (for the record - edited from /var/log/messages) umass0: STMicroelectronics JamP3 Portable Player, rev 1.10/0.50, addr 2 da1 at umass-sim0 bus 0 target 0 lun 0 da1: KBGear JamP3 Player 0.93 Removable Direct Access SCSI-2 device ... da2 at umass-sim0 bus 0 target 0 lun 1 da2: KBGear JamP3 Player 0.93 Removable Direct Access SCSI-2 device (da2:umass-sim0:0:0:1): READ(6)/WRITE(6) failed, minimum_cmd_size is increased to 10 ... Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Logitech iTouch Cordless Desktop
On Tue, 15 Oct 2002, Ian Cartwright wrote: I have been trying to get a Logitech Cordless Desktop to work with FreeBSD without success. The cordless desktop consists of: 1) Cordless Keyboard model number Y-RE20 2) Cordless Mouse model number M-RR63 3) RF Receiver for Keyboard and Mouse model number C-BD9-DUAL The iTouch stuff generally requires custom drivers, or doesn't quite act like a standard keyboard so the driver gets confused. Other people have run afoul of that equipment. You might try disabling the device resets in the psm driver and/or playing with the KBD_RESETDELAY and KBD_MAXWAIT kernel options. These are documented on the atkbdc man page. In general, though, avoid any gimmicky keyboards with non-Windows operating systems :-) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
tracing exec system call
What would be the best way to *capture* the execv system call at its entry point from user space? ptrace()? What would be a good way to inspect the command line args to execv *after* the path, etc., has been resolved? This is useful if one wants to monitor a process and all the system calls it makes and then disallow a few of them if suspicious. Thanks. -Ram To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tracing exec system call
Ramkumar Chinchani wrote: What would be the best way to *capture* the execv system call at its entry point from user space? ptrace()? What would be a good way to inspect the command line args to execv *after* the path, etc., has been resolved? Duplicate the path resolution process, and examine the results, before making the call. This is useful if one wants to monitor a process and all the system calls it makes and then disallow a few of them if suspicious. This is also useful for weenies who want to write rootkits, or to hide the fact that there are suspicious calls being made from any monitoring software loaded before the exploit was loaded, by capruring the suspicious events and calling the code directly, to avoid the monitoring. The answer is that you can replace any system call entry point with your own. If you want another approach, replace the standard execution class entry points with your own, using a loadable module, since they are pointers, and call through to the original pointers in order to do the real work. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware2 and simd instructions
is there anyway to lie to vmware2 about the processor installed? or a patch to vmmon to have it lie to the guest os about the processor installed? yes 17.10.2002; 19:32:37 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Netgraph TCP/IP
A while back someone was fishing for a project to take on and someone suggested a complete TCP/IP implementation in netgraph. I found the idea interesting and am considering taking a shot at it. My main goal in all this is to learn as much as possible and at this point I'm just reading. While this is a personal educational project, I figure I should propose it here and solicit comments/thoughts/suggestions on such a venture so that maybe the results might be usable by someone else. Thanks -- Steve Tremblett To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Netgraph TCP/IP
Steve Tremblett wrote: A while back someone was fishing for a project to take on and someone suggested a complete TCP/IP implementation in netgraph. I found the idea interesting and am considering taking a shot at it. My main goal in all this is to learn as much as possible and at this point I'm just reading. While this is a personal educational project, I figure I should propose it here and solicit comments/thoughts/suggestions on such a venture so that maybe the results might be usable by someone else. Start with just a TCP implementation, after exposing a raw IP interface as a netgraph node. This will make your life much easier. There is a lot of promiscuous knowledge in the code, both for packets on the way in, and packets on the way out. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Netgraph TCP/IP
I do not think that you need a raw IP netgraph node. Something similar already exists. Why not use the ng_ksocket in order to open a raw IP socket under your TCP node ? Vincent Le Jeudi 17 Octobre 2002 20:59, vous avez écrit : Steve Tremblett wrote: A while back someone was fishing for a project to take on and someone suggested a complete TCP/IP implementation in netgraph. I found the idea interesting and am considering taking a shot at it. My main goal in all this is to learn as much as possible and at this point I'm just reading. While this is a personal educational project, I figure I should propose it here and solicit comments/thoughts/suggestions on such a venture so that maybe the results might be usable by someone else. Start with just a TCP implementation, after exposing a raw IP interface as a netgraph node. This will make your life much easier. There is a lot of promiscuous knowledge in the code, both for packets on the way in, and packets on the way out. -- Terry 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-hackers in the body of the message
Re: Netgraph TCP/IP
Vincent Jardin wrote:
I do not think that you need a raw IP netgraph node. Something similar
already exists. Why not use the ng_ksocket in order to open a raw IP socket
under your TCP node ?
Because the packet will never get to your protocol processing, unless
you turn of standard TCP altogether, and even then, the pr_input will
not do the right thing for chaining the data up to a Netgraph node.
ip_input.c:
...
if (args.next_hop ip-ip_p == IPPROTO_TCP) {
/* TCP needs IPFORWARD info if available */
struct m_hdr tag;
tag.mh_type = MT_TAG;
tag.mh_flags = PACKET_TAG_IPFORWARD;
tag.mh_data = (caddr_t)args.next_hop;
tag.mh_next = m;
(*inetsw[ip_protox[ip-ip_p]].pr_input)(
(struct mbuf *)tag, hlen);
} else
(*inetsw[ip_protox[ip-ip_p]].pr_input)(m, hlen);
...
For this to work, you have to have a pr_input that glues into a
Netgraph entry point, so that IP packets of a specific protocol
type captured by the Netgraph node get passed to it.
There is also the m_pullup() issue of the TCP protocol that is
being passed IP datagrams which may be frags of TCP packets, in
order to get the full TCP header, with options.
Minimally, the approach has to be a seperate TCP stack, which is
given a different protocol number for the purposes of experiment,
so that you can have a duplicate TCP stack on both sides using
the normal mechanism, and replace it on one side with the Netgraph
version equivalen.
See the LRP implementation from Rice University, or the updated
port by Duke University. They both use this approach to run a
stack, and other primitives, in paralell on the system. That is
also why the code, as it sits in their source bases, would take
some work to integrate fully into FreeBSD (license issues aside)
as the default protocol processing path. Actually, it would take
much longer now that the SYN cache and the polling code has
obfuscated things.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Netgraph TCP/IP
On Thu, 17 Oct 2002, Terry Lambert wrote:
Vincent Jardin wrote:
I do not think that you need a raw IP netgraph node. Something similar
already exists. Why not use the ng_ksocket in order to open a raw IP socket
under your TCP node ?
Because the packet will never get to your protocol processing, unless
you turn of standard TCP altogether, and even then, the pr_input will
not do the right thing for chaining the data up to a Netgraph node.
ip_input.c:
...
if (args.next_hop ip-ip_p == IPPROTO_TCP) {
/* TCP needs IPFORWARD info if available */
struct m_hdr tag;
tag.mh_type = MT_TAG;
tag.mh_flags = PACKET_TAG_IPFORWARD;
tag.mh_data = (caddr_t)args.next_hop;
tag.mh_next = m;
(*inetsw[ip_protox[ip-ip_p]].pr_input)(
(struct mbuf *)tag, hlen);
} else
(*inetsw[ip_protox[ip-ip_p]].pr_input)(m, hlen);
...
This has been changed with the addition of the new OOB tag metadata
methods committed by sam Leffler a few days ago. This were specifically
designed to co-operate with the netgraph OOB data requirements. I will
be modifying netgraph over the next few weeks (I hope) to use the new
scheme. This will allow seamless flow of metadata between netgaph and
other networking components. (e.g. the 'fwd' info above)
For this to work, you have to have a pr_input that glues into a
Netgraph entry point, so that IP packets of a specific protocol
type captured by the Netgraph node get passed to it.
it will all fall into place with the new scheme, once I
have converted netgraph to use it.
There is also the m_pullup() issue of the TCP protocol that is
being passed IP datagrams which may be frags of TCP packets, in
order to get the full TCP header, with options.
The tcp code should handle this anyway.
Minimally, the approach has to be a seperate TCP stack, which is
given a different protocol number for the purposes of experiment,
so that you can have a duplicate TCP stack on both sides using
the normal mechanism, and replace it on one side with the Netgraph
version equivalen.
Not necessarily.. if each stack can 'reject' a packet.. (not mine).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Netgraph TCP/IP
Julian Elischer wrote: There is also the m_pullup() issue of the TCP protocol that is being passed IP datagrams which may be frags of TCP packets, in order to get the full TCP header, with options. The tcp code should handle this anyway. It should, but it won't. The issue is when you need to make a decision based on TCP packet contents, but you don't have a complete packet. The expected behaviour is to call m_pullup. For a Netgraph version of this, you will either need a context (there isn't one at that point -- it runs at NETISR), or you will need to be able to restart tcp_input(). The problem with that is that it's expensive. Effectively, you almost need to seperate out the frag code before, and assemble whole packets before going into the traditional tcp_input(). Lemon has some good idea in this area; so do I. I've got code here, where I've moved around some of the operations to delay computations until fill data is available (which would avoid recomputation). Minimally, the approach has to be a seperate TCP stack, which is given a different protocol number for the purposes of experiment, so that you can have a duplicate TCP stack on both sides using the normal mechanism, and replace it on one side with the Netgraph version equivalen. Not necessarily.. if each stack can 'reject' a packet.. (not mine). The problem with this one is that the packet in this case is TCP. Ideally, what you would like for the developement case is to be able to tag particular flows as going to one TCP stack vs. the other; then by examining the flow tag, youy would be able to decide where to handle the packet (this also implies moving the frag reassembly to a seperate layer). Then you could flag a flow, and have it dealt with that way. In FreeBSD's lower level code, though, IP flows aren't really treated as flows; this is partly an artifact of the routing code, itself, and partly an artifact if inpcbhash(), which is actually broken. The hash on iput for a flow vs. output on a flow allocation is also broken; consider, that you can make a connection on an outbound socket which is not bound, from a specific source IP address, with no specific source port, and the source port contention is handled globally, rather than locally -- thus limiting you to 65535 maximum outbound connections on a single machine (the number of ports in a single globally contended IP address space, despite the fact that your source IP was specified). What this adss up to is that if you want to run stacks in parallel, they can't share protocol numbers, because the code does not really distinguish them at the proper layer, but instead, distinguishes them off-by-one. This actually makes processing slower overall, as well; consider that the fast forwarding code does a lookup, which, on a miss, is then passed up to the TCP to do another lookup, rather than passing the lookup result as part of the context. What this basically means is that the hash entries for the values are not shared, with a single hit-per-flow, and the more fast forwarding you do, the slower normal processing goes. The same happens for the SYN cache context lookup. It basically really slows down the code, to not do the hash lower down, and then make the decision on the basis of the result of identifying the flow. In a general sense, what you would need to do to do what you suggest is to pass all packets through all possible stacks, until you hit the default one -- the standard TCP -- and rely on all the other stacks to not eat the packet. In practice, this means that every IP protocol, except TCP, ends up getting rewritten for Netgraph use, until TCP gets rewritten, and then your lookup is O(N*MAX(1,flow_count/hash_size)), where N is the number of IP protocols (TCP, UDP, RTP, etc.). Also, in practice, this still doubles the overhead for things that need to be pre-decided (flow identification for IP fast forwarding, DSR, splicing, etc.), and that none of these things can really be safely implemented as Netgraph modules. Yeah, it can be made to function correctly that way, but it won't function quickly. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Netgraph TCP/IP
Steve Tremblett writes: A while back someone was fishing for a project to take on and someone suggested a complete TCP/IP implementation in netgraph. I found the idea interesting and am considering taking a shot at it. My main goal in all this is to learn as much as possible and at this point I'm just reading. While this is a personal educational project, I figure I should propose it here and solicit comments/thoughts/suggestions on such a venture so that maybe the results might be usable by someone else. Are you intending to have this hook into the normal FreeBSD TCP/IP stack or be truly standalone? I read your question as the latter but others seem to read it as the former. If the latter, I'd suggest splitting it up into several netgraph nodes, eg.: | | | | | | ng_udpng_tcp \ / \ / ng_ip | | ng_arp | | | | ng_ether -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Radui card with FM tuner PV-BT878P +FM
On Thu, 2002-10-17 at 22:38, Mantas S. wrote: I got %subj% but I cannot find support fot this on FreeBSD. Yes, Linux have this, but maybe anyone had such card or smth. It is probably supported by the bktr device driver. You'll need a TV viewer app like fxtv too. If you want radio then xmradio is OK. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
