Re: Setting the mss for socket
Luiz Otavio O Souza escreveu: Hello hackers, Is there a way to set the mss for a socket ? Like you can do in linux with setsockopt(TCP_MAXSEG) ? So i can set the maximum size of packets (or sort of) from a simple userland program. I've read the code and i cannot find by myself (at least from a 30minute reading) a single point to change this. It looks like it is dynamic calculated with interface/path mtu. Someone has a simple approach to deal with this ? Any ideas ? Thanks in advance, Luiz Good point. With something like that it could be possible to make --mss switch from iperf work properly on FreeBSD. -- Patrick Tracanelli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UPEK/TouchChip Biometric Device problem
Maxim Konovalov wrote: On Tue, 26 Jun 2007, 15:40-0300, Patrick Tracanelli wrote: Maxim Konovalov wrote: On Fri, 22 Jun 2007, 17:42-0300, Patrick Tracanelli wrote: Hello all, I have used the mentioned devices on FreeBSD 5.4 in the past, and they worked just fine, but now I get problems with the same device, on top of 6.2-STABLE and also 7.0-CURRENT. [...] Just for the record: the above mentioned device works fine on lenovo x60s and 6.2-STABLE. Is it 0?0483 vendor and 0?2016 device? Which revision? Can you please send the relevant output from usbdevs -v and the ugen device from /var/run/dmesg.boot? port 2 addr 2: full speed, power 100 mA, config 1, Biometric Coprocessor(0x2016), STMicroelectronics(0x0483), rev 0.01 Controller /dev/usb4: ugen0: STMicroelectronics Biometric Coprocessor, rev 1.00/0.01, addr 2 Exactly the same. Did you do anything different from using securyt/bioapi, securiy/bsp_upektfmess and security/pam_bsdbioapi and creating birdb.conf? -- Patrick Tracanelli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPEK/TouchChip Biometric Device problem
Maxim Konovalov wrote: On Fri, 22 Jun 2007, 17:42-0300, Patrick Tracanelli wrote: Hello all, I have used the mentioned devices on FreeBSD 5.4 in the past, and they worked just fine, but now I get problems with the same device, on top of 6.2-STABLE and also 7.0-CURRENT. [...] Just for the record: the above mentioned device works fine on lenovo x60s and 6.2-STABLE. Is it 0×0483 vendor and 0×2016 device? Which revision? Can you please send the relevant output from usbdevs -v and the ugen device from /var/run/dmesg.boot? -- Patrick Tracanelli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPEK/TouchChip Biometric Device problem
First of all, can you turn on more debugging in your "bbdm"?
# bbdm -b "{5550454b-2054-464d-2f45-535320425350}" -m filedb -c eksffa ;
echo $?
usb_set_debug: Setting debugging level to 3 (on)
usb_os_find_busses: Found /dev/usb0
usb_os_find_busses: Found /dev/usb1
usb_os_find_busses: Found /dev/usb2
usb_os_find_busses: Found /dev/usb3
usb_os_find_busses: Found /dev/usb4
usb_os_find_devices: Found /dev/ugen1 on /dev/usb2
usb_control_msg: 128 6 512 0 0xbfbfdee8 8 1000
usb_control_msg: 128 6 512 0 0x8058a80 39 1000
usb_os_find_devices: Found /dev/ugen0 on /dev/usb4
usb_control_msg: 128 6 512 0 0xbfbfdee8 8 1000
usb_control_msg: 128 6 512 0 0x8055200 396 1000
skipping descriptor 0xB
skipped 1 class/vendor specific endpoint descriptors
skipped 5 class/vendor specific interface descriptors
skipping descriptor 0x25
skipped 1 class/vendor specific endpoint descriptors
skipped 7 class/vendor specific interface descriptors
usb_control_msg: 64 12 256 1024 0xbfbfdf80 1 100
usb_os_close: closing endpoint 14
usb_os_close: closing endpoint 15
bbdm: Failed to initate BSP {5550454b-2054-464d-2f45-535320425350}
If you have time you can also try the my new USB stack:
See:
http://www.turbocat.net/~hselasky/usb4bsd/
Download the SVN version.
If my new USB stack solves the problem then it is probably a regression issue
in 6.2-STABLE, and as I recall there have been lots of changes.
I did it. In fact I am running a kernel with your USB stack in this
minute, following the page instructions.
(I had, btw, 2 hunks ignored when patching, after "make install" but it
is ural, and you mention it as non critical. Anyway, it is not related).
Debug messages with the curret -STABLE stack or with your current USB
stack from this SVN seem to change very few, if anything.
What kind of platform are you using?
i386 right now.
Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPEK/TouchChip Biometric Device problem
Fredrik Lindberg wrote:
Patrick Tracanelli wrote:
All threads purged from ugen1.1
All threads purged from ugen1.2
All threads purged from ugen1.3
Harmless, as far as I know.
What is this about "threads purged"? Also, the port want
libintl.so.6 while 6.2-STABLE has libintl.so.8. I have tried 1)
linking .8 to .6 and also copied .6 from another system (also,
6.2-STABLE) to the current one. Didnt work both way. Same behavior,
exactly.
This is because of a gettext library bump, I just found out about it
(although it happened in march), and I have know good solution to it.
Installing an old version of gettext should of course work, but that's
ugly.
So, this has nothing to do with the fact that the device can not be
initiated?
This is _exactly_ the same device as you have been using in the past
with libtfmessbsp.so ?
No, not the same hardware, but same model/chipset.
Because if you try to use it with an unsupported device you'll get
the "unable to attach" message.
Its a 0x2016 device from 0x0483 vendor. This is the only thing that is
"the same" as the previously used device.
Those "All threads purged" have "always" been there, it appears
to happen with other devices as well
http://lists.freebsd.org/pipermail/freebsd-bugs/2006-May/018361.html
Since the binary is built on top of libusb you can turn on debugging
in libusb by setting the environment variable USB_DEBUG (the larger
value the more verbose debugging).
Goood hint,thank you.
Here is what I get:
# bbdm -b "{5550454b-2054-464d-2f45-535320425350}" -m filedb -c eksffa ;
echo $?
usb_set_debug: Setting debugging level to 3 (on)
usb_os_find_busses: Found /dev/usb0
usb_os_find_busses: Found /dev/usb1
usb_os_find_busses: Found /dev/usb2
usb_os_find_busses: Found /dev/usb3
usb_os_find_busses: Found /dev/usb4
usb_os_find_devices: Found /dev/ugen1 on /dev/usb2
usb_control_msg: 128 6 512 0 0xbfbfdee8 8 1000
usb_control_msg: 128 6 512 0 0x8058a80 39 1000
usb_os_find_devices: Found /dev/ugen0 on /dev/usb4
usb_control_msg: 128 6 512 0 0xbfbfdee8 8 1000
usb_control_msg: 128 6 512 0 0x8055200 396 1000
skipping descriptor 0xB
skipped 1 class/vendor specific endpoint descriptors
skipped 5 class/vendor specific interface descriptors
skipping descriptor 0x25
skipped 1 class/vendor specific endpoint descriptors
skipped 7 class/vendor specific interface descriptors
usb_control_msg: 64 12 256 1024 0xbfbfdf80 1 100
usb_os_close: closing endpoint 14
usb_os_close: closing endpoint 15
bbdm: Failed to initate BSP {5550454b-2054-464d-2f45-535320425350}
And debugging on /var/log/messages shows:
Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0
Jun 23 09:40:01 claire kernel: usb_cdev_close: closed
Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0
Jun 23 09:40:01 claire kernel: usb_cdev_close: closed
Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0
Jun 23 09:40:01 claire kernel: usb_cdev_close: closed
Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0
Jun 23 09:40:01 claire kernel: usb_cdev_close: closed
Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0
Jun 23 09:40:01 claire kernel: usb_cdev_close: closed
Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0
Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc8ef0220,
pipe=0xc5ee2000 len=10 dir=out
Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee2000
edesc=0xc5ee243f isoc_next=0 toggle_next=0 bEndpointAddress
=0x00
Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee2000
Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6bb5920,
pipe=0xc5ee2000 len=20 dir=out
Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee2000
edesc=0xc5ee243f isoc_next=0 toggle_next=0 bEndpointAddress
=0x00
Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee2000
Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6bb3720,
pipe=0xc5ee2000 len=10 dir=out
Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee2000
edesc=0xc5ee243f isoc_next=0 toggle_next=0 bEndpointAddress
=0x00
Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee2000
Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6bc0320,
pipe=0xc5ee2000 len=36 dir=out
Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee2000
edesc=0xc5ee243f isoc_next=0 toggle_next=0 bEndpointAddress
=0x00
Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee2000
Jun 23 09:40:01 claire kernel: usb_cdev_close: closed
Jun 23 09:40:01 claire kernel: usb_cdev_open: done, error=0
Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6b5d520,
pipe=0xc5ee9800 len=10 dir=out
Jun 23 09:40:01 claire kernel: usbd_dump_pipe: pipe=0xc5ee9800
edesc=0xc5ee9c3f isoc_next=0 toggle_next=0 bEndpointAddress
=0x00
Jun 23 09:40:01 claire kernel: usbd_dump_queue: pipe=0xc5ee9800
Jun 23 09:40:01 claire kernel: usbd_start_hardware: xfer=0xc6b58b20,
pipe=0xc5ee9800 len=20 dir=out
Re: UPEK/TouchChip Biometric Device problem
First, you cross-posted to way too many lists, ports@ would probably have been the most appropriate as this has nothing to do with FreeBSD itself. Believed it to be related to recent system changes. All threads purged from ugen1.1 All threads purged from ugen1.2 All threads purged from ugen1.3 Harmless, as far as I know. What is this about "threads purged"? Also, the port want libintl.so.6 while 6.2-STABLE has libintl.so.8. I have tried 1) linking .8 to .6 and also copied .6 from another system (also, 6.2-STABLE) to the current one. Didnt work both way. Same behavior, exactly. This is because of a gettext library bump, I just found out about it (although it happened in march), and I have know good solution to it. Installing an old version of gettext should of course work, but that's ugly. So, this has nothing to do with the fact that the device can not be initiated? On 7.0-CURRENT things are worse. libpthread is not found, and the same command core dumps. Anyway, 6.2-STABLE is more important to me right now, since I need this device to work on FreeBSD for an ongoing project, but if a solution to 7.0 happens first my work can move to that version. This is life with binary only, closed source applications. Things might have been slightly better if this was statically linked but unfortunately that's not the case. misc/compat6x should hopefully cover the threading though. Tried with, compat6x, no difference. Also tried with libpthread as denoted on current's /usr/src/UPDATING, also, same behavior. When I get some spare time, I'll try to ping my contact at UPEK, but last time I heard from them they were developing a new version but nothing have been released yet, so things aren't looking good. If nothing works out, I'm afraid this port have seen its last days. Fredrik ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
UPEK/TouchChip Biometric Device problem
Hello all,
I have used the mentioned devices on FreeBSD 5.4 in the past, and they
worked just fine, but now I get problems with the same device, on top of
6.2-STABLE and also 7.0-CURRENT.
From `usbdevs -v`, I get:
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x), rev 1.00
port 1 addr 2: full speed, power 100 mA, config 1, Biometric
Coprocessor(0x2016), STMicroelectronics(0x0483), rev 0.01
port 2 powered
I have security/bsp_upektfmess, security/pam_bsdbioapi and
security/bioapi installed. It is a 6.2-STABLE system from 2 hours ago.
Listing bsp devices, I get:
# bbdm -l bsp
UUID {----}
Example Vendor libbioapi_dummy100.so (BioAPI v1.1 Dummy BSP)
UUID {263a41e0-71eb-11d4-9c34-12403700}
BioAPI Consortium libpwbsp.so (BioAPI Password BSP)
UUID {5550454b-2054-464d-2f45-535320425350}
UPEK, Inc. libtfmessbsp.so (TouchChip TFM/ESS Fingerprint BSP)
Backend configurations:
# bbdm -l birdb
Installed BIRDB modules
filedb Filebacked database (b-tree)
plainPlain text file
And now, the problem:
# bbdm -b "{5550454b-2054-464d-2f45-535320425350}" -m filedb -c eksffa
bbdm: Failed to initate BSP {5550454b-2054-464d-2f45-535320425350}
And on /var/log/messages as well as dmesg, I get:
All threads purged from ugen1.1
All threads purged from ugen1.2
All threads purged from ugen1.3
What is this about "threads purged"? Also, the port want libintl.so.6
while 6.2-STABLE has libintl.so.8. I have tried 1) linking .8 to .6 and
also copied .6 from another system (also, 6.2-STABLE) to the current
one. Didnt work both way. Same behavior, exactly.
On 7.0-CURRENT things are worse. libpthread is not found, and the same
command core dumps. Anyway, 6.2-STABLE is more important to me right
now, since I need this device to work on FreeBSD for an ongoing project,
but if a solution to 7.0 happens first my work can move to that version.
Can anyone help me?
Thank you.
--
Patrick Tracanelli
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with FreeBSD 6.0
Kris Kennaway wrote: On Thu, Apr 13, 2006 at 02:48:51AM +0200, Stefan Sperling wrote: On Wed, Apr 12, 2006 at 07:22:27PM -0400, Kris Kennaway wrote: On Wed, Apr 12, 2006 at 10:48:44PM +, [EMAIL PROTECTED] wrote: I tried out FreeBSD 6.0 (sorry, I copied just part or uname -a and I got something like "LINUX 2.4.2 FreeBSD 6.0 - Release #0: Nov 3 09:36:13 UTC 2005 i686 i686 i386 GNU/LINUX") No you didn't, since no version of FreeBSD reports itself as LINUX from uname. Unless uname is a Linux binary. FreeBSD doesn't ship uname as a Linux binary either :-) Kris Unless under Linux mode... # /compat/linux/bin/uname -a Linux claire.freebsdbrasil.com.br 2.4.2 FreeBSD 7.0-CURRENT #15: Wed Apr 12 13:23:25 BRST 2006 i686 i686 i386 GNU/Linux # chroot /compat/linux /bin/bash bash-2.05b# uname -a Linux claire.freebsdbrasil.com.br 2.4.2 FreeBSD 7.0-CURRENT #15: Wed Apr 12 13:23:25 BRST 2006 i686 i686 i386 GNU/Linux -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cloning a FreeBSD HDD
John-Mark Gurney wrote: Patrick Tracanelli wrote this message on Wed, Mar 29, 2006 at 10:14 -0300: Daniel O'Connor wrote: On Wednesday 29 March 2006 14:34, M. Warner Losh wrote: dump + restore is slow but reliabe. Faster than dd for disks that aren't full :) It also gives you a defrag as well as allowing you to change FS options. Yes, pretty much faster for non-full disks, even compared to paralell dd(1). And we always have the "-L" option to snapshot and dump(1) from live file systems, what makes it an interesting and completly viable choice to clone the disks in multiuser mode (no need to go single user). It is my choice to copy a disk into one other. It is even possible to copy a disk to a slower one (again, if the source is not full and if the dst disk have enough space to store all data currently in use in the source disk), and better (customizable new partitions) results when copying to a larger second disk, when compared to dd(1). Though if you are using extended attributes, the dump/restore pair won't transfer them... :( You are right, I am afraid it is true for ACLs and other MAC modules too. Sadly dump does not know about 'em (yet?). So it is really something to consider when backin' up full disks with the dump|restore pair, if the person use more sophisticated FS attributes. -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cloning a FreeBSD HDD
Daniel O'Connor wrote: On Wednesday 29 March 2006 14:34, M. Warner Losh wrote: dump + restore is slow but reliabe. Faster than dd for disks that aren't full :) It also gives you a defrag as well as allowing you to change FS options. Yes, pretty much faster for non-full disks, even compared to paralell dd(1). And we always have the "-L" option to snapshot and dump(1) from live file systems, what makes it an interesting and completly viable choice to clone the disks in multiuser mode (no need to go single user). It is my choice to copy a disk into one other. It is even possible to copy a disk to a slower one (again, if the source is not full and if the dst disk have enough space to store all data currently in use in the source disk), and better (customizable new partitions) results when copying to a larger second disk, when compared to dd(1). -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cloning a FreeBSD HDD
I heard its faster if you use two dd's; i.e: # dd if=/dev/ad0 bs=64k | dd of=/dev/ad1 bs=64k allowing read and write to proceed in parallel. that's what ddd and 'team' are for. I don't know if ddd is in the ports as it may clash inname with teh debugger ddd They internally fork and use several processes synchronised in some manner. Isn't dump+restore and a couple of fdisk+bsdlabel trick to copy the source partitioning a better choice to "clone" this HDD? -- Patrick Tracanelli (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: organization
Maybe you are just more familiar to Linux kernel. I am not a kernel hacker, like you and many people here. But I usually read source codes, FreeBSD and also NetBSD and Linux, specially the areas where I am a particular curious. FreeBSD code organization is close to BSD's roots (you can get those Walnut Creek historical CDROM which has code for 4BSD and 386BSD to compare). I like FreeBSD orgaization better. Maybe you will disagree it for a thousand years, or one day find NetBSD approach better than both. In any case I am sure spending more time under FreeBSD's src/ won't make the organization such a deal that deserves this comment. mohamed aslan wrote: hi guys it's my first post here, BTW i was a linux hacker and linux kernel mailing list member for 3 years. and i've a comment here , i think the freebsd kernel source files aren't well organized as linux ones. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs within jail
Matt wrote: Quick question regarding nfs (or other filesystems) inside a jail. As far as I can tell, it isn't possible to mount nfs shares while inside a jail. Is this correct? Is there any way around this limitation? A way to browse network shares without mounting? Or some such trickery? Thanks. When a Jail needs to access a NFS mounted device I use to mount it on the hosting machine (the system outsite the jail where jail is runned from) in any mount-point, so I mount_nullfs inside the selected jails, say, mount_nullfs /nfs/backup/200.200.100.40 /usr/jail/200.200.100.40/mnt/nfs/backup; The problem is that you cant do it if you are not the jails admin (ie, you dont have full access to the jails hosting system). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UCARP support for FreeBSD
Vladimir Terziev wrote: Hi, i need to implement gateway redundancy for our server farm. I found UCARP ( http://www.ucarp.org ) as a potential solution, but it is written it is tested successfully only on Linux, OpenBSD and NetBSD. Did anybody have luck with it under FreeBSD ? Try CARP, not a variant. MLaier's been very successfull at porting it to FreeBSD. The available patches just apply fine against 5.3-RELEASE and it works *very well*. Reffer to OBSD's CARP documentation to get it to work. http://people.freebsd.org/~mlaier/CARP/ -- Atenciosamente, Patrick Tracanelli FreeBSD Brasil LTDA. The FreeBSD pt_BR Documentation Project http://www.freebsdbrasil.com.br Fone/Fax: (31) 3281-9633 "Long live Hanin Elias, Kim Deal!" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
