**** BEGIN LOGGING AT Tue Jan 05 02:59:56 2010
**** ENDING LOGGING AT Tue Jan 05 05:57:21 2010

**** BEGIN LOGGING AT Tue Jan 05 05:58:14 2010
Jan 06 00:31:26 <zhenhua1> denkenz: there?
Jan 06 00:32:39 <denkenz> zhenhua1: yep
Jan 06 00:33:14 <zhenhua1> i know you will have many comments of my prototype.
Jan 06 00:33:36 <denkenz> yep ;)
Jan 06 00:34:06 <zhenhua1> so i am now opening my hear;-)
Jan 06 00:34:27 <zhenhua1> s/hear/ear
Jan 06 00:35:33 <denkenz> Ok, so there's way too much code to review properly, so I want you to submit this stuff in chunks
Jan 06 00:36:03 <zhenhua1> okay
Jan 06 00:36:16 <denkenz> First off, send a patch to move the pretty print function to gatutil.c
Jan 06 00:36:19 <denkenz> or something
Jan 06 00:36:51 <denkenz> second:
Jan 06 00:36:53 <zhenhua1> it need also motify gatchat.c code, like debug_chat
Jan 06 00:37:02 <denkenz> That's fine
Jan 06 00:37:05 <zhenhua1> ok
Jan 06 00:37:12 <denkenz> second:
Jan 06 00:37:25 <denkenz> remove g_at_server_new_tcp/new_unix
Jan 06 00:37:35 <denkenz> that should both be handled by a single function that takes a file descriptor
Jan 06 00:38:19 <denkenz> Perhaps g_at_server_new(GIOChannel)
Jan 06 00:39:17 <zhenhua1> they can share some common api, but you need to expose interface to user?
Jan 06 00:39:29 <denkenz> Let the upper layer handle it
Jan 06 00:39:44 <denkenz> Socket setup, accepting multiple connections, etc belongs higher
Jan 06 00:40:11 <denkenz> Just like atchat doesn't handle TCP connections
Jan 06 00:40:33 <zhenhua1> so multiple connections use different sock and listen on different port?
Jan 06 00:40:53 <denkenz> not necessarily
Jan 06 00:40:54 <denkenz> however g_at_server is 1 _active_ socket
Jan 06 00:41:05 <zhenhua1> that's fine
Jan 06 00:41:09 <denkenz> not even socket, but rather giochannel
Jan 06 00:41:25 <zhenhua1> yes, i know
Jan 06 00:42:05 <zhenhua1> as you can see, tty is different with tcp/unix socket.
Jan 06 00:42:22 <zhenhua1> i need to check whether it could to share the same api
Jan 06 00:42:26 <denkenz> so what I'm saying is, socket listen/accept belongs in test-server.c or similar
Jan 06 00:43:13 <zhenhua1> that's fine
Jan 06 00:43:31 <denkenz> If you can't, server_new_tty is fine
Jan 06 00:43:34 <denkenz> But see if you can
Jan 06 00:43:52 <zhenhua1> ok. what's the third one
Jan 06 00:44:50 <denkenz> Lets get rid of the CMEE error codes for now
Jan 06 00:45:26 <zhenhua1> ok
Jan 06 00:46:05 <zhenhua1> btw, what kind of error is mt error. suppose it should be reported by upper layer
Jan 06 00:47:01 <denkenz> Anything not network related AFAIK
Jan 06 00:48:06 <zhenhua1> we can add this support later. but we need keep it in mind.
Jan 06 00:48:22 <denkenz> Yep, right now I just want the basics working
Jan 06 00:48:41 <zhenhua1> ok
Jan 06 00:48:53 <denkenz> what is the purpose of g_at_server_get_modem_path?
Jan 06 00:49:10 <zhenhua1> not use it now
Jan 06 00:49:18 <denkenz> Get rid of it
Jan 06 00:49:19 <zhenhua1> still there? i will get rid of it.
Jan 06 00:50:47 <denkenz> also you have void *data in server_new_* functions
Jan 06 00:50:50 <denkenz> What is the purpose?
Jan 06 00:51:10 <zhenhua1> that's for user_data
Jan 06 00:51:36 <denkenz> you also have user_data in server_add_command
Jan 06 00:51:45 <denkenz> That one makes sense, the _new one doesn't
Jan 06 00:52:58 <zhenhua1> so far it doesn't use. you're right. i will remove it.
Jan 06 00:53:46 <zhenhua1> any comments for variable names, struct names?
Jan 06 00:53:52 <zhenhua1> like v250...
Jan 06 00:54:54 <denkenz> So generally you must prefix all your enums by the library prefix
Jan 06 00:54:59 <denkenz> e.g. G_AT_SERVER_RESULT_OK
Jan 06 00:56:03 <zhenhua1> okay, i will change it
Jan 06 00:56:23 <denkenz> also, for things like char terminator -> char s3
Jan 06 00:56:29 <denkenz> char response -> char s4
Jan 06 00:56:48 <denkenz> command_echo -> echo
Jan 06 00:56:55 <denkenz> result_code_suppress -> quiet
Jan 06 00:57:00 <zhenhua1> gatchat also use terminator, so i think it's good and meanful
Jan 06 00:57:11 <denkenz> is_v1_format -> is_v1
Jan 06 00:57:40 <denkenz> or perhaps simply v1
Jan 06 00:57:55 <zhenhua1> is_v1 is better
Jan 06 00:58:00 <denkenz> Just general guidelines, but your variables are waay to long :)
Jan 06 00:58:27 <zhenhua1> no, i want it be meanful, easy to understand.:)
Jan 06 00:58:51 <zhenhua1> anyway, it's a small case
Jan 06 00:59:01 <denkenz> Nod, for the most part they're fine, but those can be compressed a bit
Jan 06 00:59:33 <zhenhua1> okay, so what about struct basic_command/extended_command
Jan 06 00:59:45 <zhenhua1> i am not satisfy about them
Jan 06 01:00:26 <zhenhua1> and struct basic_command *v250;
Jan 06 01:00:28 <denkenz> so basic_command is a bad name
Jan 06 01:00:45 <denkenz> simply name it v250_settings or something
Jan 06 01:01:02 <zhenhua1> so i vote v250_settings.
Jan 06 01:01:34 <denkenz> ok
Jan 06 01:01:53 <denkenz> for extended_command, what is the purpose of read_only?
Jan 06 01:02:02 <zhenhua1> and extended_command can be renamed to at_command or something else
Jan 06 01:02:35 <zhenhua1> errr. i saw v250 spec says some AT are read_only
Jan 06 01:02:50 <zhenhua1> so we may report error if user set the value
Jan 06 01:03:09 <zhenhua1> i am not sure so i just put it there. not using it now.
Jan 06 01:03:36 <denkenz> How many times have I told you not to try to predict the future? ;)
Jan 06 01:03:41 <denkenz> Remove for now
Jan 06 01:03:58 <denkenz> rename char *command to char *prefix
Jan 06 01:03:59 <zhenhua1> okay
Jan 06 01:04:06 <zhenhua1> okay
Jan 06 01:04:27 <denkenz> and yeah struct extended_command -> struct command or something
Jan 06 01:04:51 <denkenz> in struct _GAtServer
Jan 06 01:05:05 <zhenhua1> how about struct at_command
Jan 06 01:05:13 <denkenz> that's fine
Jan 06 01:05:25 <denkenz> though really it is a handler
Jan 06 01:05:33 <denkenz> so maybe cmd_handler?
Jan 06 01:05:38 <denkenz> or at_handler
Jan 06 01:05:53 <zhenhua1> i don't care
Jan 06 01:06:00 <denkenz> yep, pick whatever
Jan 06 01:06:24 <zhenhua1> in struct _GAtServer, struct basic_command *v250; -> struct v250_settings v250;?
Jan 06 01:06:32 <denkenz> yep
Jan 06 01:06:41 <zhenhua1> that's fine for me.
Jan 06 01:06:54 <denkenz> also get rid of server_io/server_watch and whatever else isn't necessary
Jan 06 01:07:08 <zhenhua1> what does expect_pdu use for
Jan 06 01:07:33 <denkenz> That is for commands that take PDUs, see 27.005 for details
Jan 06 01:07:49 <denkenz> e.g. +CMGS
Jan 06 01:07:52 <zhenhua1> okay,
Jan 06 01:07:59 <zhenhua1> i will check that later
Jan 06 01:08:22 <zhenhua1> i assume that's for client not for server.
Jan 06 01:08:32 <zhenhua1> it looks i am wrong
Jan 06 01:08:43 <denkenz> both need it
Jan 06 01:09:15 <zhenhua1> go ahead
Jan 06 01:10:11 <denkenz> We must be able to handle extended commands that start with other characters than '+'
Jan 06 01:11:33 <zhenhua1> you're right. i need add code for that
Jan 06 01:12:05 <denkenz> If we can make this work generically by searching all prefixes that would be nice
Jan 06 01:12:13 <zhenhua1> it should be get_command_prefix
Jan 06 01:13:03 <zhenhua1> yes. i will try.
Jan 06 01:14:18 <denkenz> According to 27.007, all extension commands must be delimited by ;
Jan 06 01:14:38 <denkenz> So it should be possible to validate the command line fairly quickly
Jan 06 01:14:40 <zhenhua1> not for last extended command
Jan 06 01:14:48 <denkenz> well, <CR> too ;)
Jan 06 01:15:25 <zhenhua1> you means first cut command line into pieces?
Jan 06 01:15:41 <denkenz> Well, so if I send something like:
Jan 06 01:16:02 <denkenz> ATV1+CCWA=2<CR>
Jan 06 01:16:05 <denkenz> That should fail
Jan 06 01:16:28 <zhenhua1> why fail?
Jan 06 01:16:48 <zhenhua1> you don't need semicolon after basic command
Jan 06 01:16:49 <denkenz> CCWA is an extended command and must be delimited by a semicolon
Jan 06 01:17:07 <denkenz> in 27.007 it is...
Jan 06 01:17:39 <denkenz> Double check what V250 has to say about this
Jan 06 01:17:56 <zhenhua1> i am pretty sure about that. wait a sec
Jan 06 01:18:30 <zhenhua1> v250 5.4.5.2
Jan 06 01:19:16 <zhenhua1> Extended syntax commands may appear on the same command line after a basic syntax command without a separator
Jan 06 01:19:40 <denkenz> Ok
Jan 06 01:20:00 <zhenhua1> now i won one time;-)
Jan 06 01:20:18 <denkenz> I expect many more ;)
Jan 06 01:20:43 <denkenz> anyway, just make sure to parse the command line
Jan 06 01:20:51 <zhenhua1> yeah, i know
Jan 06 01:20:58 <denkenz> And ensure that we support %FOO +FOO *FOO ^FOO $FOO etc
Jan 06 01:21:19 <denkenz> Preferably anything that isn't defined in V250 should be treated as an extension command
Jan 06 01:21:39 <zhenhua1> yes. it's simple
Jan 06 01:21:59 <denkenz> so for the first patch I really just want this part
Jan 06 01:22:12 <zhenhua1> in get_command_prefix, if (c=='+') -> if (is_prefix(c))
Jan 06 01:22:19 <zhenhua1> okay
Jan 06 01:22:48 <denkenz> so g_at_server_new(GIOChannel), perhaps new_tty
Jan 06 01:22:54 <denkenz> ref/unref/shutdown
Jan 06 01:23:11 <denkenz> disconnect_function / debug / add command / remove command
Jan 06 01:23:23 <denkenz> remove all and the basic parser
Jan 06 01:23:40 <zhenhua1> no parse at all?
Jan 06 01:23:51 <denkenz> Also, model test-server after gsmdial
Jan 06 01:24:01 <denkenz> e.g. stick it into the gatchat directory
Jan 06 01:24:16 <zhenhua1> test-server now is not ready for checkin
Jan 06 01:24:28 <zhenhua1> it doesn't follow g_test_xxx
Jan 06 01:25:08 <denkenz> Yep, but a small utility that implements a server would be nice
Jan 06 01:25:25 <zhenhua1> okay
Jan 06 01:25:26 <denkenz> Even if all it does is print OK/ERROR for commands
Jan 06 01:26:26 <denkenz> The goal is to have something that parses commands properly and the basic structure
Jan 06 01:26:37 <denkenz> Then we can make things like echo/no echo, etc work
Jan 06 01:27:50 <zhenhua1> again, no parse at all? we need received_data and parse_buffer to do that?
Jan 06 01:28:16 <denkenz> yeah, the basic parsing has to be there
Jan 06 01:28:33 <zhenhua1> okay
Jan 06 01:28:39 <denkenz> but don't worry about echo or backspaces or a/, etc
Jan 06 01:29:03 <zhenhua1> okay
Jan 06 01:29:47 <denkenz> keep the code, but I like to digest things in pieces :)
Jan 06 01:30:01 <zhenhua1> i know that
Jan 06 01:31:01 <zhenhua1> so talking about patch i sent in the ML
Jan 06 01:31:32 <zhenhua1> do i need to fix it in atgen? may no need
Jan 06 01:31:48 <zhenhua1> because modem.conf can do that
Jan 06 01:31:49 <denkenz> I think its fine the way it is
Jan 06 01:31:57 <zhenhua1> okay
Jan 06 01:32:13 <denkenz> Most devices are raw anyway, if you have a real serial port you better set it up properly
Jan 06 01:32:16 <zhenhua1> but for N900, you have to set it in modem.conf, otherwise, you cannot use it
Jan 06 01:32:26 <denkenz> Same with the Freerunner
Jan 06 01:32:58 <zhenhua1> i check the default input/output speed is raw, which is zero.
Jan 06 01:33:15 <zhenhua1> or 38600? i am not sure.
Jan 06 01:33:24 <zhenhua1> 3860
Jan 06 01:33:26 <denkenz> I memset the structure and then call cfmakeraw
Jan 06 01:33:35 <denkenz> So it is whatever it sets it to
Jan 06 01:33:54 <zhenhua1> i know
Jan 06 01:34:22 <zhenhua1> you can print cfgetospeed to see the output is 0
Jan 06 01:34:36 <zhenhua1> from man, i know that's the disconnect value
Jan 06 01:35:32 <zhenhua1> The zero baud rate, B0, is used to terminate the connection. If B0 is specified, the modem control lines shall no longer be asserted. Normally, this will disconnect the line. CBAUDEX is a mask for the speeds beyond those defined in POSIX.1 (57600 and above). Thus, B57600 & CBAUDEX is non-zero.
Jan 06 01:35:35 <zhenhua1> http://linux.die.net/man/3/cfsetospeed
Jan 06 01:37:01 <jebba> zhenhua1: hey, been lurking here for awhile hoping to gleen some N900 info.  Can you show me a n900 modem.conf?  :)
Jan 06 01:37:29 <denkenz> Shrug, cfmakeraw devices ignore baud, so who cares
Jan 06 01:37:32 <zhenhua1> jebba: i am glad to share it to u.;)
Jan 06 01:37:36 <denkenz> For proper devices set it properly
Jan 06 01:38:09 <zhenhua1> [atgen]
Jan 06 01:38:09 <zhenhua1> Driver=atgen
Jan 06 01:38:09 <zhenhua1> Device=/dev/ttyACM0
Jan 06 01:38:09 <zhenhua1> Baud=115200
Jan 06 01:38:19 <zhenhua1> that's the setting for N900
Jan 06 01:38:31 <jebba> very much thanks zhenhua1!   :)  /me rebooting into fedora 12 on n900 now  :)
Jan 06 01:43:46 <jebba> zhenhua1: Any other N900 hints? I have the latest git ofono. I am using linux-2.6.28-omap1 kernel from Maemo/N900 but with a variety of more options enabled (such as framebuffer console).
Jan 06 01:46:14 <zhenhua1> jebba: nop, i am just getting a N900 and not try much yet.
Jan 06 01:47:21 <zhenhua1> jebba: just found i can dial a call through ofono on N900. :-)
Jan 06 01:47:32 <jebba> mknod /dev/ttyACM0 c 166 0                 any idea if that is correct for N900?  I've tried various dbus-sends, but nothing comes back happy, ala:
Jan 06 01:47:32 <jebba> sudo dbus-send --system --type=method_call --print-reply --dest=org.ofono  /atgen org.ofono.Modem.SetProperty string:"Powered" variant:boolean:true
Jan 06 01:48:46 <zhenhua1> when you connect to N900, choose PC suite mode and kernel will expose /dev/ttyACM0 automatically
Jan 06 01:49:17 <zhenhua1> try lsusb to see output
Jan 06 01:50:06 <jebba> ah ok, i wasn't booting into maemo, but i'll try that now
Jan 06 01:53:04 <jebba> didn't give me any ttyACM0, but i did get /dev/ttyGS0, /dev/ttyGS1, /dev/ttyGS2
Jan 06 01:53:46 <zhenhua1> do you have any udev rules for N900?
Jan 06 01:54:09 <zhenhua1> can you print out the dmesg
Jan 06 01:54:36 <denkenz> Heh, N900 using atgen? Good luck with that :)
Jan 06 01:54:56 <zhenhua1> yep, that works fine for me
Jan 06 01:55:07 <zhenhua1> i can make a call with N900.:-)
Jan 06 01:55:20 <zhenhua1> but not try GPRS or others yet
Jan 06 01:56:44 <denkenz> heh, you'd need ppp for GPRS
Jan 06 01:57:02 <zhenhua1> yep, i think so.
Jan 06 01:57:32 <denkenz> atgen is not really the right solution for N900 though
Jan 06 01:57:46 <denkenz> Maybe isimodem will actually work with it someday
Jan 06 01:57:51 <jebba> zhenhua1: http://pastebin.ca/1739619  is dmesg.   
Jan 06 01:58:03 <jebba> i havent done anything in particular with udev
Jan 06 01:58:05 <zhenhua1> how to use isimodem?
Jan 06 01:59:06 <denkenz> not sure it works on the N900, but Nokia guys can say more
Jan 06 01:59:14 <zhenhua1> [   65.174621] g_nokia gadget: USB CDC Phonet function
Jan 06 01:59:52 <zhenhua1> i don't see Phonet works on my ubuntu 9.10
Jan 06 01:59:59 <zhenhua1> it's interesting
Jan 06 02:00:38 <jebba> zhenhua1: that's dmesg from n900.
Jan 06 02:01:17 <jebba> ahhhh! i get it now, the laptop with /dev/ttyACM0 not n900 ;)
Jan 06 02:01:27 <zhenhua1> yes.
Jan 06 02:01:37 <zhenhua1> so we're in different topic
Jan 06 02:02:30 <denkenz> oFono won't work natively on the N900
Jan 06 02:02:30 <jebba> i have /dev/ttyACM0 on laptop fine now  :)
Jan 06 02:02:40 <zhenhua1> that's great
Jan 06 02:03:16 <zhenhua1> i need to learn how to ssh to n900 from laptop.
Jan 06 02:04:27 <jebba> denkenz: why would it work remotely but not natively?
Jan 06 02:04:45 <jebba> gah, in fedora i'm getting:
Jan 06 02:04:46 <jebba> ofonod[1674]: Unable to hop onto D-Bus: Connection ":1.219" is not allowed to own the service "org.ofono" due to security policies in the configuration file
Jan 06 02:04:57 <denkenz> because Nokia uses a different protocol natively
Jan 06 02:05:19 <zhenhua1> check your /etc/dbus-1/system.d/ofono.conf
Jan 06 02:05:40 <zhenhua1> <policy user="xxx">
Jan 06 02:05:48 <denkenz> That protocol isn't fully implemented in oFono yet
Jan 06 02:05:50 <jebba> ah ok now.
Jan 06 02:06:22 <jebba> denkenz: Nokia in Maemo, or in general?  Because I have Mer and Fedora 12 instaled on the fone as well.
Jan 06 02:06:45 <denkenz> N900 uses Phonet/ISI
Jan 06 02:07:04 <denkenz> oFono has a beginnings of ISI support, but it isn't ready or integrated with N900
Jan 06 02:07:14 <denkenz> Talk to the Nokia guys to know more
Jan 06 02:08:27 <jebba> ok thx
Jan 06 02:11:55 <jebba> ok, i have the /etc/ofono/modem.conf set up as described in my laptop. The /dev/ttyACM0 was created automatically. ofono starts ok (no complaints from dbus permssions). I launch ofono -nd. 
Jan 06 02:11:55 <jebba> I run:   `sudo dbus-send --system --type=method_call --print-reply  --dest=org.ofono  /atgen org.ofono.Modem.SetProperty string:"Powered"  variant:boolean:true`      But it complains:
Jan 06 02:11:55 <jebba> Error org.freedesktop.DBus.Error.UnknownMethod: Method "SetProperty" with signature "sv" on interface "org.ofono.Modem" doesn't exist
Jan 06 02:12:50 <jebba> stracing it seems to show it's seeing /dev/ttyACM0 ok:
Jan 06 02:12:51 <jebba> writev(2, [{"ofonod[1760]: src/modem.c:ofono_"..., 52}, {"\n", 1}], 2ofonod[1760]: src/modem.c:ofono_modem_create() atgen
Jan 06 02:13:47 <denkenz> try /atgen01
Jan 06 02:14:08 <denkenz> Or even better, use Manager.GetProperties first
Jan 06 02:16:01 <jebba> $ sudo dbus-send --system --print-reply --dest=org.ofono /atgen01 org.ofono.Manager.GetProperties
Jan 06 02:16:01 <jebba> Error org.freedesktop.DBus.Error.UnknownMethod: Method "GetProperties" with signature "" on interface "org.ofono.Manager" doesn't exist
Jan 06 02:17:30 <zhenhua1> check whether you have /usr/local/etc/ofono/modem.conf
Jan 06 02:20:20 <jebba> ya, and /etc/ofono/modem.conf
Jan 06 02:20:49 <jebba> strace of ofonod shows:
Jan 06 02:20:49 <jebba> read(5, "l\1\0\1\0\0\0\0\2\0\0\0w\0\0\0\1\1o\0\10\0\0\0/atgen01"..., 2048) = 136
Jan 06 02:20:49 <jebba> read(5, 0x1e388e0, 2048)                = -1 EAGAIN (Resource temporarily unavailable)
Jan 06 02:26:41 <zhenhua1> export OFONO_AT_DEBUG=1 and print out at chat log.
Jan 06 02:27:05 <zhenhua1> i guess the issue is the same as you need set baud rate to 115200
Jan 06 02:29:32 <jebba> http://pastebin.ca/1739635   after export OFONO_AT_DEBUG=1 
Jan 06 02:32:02 <zhenhua1> then you need to execute ofono/test/enable-modem and then show the log
Jan 06 02:38:54 <zhenhua1> jebba: http://pastebin.ca/1739645
Jan 06 02:40:30 <jebba> http://pastebin.ca/1739649
Jan 06 02:41:09 <zhenhua1> then you're done. try ofono/test/test-voicecall xxx
Jan 06 02:43:51 <jebba> ah! i's this:
Jan 06 02:43:52 <jebba> sudo dbus-send --system --print-reply --dest=org.ofono /atgen0 org.ofono.Modem.GetProperties
Jan 06 02:43:57 <jebba>  /atgen0 not 01
Jan 06 02:44:15 <jebba> though i couldnt make a voicecall yet ,fwwi
Jan 06 02:46:08 <zhenhua1> what's error you have when making the call
Jan 06 02:48:31 <jebba> http://pastebin.ca/1739657
Jan 06 02:50:14 <zhenhua1> jebba: can you output the ofono at log? btw, no need sudo to dial the call. use your current user is fine.
Jan 06 02:51:35 <jebba> ofono doesn't produce any more debug output after I run ./test/enable-modem.  When I run ./test/test-voicecall 5551212    There is no more output to ofonod -dn screen
Jan 06 02:52:42 <zhenhua1> you may need export OFONO_AT_DEBUG=1
Jan 06 02:55:45 <jebba> YES!!!!
Jan 06 02:56:08 <jebba> thank you so much! I will document this on the maemo.org wiki  :)
Jan 06 02:56:33 <zhenhua1> can u make call now?
Jan 06 02:56:49 <jebba> yes i can.
Jan 06 02:57:07 <zhenhua1> okay. but i am afraid it's not a official way heh
Jan 06 02:57:10 <jebba> haha
Jan 06 02:57:13 <zhenhua1> use /dev/ttyACM0
Jan 06 02:57:18 <jebba> it's what i call progress though  :)
Jan 06 02:57:48 <zhenhua1> because N900 should use ISImodem instead of atgen. like denis said.
Jan 06 02:58:26 <jebba> Yes, I am using Device=/dev/ttyACM0.  
Jan 06 02:59:10 <zhenhua1> good luck. you can try more test cases there.;-)
**** ENDING LOGGING AT Wed Jan 06 02:59:57 2010