Hello,
[...]
Now to what I can understand, the biggest problem is the proxy arp. I can
have bc compuerts connects to bs, but I cannot let them access other hosts
on the LAN. A true example: bc1 is 10.0.0.11, on the other side of the
tunnel is 10.0.0.10 (bs). bs also have a NIC address
Dear Hackers,
I'm working on the Bluetooth stack for FreeBSD and currently
doing testing for new in-kernel RFCOMM code. RFCOMM is a way
to emulate serial link over Bluetooth.
In particular Bluetooth spec defines two RFCOMM based profiles
LAN (Network Access profile) and DUN (DialUp Networking
Daniel,
So the questions is: would it be possible to enable PPP chat
in direct mode? Is there any reason to not allow this? It
seems 'login' script would do just fine. Is there any other/
better way to do this? One possible option right now is to
execute /bin/chat from the launcher
Warner,
Is there any reason that RFCOMM doesn't give full tty support, like
the various USB modem drivers do? That's likely the best way to deal
with this. Then ppp or whatever application you want will just work.
Yes, there is. RFCOMM connection can only be established when
baseband link
Daniel,
Is there any reason that RFCOMM doesn't give full tty support, like
the various USB modem drivers do? That's likely the best way to deal
with this. Then ppp or whatever application you want will just work.
Maybe it is necessary/useful to 'steer' PPP from the RFCOMM end?
eg
Warner,
: So you see it is probably possible to build a tty-like interface,
: but i do not think it really worth the trouble. In fact one
: can do it right now with the help of nmdm(4) driver. It is a
: simple wrapper that would pass the data between socket and
: /dev/nmdm0{A|B}.
That's
Daniel,
yes. that is one example. but the real trouble with tty is the
server application that wants to listen on wildcard address. for
example Network Access point that listens on RFCOMM channel 1. no
matter what client comes in the server will just accept connection
on the socket,
Dear Hackers,
Please find attached patch that adds new option to the PPP.
run-scripts-in-direct-mode
Default: Disabled. This allows to run chat scripts in
direct mode.
did i miss anything? objections? comments? reviews?
thanks,
max
I'm working on the Bluetooth stack for FreeBSD and
Dear Brian and Hackers,
Please find updated proposed version of the patch. As suggested by
Warner option has been renamed to 'force-sripts' and now works for
both 'direct' and 'dedicated' modes. Also as suggested by Terry the
man page has been updated to document side effect of 'direct'.
-direct
Terry,
Maksim Yevmenkin wrote:
force-scripts
Default: Disabled. Forces execution of the configured chat
scripts in direct and dedicated modes.
Outstanding! If Brian doesn't veto, I'd say it's gold, and
someone should commit it; so I guess this fixes the last Bluetooth
Cell phone PPP
Terry,
seems like it :) just got report back from one of the testers.
he got connected to the internet over his T39m bluetooth enabled
cell phone. the cool thing is that you can make CSD, GPRS or HSCSD
calls. its just a matter of init string you send to the phone :)
still waiting on
description. i missed it.
changes. Just to be picky, I'll re-sort the OPT_ variables too :*P
no problem :)
And thanks for the patches.
thank you for reviewing them :)
max
On Mon, 03 Feb 2003 14:45:37 -0800, Maksim Yevmenkin wrote:
Dear Brian and Hackers,
Please find updated proposed version
Hello,
3. shell script (from man kbdcontrol):
kbdcontrol -K /dev/console
kbdcontrol -a /dev/ukbd0 /dev/kbdmux0
kbdcontrol -a /dev/atkbd0 /dev/kbdmux0
kbdcontrol -k /dev/kbdmux0 /dev/console
please read the man page carefully. you should use
kbdcontrol -a ukbd0 /dev/kbdmux0
kbdcontrol
3. shell script (from man kbdcontrol):
kbdcontrol -K /dev/console
kbdcontrol -a /dev/ukbd0 /dev/kbdmux0
kbdcontrol -a /dev/atkbd0 /dev/kbdmux0
kbdcontrol -k /dev/kbdmux0 /dev/console
please read the man page carefully. you should use
kbdcontrol -a ukbd0 /dev/kbdmux0
kbdcontrol
no, its not the same as in your previous email. you got different
error. did you run your script in console or xterm window?
also, just to be on the safe side, you might want to replace
/dev/console with /dev/ttyv0, i.e.
kbdcontrol -K /dev/ttyv0
kbdcontrol -a ukbd0 /dev/kbdmux0
Dear Hackers,
is there a way to force packets to go out on a specific interface
based on a source IP address?
here is what we want: for testing purposes we have a FreeBSD box with
two 100Mbit NICs (em0 and em1). both NICs are on the the same subnet
172.1.1.x/23. both NICs are connected to the
Hello,
first, please _do_not_ cross post. second, please use appropriate
mailing list. i have redirected this thread to freebsd-questions@
this type of question comes up quite often. its
really simple: a single
read(2) call on /dev/tapX will return entire
ethernet frame (if any)
received
On 11/8/07, Jimmie James [EMAIL PROTECTED] wrote:
Maksim Yevmenkin wrote:
On 11/8/07, Jimmie James [EMAIL PROTECTED] wrote:
I have a Broadcom BCM92035DGROM dongle, and this is what I'm seeing.
I'm assuming it's not supported, (from the handbook: The Broadcom
BCM2033 chip based Bluetooth
On 11/8/07, Jimmie James [EMAIL PROTECTED] wrote:
I have a Broadcom BCM92035DGROM dongle, and this is what I'm seeing.
I'm assuming it's not supported, (from the handbook: The Broadcom
BCM2033 chip based Bluetooth devices are supported via the ubtbcmfw(4)
and ng_ubt(4) drivers)
Is there
19 matches
Mail list logo
