How to assign rfcomm ?
-
Hello This is a follow-up on my previous post about “ln” commend. I am trying to link “dev/ttytUSB0” with “dev/rfcomm0”. I am doing something wrong and obviously not doing it in correct sequence or using Linux commands wrong. . I am using “ln” and “rfcomm” and get no response from both “ln” and “rfcomm”; nov5-6@nov56-desktop:~$ sudo ln /dev/ttyUSB0 /dev/rfcomm0 [sudo] password for nov5-6: nov5-6@nov56-desktop:~$ rfcomm –a nov5-6@nov56-desktop:~$ \ When I run “ln” again I get this: \nov5-6@nov56-desktop:~$ sudo ln -v /dev/ttyUSB0 /dev/rfcomm0 [sudo] password for nov5-6: ln: failed to create hard link '/dev/rfcomm0': File exists nov5-6@nov56-desktop:~$ If I use “rfcomm” it still returns nothing. nov5-6@nov56-desktop:~$ rfcomm –a nov5-6@nov56-desktop:~$ \ I am obviously missing something and I am asking the group for a solution. Thanks, any help with solving thius will be much appreciated
-
Hello This is a follow-up on my previous post about “ln” commend. I am trying to link “dev/ttytUSB0” with “dev/rfcomm0”. I am doing something wrong and obviously not doing it in correct sequence or using Linux commands wrong. . I am using “ln” and “rfcomm” and get no response from both “ln” and “rfcomm”; nov5-6@nov56-desktop:~$ sudo ln /dev/ttyUSB0 /dev/rfcomm0 [sudo] password for nov5-6: nov5-6@nov56-desktop:~$ rfcomm –a nov5-6@nov56-desktop:~$ \ When I run “ln” again I get this: \nov5-6@nov56-desktop:~$ sudo ln -v /dev/ttyUSB0 /dev/rfcomm0 [sudo] password for nov5-6: ln: failed to create hard link '/dev/rfcomm0': File exists nov5-6@nov56-desktop:~$ If I use “rfcomm” it still returns nothing. nov5-6@nov56-desktop:~$ rfcomm –a nov5-6@nov56-desktop:~$ \ I am obviously missing something and I am asking the group for a solution. Thanks, any help with solving thius will be much appreciated
It seems like you're still trying to connect /dev/rfcomm0 and /dev/ttyUSB0 together, so that a write to one will write to the other. As explained previously, that's not how a link works. Creating a link could be thought of as providing a different name for the same object. So for example, suppose you live at 42 Main Street. Creating a link is like adding the number 24 to your house. If you tell someone you live at 24 Main Street, or 42 Main Street, they find the same house, either way. As far as I know, there's no way to multiplex 2 files together. At least not in the Unix/Linux world. Maybe Windows does this? You do know that /dev in all but very old Linux systems is a virtual file system, and gets recreated every time you reboot? It's actually quite dynamic. For example as you plug-in and unplug USB devices, new /dev entries get added and removed as needed. My other suspicion is that you're trying to create /dev/rfcomm0 incorrectly. when you ls a device file, you get something like
crw------- 1 root root 4, 1 Sep 23 08:17 /dev/tty1. The "c" at the start of the permissions string indicates its a character device, and4, 1indicate the MAJOR and MINOR device numbers. The major device number is, more or less, an index into the kernel's device driver table, and the minor is, once again more or less, the specific device to do I/O with. So in the case above, the MAJOR is 4, a console TTY device, and 1 is the tty number. Similarly /dev/tty2 has MAJOR,MINOR 4,2 etc. I'm guessing that /dev/rfcomm0 should be some sort of radio frequency communication device. As such it will have it's own MAJOR/MINOR assignments, almost certainly different from what a USB Serial device would have. Additionally, an rfcomm device will probably have its own set of ioctl calls that only make sense for that device. So think about that, what happens if you could link devices together what should happen when you try to send an ioctl to one of them that the other does not recognize, via the multiplex? Should it silently fail on one, but succeed on the other? What's the return value? How would you distinguish which device had rejected the IOCTL call. Worse, an ioctl looks likeioctl(int fd, unsigned long request, ...). So a request id (say 2) to one device might turn it on and to the other might put it in diagnostic mode. I repeat, it's not quite clear what you are trying to do. If you need a /dev/rfcomm0 device file to communicate to -
It seems like you're still trying to connect /dev/rfcomm0 and /dev/ttyUSB0 together, so that a write to one will write to the other. As explained previously, that's not how a link works. Creating a link could be thought of as providing a different name for the same object. So for example, suppose you live at 42 Main Street. Creating a link is like adding the number 24 to your house. If you tell someone you live at 24 Main Street, or 42 Main Street, they find the same house, either way. As far as I know, there's no way to multiplex 2 files together. At least not in the Unix/Linux world. Maybe Windows does this? You do know that /dev in all but very old Linux systems is a virtual file system, and gets recreated every time you reboot? It's actually quite dynamic. For example as you plug-in and unplug USB devices, new /dev entries get added and removed as needed. My other suspicion is that you're trying to create /dev/rfcomm0 incorrectly. when you ls a device file, you get something like
crw------- 1 root root 4, 1 Sep 23 08:17 /dev/tty1. The "c" at the start of the permissions string indicates its a character device, and4, 1indicate the MAJOR and MINOR device numbers. The major device number is, more or less, an index into the kernel's device driver table, and the minor is, once again more or less, the specific device to do I/O with. So in the case above, the MAJOR is 4, a console TTY device, and 1 is the tty number. Similarly /dev/tty2 has MAJOR,MINOR 4,2 etc. I'm guessing that /dev/rfcomm0 should be some sort of radio frequency communication device. As such it will have it's own MAJOR/MINOR assignments, almost certainly different from what a USB Serial device would have. Additionally, an rfcomm device will probably have its own set of ioctl calls that only make sense for that device. So think about that, what happens if you could link devices together what should happen when you try to send an ioctl to one of them that the other does not recognize, via the multiplex? Should it silently fail on one, but succeed on the other? What's the return value? How would you distinguish which device had rejected the IOCTL call. Worse, an ioctl looks likeioctl(int fd, unsigned long request, ...). So a request id (say 2) to one device might turn it on and to the other might put it in diagnostic mode. I repeat, it's not quite clear what you are trying to do. If you need a /dev/rfcomm0 device file to communicate toThank you for the reply. I am not sure HOW to reply without offending, however, I have specifically asked for assistance in analyzing the posted commands. I need to keep this short, my new OS does not do spell check... However - the second usage of "ln" failed because the /dev/rfcomm0 WAS already build....
-
Thank you for the reply. I am not sure HOW to reply without offending, however, I have specifically asked for assistance in analyzing the posted commands. I need to keep this short, my new OS does not do spell check... However - the second usage of "ln" failed because the /dev/rfcomm0 WAS already build....
I have found that relaying on responses / return values of SOME Linux commands is not necessary. Usually there are other commands where the result of the first command can be found, hence verified. For example "ln -v /dev/ttyUSB0 /dev/rfcomm0" result can be verified using "ls /dev/rf*"
-
I have found that relaying on responses / return values of SOME Linux commands is not necessary. Usually there are other commands where the result of the first command can be found, hence verified. For example "ln -v /dev/ttyUSB0 /dev/rfcomm0" result can be verified using "ls /dev/rf*"
-
It may help if you provide a long listing of thos devices:
ls -al /dev/tty*
ls -al /dev/rfc*This would at least show how these two are currently assigned.