I'm using OpenZaurus 3.5.4.1 and have been trying to connect as much stuff to my Collie as I possibly can. I currently have USB, Wi-Fi and IrDA connected and I don't think there's room for another interface - pity.
On bootup, irda0 exists and is up, and irda1 exists, and is down; neither have an IP address, and irattach is running. irping works, but TCP/IP communication does not - assigning an IP address to either interface will not result in communication because you need an extra layer. Unfortunately, the irda-utils is quite a slimmed-down version. The key to getting this working was getting ircomm to send and receive data. Once that was done, I ran PPP over the link. I didn't have any success with other protocols.
These notes are from my journal/diary, and I have attempted to tidy them up a little - but they are still in a total higgledy-piggledy order, and all unformatted and not easy to read.
This is a program similar to ping(8). It sends IrDA test frames (added some userdata which contains the frame number and the time the frame was sent). You can change the size of the frame by using the -s option. To get daddr you may use irdadump.That last paragraph is messed-up because it contains Unicode chrs. There's a better page (same page, but with formatting) here:irdaping must be run as root or installed setuid root, as it requires root privileges.
EXAMPLES
irdaping <daddr> [-s <framesize>]You may use an alias, which does not use any parameter:alias irping="irdaping `grep daddr /proc/net/irda/discovery|sed s/.*daddr://\`"It works fine when there is only one discovered client.
irdaping causes a lot of 'Alignment trap' messages. /proc/net/irda/discovery is an important file, as it tells you which devices have been 'picked up'. Nothing appears in that file on either host, though I can see that data is being sent by one host, and received by the other. Yay! Got a reply! The issue seems to be the format of address that irdaping requires. It is a hexadecimal number - I tried 16 bytes, because those appear in the corresponding HWaddr field of the other host. E.g. on Collie:http://manpages.ubuntu.com/manpages/dapper/man8/irdaping.8.html
.. so I used that address on Attraction:root@collie:~# ifconfig irda0 irda0 Link encap:UNSPEC HWaddr EF-7D-A0-25-00-00-00-00-00-00-00-00-00-00-0 0-00 UP RUNNING NOARP MTU:2048 Metric:1 RX packets:42 errors:0 dropped:0 overruns:0 frame:0 TX packets:133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:8 RX bytes:1428 (1.3 KiB) TX bytes:8667 (8.4 KiB) Interrupt:16
Interesting that the bytes of the address are reversed. Sure enough, if I do this:root@attraction:~# irdaping 0xEF7DA025000000000000000000000000 IrDA ping (0xffffffff on irda0): 32 bytes 32 bytes from 0x25a07def: irda_seq=0 time=105.71 ms. 32 bytes from 0x25a07def: irda_seq=1 time=105.68 ms. 32 bytes from 0x25a07def: irda_seq=2 time=105.65 ms. 32 bytes from 0x25a07def: irda_seq=3 time=106.72 ms. 4 packets received by filter
.. I get a reply. So if you specify all 16 bytes, the order is reversed. The first 4 bytes of the HWaddr need to be switched around.root@attraction:~# irdaping 0x25a07def IrDA ping (0x25a07def on irda0): 32 bytes 32 bytes from 0x25a07def: irda_seq=0 time=106.75 ms. 32 bytes from 0x25a07def: irda_seq=1 time=106.73 ms. 2 packets received by filter
Collie: 0x25a007defThat's a hardware ping though - I have not assigned an IP address yet. Giving an IP address to the irda0 interface doesn't seem to have an effect: you need to run irattach. (So far, irattach has not been running - I stopped it)
Attraction: 0x8744c384
The '-s' irattach option starts discovery Attraction shows that it's found Collie, but I have not started irattach on Attr yet.http://manpages.ubuntu.com/manpages/dapper/man8/irattach.8.html ^ manpageroot@collie:~# irattach irda0 -s root@collie:~# cat /proc/net/irda/discovery IrLMP: Discovery log: nickname: attraction, hint: 0x0400, saddr: 0x25a07def, daddr: 0x8744c384 .. Boogie!
In this case, irattach does not add a new irda interface, and irda0 is still up (and has no IP address). If I give it an IP address, 'ping' doesn't return a reply, although ifconfig shows that data is being sent. irattach /dev/ttyS1 -s attaches to the tty (not the irda interface) and adds irda1 .. but doesn't work..root@attraction:~# ifconfig irda0 0.0.0.0 root@attraction:~# cat /proc/net/irda/discovery IrLMP: Discovery log: nickname: collie, hint: 0x0400, saddr: 0x8744c384, daddr: 0x25a07def root@attraction:~# ps | grep irattach 23732 root 472 S grep irattach
Infrared-HOWTO: http://tuxmobil.org/Infrared-HOWTO/Infrared-HOWTO.html
Loading the irnet module didn't seem to change anything.
Done on both hosts:
I can't get ircomm to work. I loaded irnet - no luck with that either. Getting ircomm to work might be the first step. This chapter talks about the SL5500:root@[attraction|collie]:~# cat >/etc/modutils/irda.conf # Added by --- on 11-Feb-11 # See http://tuxmobil.org/Infrared-HOWTO/infrared-howto-s-configuration.html # IrDA over a normal serial port, or a serial port compatible IrDA port (SIR) alias tty-ldisc-11 irtty # IrCOMM (for printing, PPP, Minicom etc) alias char-major-161 ircomm-tty # if you want IrCOMM support # IRLAN # But currently the IrLAN protocol is no longer maintained # by the Linux/IrDA core team. alias irlan0 irlan alias irda0 sa1100_ir
... only, it relates to the Sharp ROM. Compile irda-utils, maybe..http://tuxmobil.org/Infrared-HOWTO/infrared-howto-s-irda-pda.html
It's already present, but not many of the utilities are there. On Collie, irattach /dev/ttyS2 -s definitely works, and adds irda1. Assigning an IP address to irda1 and doing 'ping' then transmits (verified with the camera of the SGH-M150), but nothing is received.root@attraction:~# ipkg files irda-utils Package irda-utils (0.9.16-r4) is installed on root and has the following files: /usr/sbin/irdaping /usr/sbin/dongle_attach /etc/init.d/irattach /usr/sbin/irattach
Woo! Well, somehow, I got ircomm to work.
Before that ifconfig command, I'd configured irda1 with ifconfig irda1 172.16.0.2 pointopoint 172.16.0.1, but I then reset it with ifconfig irda1 172.16.0.2.root@collie:~# ifconfig irda1 irda1 Link encap:UNSPEC HWaddr AE-78-43-9D-00-00-00-00-00-00-00-00-00-00-0 0-00 inet addr:172.16.0.1 Mask:255.255.0.0 UP RUNNING NOARP MTU:2048 Metric:1 RX packets:691 errors:7 dropped:0 overruns:0 frame:7 TX packets:184 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:8 RX bytes:12910 (12.6 KiB) TX bytes:9739 (9.5 KiB) root@collie:~# # nah root@collie:~# ifconfig irda1 172.16.0.1 root@collie:~# echo >/dev/ircomm0 "hello" root@collie:~# ps | grep ir 7 root RWN [ksoftirqd_CPU0] 23229 lex-new 1680 S mb-applet-wireless 14879 root 532 S irattach /dev/ttyS2 -s 15029 root 472 S grep irroot@attraction:~# ifconfig irda1 irda1 Link encap:UNSPEC HWaddr E3-9C-29-A2-00-00-00-00-00-00-00-00-00-00-0 0-00 inet addr:172.16.0.2 Mask:255.255.0.0 UP RUNNING NOARP MTU:2048 Metric:1 RX packets:141 errors:9 dropped:0 overruns:0 frame:9 TX packets:674 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:8 RX bytes:4898 (4.7 KiB) TX bytes:22280 (21.7 KiB) root@attraction:~# ifconfig irda1 172.16.0.2 root@attraction:~# ping 172.16.0.1 PING 172.16.0.1 (172.16.0.1): 56 data bytes --- 172.16.0.1 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss root@attraction:~# cat /dev/ircomm0 hello root@attraction:~# # woo!
Although TCP/IP over IrDA doesn't work, ircomm does, now. ircomm from Collie -> Attraction is working... and the other way around... which means that I should be able to setup a (slow) PPP link now.root@attraction:~# ifconfig irda1 irda1 Link encap:UNSPEC HWaddr E3-9C-29-A2-00-00-00-00-00-00-00-00-00-00-0 0-00 inet addr:172.16.0.2 Mask:255.255.0.0 UP RUNNING NOARP MTU:2048 Metric:1 RX packets:238 errors:10 dropped:0 overruns:0 frame:10 TX packets:1158 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:8 RX bytes:7013 (6.8 KiB) TX bytes:38427 (37.5 KiB)root@collie:~# ifconfig irda1 irda1 Link encap:UNSPEC HWaddr AE-78-43-9D-00-00-00-00-00-00-00-00-00-00-0 0-00 inet addr:172.16.0.1 Mask:255.255.0.0 UP RUNNING NOARP MTU:2048 Metric:1 RX packets:1140 errors:7 dropped:0 overruns:0 frame:7 TX packets:274 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:8 RX bytes:20854 (20.3 KiB) TX bytes:13597 (13.2 KiB)
Before, doing 'stty -a' on ircomm0 just waited .. and waited.. It seems that is because it tries to handshake with the other peer: whenever you change tty settings with one peer's ircomm0, you have to do the same with the other, or just send/receive some data over it - or the other host just sits there, waiting for a reply. [Is it true that IrDA is a half-duplex system?]root@attraction:~# stty -a </dev/ircomm0 speed 9600 baud; rows 0; columns 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
Some log messages, from Attr:
I set the speed to 19200 (using stty speed 19200 </dev/ircomm0) and when I did that, I needed to do the same thing on the other peer.irttp_data_request(), No data, or not connected ircomm_ttp_data_request(), failed irttp_data_request(), No data, or not connected ircomm_ttp_data_request(), failed
Got a PPP link!
That's on Attraction; for Collie:root@attraction:~# pppd /dev/ircomm0 115200 noauth persist nodetach local 172.16.0.2:172.16.0.1 Using interface ppp0 Connect: ppp0 <--> /dev/ircomm0 BSD-Compress (15) compression enabled local IP address 172.16.0.2 remote IP address 172.16.0.1
... same thing, but with opposite IP addresses. You only need the host part anyway. i.e. 172.16.0.1: for Collie, and 172.16.0.2: for Attr.root@collie:~# pppd /dev/ircomm0 115200 noauth persist nodetach local 172.16.0.1:172.16.0.2 Using interface ppp0 Connect: ppp0 <--> /dev/ircomm0 BSD-Compress (15) compression enabled local IP address 172.16.0.1 remote IP address 172.16.0.2
route:
Yes, Attraction has an IP address set for irda1. That should not be set. .. so I did ifconfig irda1 0.0.0.0 and the route disappeared. ppp still works, so I haven't killed anything.lex@collie:lex$ /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.16.0.2 * 255.255.255.255 UH 0 0 0 ppp0 192.168.135.0 * 255.255.255.0 U 0 0 0 wlan0 default router.brooknet 0.0.0.0 UG 0 0 0 wlan0lex@attraction:lex$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.16.0.1 * 255.255.255.255 UH 0 0 0 ppp0 192.168.135.0 * 255.255.255.0 U 0 0 0 wlan0 172.16.0.0 * 255.255.0.0 U 0 0 0 irda1 default router.brooknet 0.0.0.0 UG 0 0 0 wlan0
Logged in! ssh over IR! Attraction is now a very well-connected device: it has iRDA, Wi-Fi and USB interfaces, all connected.lex@collie:lex$ ssh 172.16.0.2 Host '172.16.0.2' is not in the trusted hosts file. (fingerprint md5 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx) Do you want to continue connecting? (y/n) y Password: Last login: Wed Feb 9 14:33:19 2011 from desree.brooknet lex@attraction:lex$ lex@attraction:lex$ who USER TTY IDLE FROM HOST root ttyS0 02:44m Jan 3 17:49 lex pts/0 00:00m Feb 9 14:33 desree.brooknet lex pts/5 00:00m Feb 11 04:35 172.16.0.1
devname: collie discovery: 1 discovery_slots: 6 discovery_timeout: 3 fast_poll_increase: 50 lap_keepalive_time: 2000 max_baud_rate: 16000000 max_noreply_time: 12 max_tx_data_size: 2042 max_tx_window: 7 min_tx_turn_time: 10 slot_timeout: 90 specific_dev: no device list. warn_noreply_time: 3The kernel is 2.4.18-rmk7-pxa3-embedix, which is ancient - but it is stable. I recommend increasing max_noreply_time because ircomm will send a HUP to pppd if this is exceeded.
A great conversation - that'll go down in history. The problem is that when someone says something like 'busy today!', he didn't say whether it was he who was busy, or me: the prepending of the words 'you are' would have made it much clearer. It's the modern way to miss out half the words in a sentence - people's time is too valuable to waste on contractions and addressing in the first person (this is me trying to remember my English Language course, from about 30 years ago).John, The Tesco Man: Busy today, eh! Me: Sorry - me? You? John, The Tesco Man: You - been shopping. Me: Yeah.
(06:34) TSLT: 12h6m5s, and counting..
Teaaaaaaaaaahhhhhhhhhhhh!!!!!!!!!!!!!!!!! ghgghhhhhhhhhhh!!
On my way up the hill, the streetlights in Channel View were off.
All of the lights on the top of the hill were off, too: I walked
into the line of darkness, and it reminded me of my West Down walks.
When I walked back, the Channel View lights were on again.
I think that it's a power-saving scheme; I approve of it (the NDDC will be
so pleased to know that).
Last modified 19:35 on 11-Feb-11