**** BEGIN LOGGING AT Mon Mar 22 03:00:02 2010
Mar 22 11:01:42 <josch> denkenz: ping
Mar 22 13:52:31 <denkenz> josch: pong
Mar 22 14:41:33 <josch> denkenz: sry just came back from an exam :)
Mar 22 14:42:23 <josch> denkenz: iirc you were the guy who proposed that you ofono guys are interested in making ofono run on whatever device we give you?
Mar 22 14:42:44 <josch> i hope it was you back then in #pyneo.org :)
Mar 22 14:43:44 <denkenz> we make ofono run on all devices
Mar 22 14:44:11 <josch> it is about the samsung h1
Mar 22 14:44:28 <josch> it already runs a custom kernel and rootfs from sd
Mar 22 14:44:45 <denkenz> However, some are easier than others, and we're not touching anything with an undocumented binary protocol (e.g. palm pre)
Mar 22 14:47:00 <josch> hahaha
Mar 22 14:47:09 <josch> that might actually be the case there ;)
Mar 22 14:47:58 <ius> dumdum, yup :x
Mar 22 14:48:03 <denkenz> Shrug, we're not magic pixies here, if it is undocumented there's not much we can do
Mar 22 14:49:31 <josch> oh hi ius :)
Mar 22 14:49:40 <ius> josch: I silently hopped in ;)
Mar 22 15:33:52 <tck> denkenz: how about the n900, got any doc on the modem i could use ? :)
Mar 22 15:34:59 <tck> i managed to find the complete list of messages (more complete than ofono's) on symbian's repo
Mar 22 15:35:13 <ius> tck: What baseband does it use?
Mar 22 15:35:38 <tck> don't really know.. its an "isi modem"
Mar 22 15:35:41 <tck> how can i check?
Mar 22 15:35:52 <denkenz> tck: Only the Nokia guys have the ISI docs and they are not making it public, even to me
Mar 22 15:36:13 <tck> sucks :/
Mar 22 15:36:33 <tck> ive been reversing nokia's CSD daemo + plugins
Mar 22 15:36:40 <tck> and searching through the web
Mar 22 15:36:49 <tck> and i managed to get some more message ids & sublocks
Mar 22 15:36:49 <tck> etc
Mar 22 15:36:57 <denkenz> Check gnokii, it has some isi reverse engineered
Mar 22 15:37:16 <tck> but i cant get NET_NEIGHBOUR_CELLS_REQ
Mar 22 15:37:17 <tck> to work
Mar 22 15:37:21 <tck> k thx i will
Mar 22 15:39:04 <denkenz> tck: If you just need the neighbor cell stuff, the easier way to go is the Freerunner or MBM
Mar 22 15:39:19 <denkenz> tck: Freerunner won't give you umts though, MBM will
Mar 22 15:40:03 <tck> freerunner is openmoko right?
Mar 22 15:40:08 <tck> what's MBM?
Mar 22 15:40:43 <denkenz> MBM = Ericsson Mobile Broadband Module
Mar 22 15:40:57 <denkenz> F3507, F3607g based cards
Mar 22 15:41:19 <denkenz> e.g. MD300, some Dell cards, etc
Mar 22 15:42:04 <denkenz> The docs are even mainly reverse-engineered online, check google
Mar 22 15:42:15 <tck> thx alot i ll check it out asap
Mar 22 16:00:02 <tck> thx denkenz, looks like MBM cards support nice at commands to get everything im after
Mar 22 16:01:39 <tck> now if only i could get all that from a _phone_ and not a laptop/netbook :|
Mar 22 16:02:20 <ius> denkenz: ofone currently only supports non-Qualcomm modems it seems?
Mar 22 16:02:26 <ius> s/ofone/ofono
Mar 22 16:11:59 <denkenz> tck: You can always wait until akiniemi is interested in implementing the neighbor cell stuff again
Mar 22 16:12:15 <denkenz> tck: Until then I can't recommend anything that will work
Mar 22 16:12:19 <tck> you think he will?
Mar 22 16:12:34 <denkenz> ius: We support everything that can be reasonably supported
Mar 22 16:12:53 <denkenz> ius: However, reverse-engineering a binary protocol is a waste of our time, we have other things to do
Mar 22 16:13:33 <denkenz> tck: No idea, ask him
Mar 22 16:13:39 <tck> from what i read / tested / etc... it would appear the modem is ignoring my requests and i need to put it in engineering / debug / whatever mode
Mar 22 16:15:14 <denkenz> ius: Also note that Qualcomm does have AT command based modems, so your statement is not correct
Mar 22 16:15:28 <denkenz> ius: E.g. HSO, Huawei, G1 are all Qualcomm based
Mar 22 16:15:42 <tck> denkenz: asked him about my problem, he hasnt answered yet.
Mar 22 16:16:00 <tck> i figured him or courmisch  were the people to ask ;p 
Mar 22 16:16:06 <tck> from their presentation slides
Mar 22 17:12:03 <ius> denkenz: Ah right, well, in this case it's a binary interface I think, so I'll just add it to my long todo :)
Mar 22 17:31:40 <josch> tck: the F3507 is THE shit!! you /rly/ want that card in your laptop
Mar 22 17:32:18 <josch> tck: it even offers an ethernet interface that you can start by issuing an AT command and then only do a dhcp request on and you are good to go
Mar 22 17:32:44 <josch> tck: it comes with 3 serial usb devices and gps on any of those
Mar 22 17:32:52 <tck> cool
Mar 22 17:33:01 <josch> it's only too bad that such killer hw is not available for usb
Mar 22 17:33:24 <josch> tck: read more about it in the thinkwiki
Mar 22 17:33:31 <josch> dells and thinkpads come with it
Mar 22 17:33:32 <tck> but thing is im trying to make a mobile based system right now
Mar 22 17:33:43 <josch> i got mine on ebay for 60€
Mar 22 17:34:11 <tck> i found a page with the list of all supported at commands for it
Mar 22 17:34:16 <tck> and it does look very complete
Mar 22 17:34:49 <tck> http://www.natisbad.org/E4300/Dell_Wireless_5530_AT_cmd_ref.html
Mar 22 17:34:50 <tck> :)
Mar 22 17:35:08 <tck> AT*E2EMM
Mar 22 17:35:17 <tck> wish i had something like that for nokia
Mar 22 17:35:39 <josch> exactly
Mar 22 17:35:42 <josch> that card is a dream
Mar 22 17:35:52 <josch> plug it in and you are good to go
Mar 22 17:37:53 <josch> so you need it even if it is note directly useful for your current project ;)
Mar 22 17:38:36 <denkenz> FYI, you can get the SE MD300 with the F3507
Mar 22 17:38:47 <denkenz> It doesn't have the GPS, but most of the other features are there
Mar 22 17:38:55 <denkenz> And its just USB stick, not PCI
Mar 22 17:39:03 <josch> oooh
Mar 22 17:39:44 <josch> denkenz: so same features except the gps? same kernel support?
Mar 22 17:40:03 <denkenz> yep
Mar 22 17:40:15 <josch> wow nice
Mar 22 17:40:17 <denkenz> That's what I did most of my MBM driver work on
Mar 22 17:40:20 <josch> denkenz: thx for the info!
Mar 22 17:40:25 <denkenz> So it should work out of the box with oFono
Mar 22 17:46:07 <tck> thanks denkenz & josch for your answers & help, i gota go but i ll be back tomorow
Mar 22 17:46:09 <tck> have fun
Mar 22 22:47:45 <denkenz> holtmann: We need to start talking about modem emulator, whether we want it in-process, out-of-process, etc
**** ENDING LOGGING AT Mon Mar 22 22:48:09 2010

**** BEGIN LOGGING AT Mon Mar 22 22:54:14 2010
**** ENDING LOGGING AT Mon Mar 22 23:25:21 2010

**** BEGIN LOGGING AT Mon Mar 22 23:44:15 2010
Mar 23 00:26:05 <holtmann> You mean second process that just runs the emulator?
Mar 23 00:26:32 <holtmann> I think this depends on a little bit what hardware support we have.
Mar 23 00:27:07 <holtmann> For example for ISI a modem emulator could be easy a different process, because how Phonet works. For AT hardware it might be actually causing issues if it is outside.
Mar 23 00:53:16 <denkenz> holtmann: No, we have to go through oFono
Mar 23 00:53:34 <denkenz> holtmann: The question is do we do it in ofonod process or using the DBus API + extensions
Mar 23 00:53:59 <holtmann> My current mindset would be to do it directly in oFono.
Mar 23 00:54:35 <holtmann> Only problem case I might see is PPP. However if we figure out on how to better use the kernel PPP, then the workload is minimal.
Mar 23 00:54:56 <denkenz> My biggest concern there is additional vectors for attacks
Mar 23 00:55:49 <holtmann> Let me put it this way. Lets start with it internally, but try not to integrate it to deeply. If it becomes the wrong choice we go externally.
Mar 23 00:56:03 <holtmann> Gut feeling is we need this internally if we not wanna complicate it for us.
Mar 23 01:02:18 <denkenz> It has to be integrated deeply
Mar 23 01:02:32 <denkenz> holtmann: Because we'd need access to internal state, which is private today
Mar 23 01:03:38 <holtmann> Then there you have your answer. Go internally. And only if we see problems we invent an API to run it externally.
Mar 23 01:04:40 <denkenz> Funny thing is, we'd be mostly ok going external too, we can use the ussd api to get access to almost everything
Mar 23 01:04:54 <denkenz> holtmann: The only thing that wouldn't work would be sms / cbs pdus
Mar 23 01:05:00 <denkenz> hence the extensions
Mar 23 01:34:46 <zhenhua> denkenz: why bother to change parse_extended_command so heavily?
Mar 23 01:37:01 <zhenhua> at least, we should split parse_extended into two or three functions. do you want me to clone parse_basic by following your style?
Mar 23 01:39:50 <zhenhua>   CC     gatchat/ppp.o
Mar 23 01:39:50 <zhenhua> cc1: warnings being treated as errors
Mar 23 01:39:50 <zhenhua> gatchat/ppp.c: In function ‘ppp_recv’:
Mar 23 01:39:50 <zhenhua> gatchat/ppp.c:202: error: cast to pointer from integer of different size
Mar 23 01:39:50 <zhenhua> make[1]: *** [gatchat/ppp.o] Error 1
Mar 23 01:39:51 <zhenhua> make: *** [all] Error 2
Mar 23 01:42:45 <zhenhua> holtmann: can i simply cast protocol from guint16 to guint in GUINT_TO_POINTER(protocol)?
Mar 23 02:03:26 <holtmann> zhenhua: You are running 32-bit?
Mar 23 02:03:38 <holtmann> I am not seeing this issue.
Mar 23 02:03:40 <zhenhua> sure
Mar 23 02:03:52 <zhenhua> do you have turn on enable-maintainer-mode
Mar 23 02:04:27 <zhenhua> my option is --enable-maintainer-mode --enable-debug --disable-optimization --no-create --no-recursion
Mar 23 02:04:54 <holtmann> I use bootstrap-configure :)
Mar 23 02:05:49 <zhenhua> heh. shall I submit a patch to fix my warning?
Mar 23 02:06:19 <zhenhua> anyway, let me rerun configure fist
Mar 23 02:06:32 <holtmann> I am not getting this one. And it should be fine to cast the guint16 into the pointer.
Mar 23 02:06:48 <holtmann> Use ./bootstrap-configure.
Mar 23 02:07:09 <zhenhua> sure
Mar 23 02:07:13 <zhenhua> wait a sec
Mar 23 02:08:36 <denkenz> zhenhua: Your code was a little overly complicated and bled through some details into user-interface
Mar 23 02:09:03 <zhenhua> denkenz: but i think your code is complicated than mine.;-)
Mar 23 02:09:18 <holtmann> zhenhua: Which distro are you using?
Mar 23 02:09:24 <denkenz> zhenhua: Sure, but I handle tons of cases you weren't
Mar 23 02:09:51 <zhenhua> am I missed any detailed case?
Mar 23 02:10:09 <zhenhua> holtmann: i am using git tree.
Mar 23 02:10:13 <zhenhua> 	gcc -DHAVE_CONFIG_H -I. -I./include -I./src -I./src -I./gdbus -I./gisi -I./gatchat   -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include   -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include    -DOFONO_PLUGIN_BUILTIN -DPLUGINDIR=\""/home/zzhan17/ofono/plugins/.libs"\" -Wall -O2 -D_FORTIFY_SOURCE=2 -Werror -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wdeclaration-after-statement -Wmissing-declarations -Wredundant-decls -Wcast-align -g -MT 
Mar 23 02:10:20 <holtmann> zhenhua: So I just checked on my Fedora 12 running on a 32-bit big endian Mac mini. And I do get that warning as well.
Mar 23 02:10:25 <zhenhua> ubutun
Mar 23 02:10:31 <holtmann> Seems that a 64-bit Linux is fine.
Mar 23 02:11:47 <zhenhua> holtmann: so what should I do or let kristen to handle it?
Mar 23 02:11:55 <denkenz> holtmann: heh, probably the magic on glib side
Mar 23 02:12:26 <denkenz> holtmann: Probably does a cast on 64 bit, but nothing on 32
Mar 23 02:12:50 <holtmann> I have fixed it now. I hate global scope variables if they are only used inside.
Mar 23 02:13:10 <zhenhua> okay
Mar 23 02:13:53 <zhenhua> denkenz: again, shall I follow your style to create parse_basic_command?
Mar 23 02:13:56 <denkenz> zhenhua: And yes, you did miss tons of cases, e.g. multiple ?,= per command, etc
Mar 23 02:14:01 <denkenz> zhenhua: Yes if possible
Mar 23 02:14:05 <holtmann> Push is fixed. Check tree, it should sync in a bit.
Mar 23 02:14:11 <holtmann> Fix is pushed ;)
Mar 23 02:14:36 <zhenhua> denkenz: one command contain multiple ?,=?
Mar 23 02:14:50 <zhenhua> can you give an example.;-)
Mar 23 02:15:10 <denkenz> It can't, but you weren't checking the input for those cases
Mar 23 02:15:44 <zhenhua> anyway, i will first work out a version.
Mar 23 02:15:52 <zhenhua> for parse_basic_command.
Mar 23 02:16:14 <denkenz> Not properly handling ';' inside strings, etc
Mar 23 02:16:32 <denkenz> Take the opportunity to think like an attacker and see if there are other cases we're still missing
Mar 23 02:16:39 <zhenhua> yeah, i admit this one
Mar 23 02:18:35 <denkenz> zhenhua: Another homework assignment, we actually can't assume the application will always return synchronously
Mar 23 02:19:06 <zhenhua> so...we need thread?
Mar 23 02:19:27 <denkenz> zhenhua: No, no threads, use event loop
Mar 23 02:20:04 <denkenz> zhenhua: E.g. the callback can defer returning because it is waiting for something (e.g. network)
Mar 23 02:20:13 <zhenhua> i see
Mar 23 02:20:20 <denkenz> zhenhua: So we have to delay command processing until the callback calls send_final
Mar 23 02:20:24 <zhenhua> in at_command_notify, right
Mar 23 02:20:44 <denkenz> Probably in many places, but start there
Mar 23 02:21:03 <zhenhua> and during that period, atserver is hang and waiting for send_final
Mar 23 02:21:17 <zhenhua> should not say hang but is waiting
Mar 23 02:21:38 <denkenz> correct, we can continue reading the socket, but we're not processing commands
Mar 23 02:21:53 <denkenz> and this can also happen mid-command line (e.g. using ';')
Mar 23 02:22:38 <zhenhua> yes. it would make the parser a little bit complex, need to handle it carefully
Mar 23 02:22:46 <denkenz> So you might want to store the last command line (needed for a/ anyway) and the offset of where you are
Mar 23 02:22:55 <holtmann>   CC     gatchat/ppp_cp.o
Mar 23 02:22:55 <holtmann> cc1: warnings being treated as errors
Mar 23 02:22:56 <holtmann> gatchat/ppp_cp.c: In function ‘verify_config_option’:
Mar 23 02:22:56 <holtmann> gatchat/ppp_cp.c:1069: error: cast to pointer from integer of different size
Mar 23 02:22:56 <holtmann> gatchat/ppp_cp.c: In function ‘remove_config_option’:
Mar 23 02:22:56 <holtmann> gatchat/ppp_cp.c:1100: error: cast to pointer from integer of different size
Mar 23 02:22:58 <holtmann> gatchat/ppp_cp.c: In function ‘pppcp_process_configure_ack’:
Mar 23 02:23:00 <holtmann> gatchat/ppp_cp.c:1219: error: cast to pointer from integer of different size
Mar 23 02:23:02 <holtmann> gatchat/ppp_cp.c: In function ‘pppcp_process_configure_nak’:
Mar 23 02:23:04 <holtmann> gatchat/ppp_cp.c:1283: error: cast to pointer from integer of different size
Mar 23 02:23:06 <holtmann> make[1]: *** [gatchat/ppp_cp.o] Error 1
Mar 23 02:23:08 <holtmann> Crap :(
Mar 23 02:23:30 <zhenhua> holtmann: yeah, there're other places need to cast guint8 to guint
Mar 23 02:23:31 <denkenz> heh
Mar 23 02:23:48 <denkenz> holtmann: That whole design needs to be rethought
Mar 23 02:25:03 <denkenz> Or invent a better macro :P
Mar 23 02:25:36 <zhenhua> denkenz: i see you have moved some interfaces to dbus.h. any thought about how to integrate atserver with core?
Mar 23 02:26:23 <denkenz> zhenhua: Me and holtmann still need to discuss it further, but I'm waffling between in-process with ofono (e.g. plugin) and out-of-process
Mar 23 02:26:47 <denkenz> zhenhua: The in-process is ultimately more flexible, but requires lots of changes in the core
Mar 23 02:26:48 <zhenhua> denkenz: sure
Mar 23 02:28:58 <zhenhua> anyway, let me know if i can help.
Mar 23 02:29:14 <zhenhua> now, i still focus on stablize the atserver itself.
Mar 23 02:29:54 <denkenz> zhenhua: Don't worry, you still have plenty to fixup, including a/ and deferred execution
Mar 23 02:30:14 <denkenz> zhenhua: There's also command abortion too ;)
Mar 23 02:30:17 <zhenhua> i know that.
Mar 23 02:30:48 <zhenhua> if you see my mail sent last day, what do you think?
Mar 23 02:31:03 <zhenhua> follow MBM or Huawei's way?
Mar 23 02:31:08 <zhenhua> for basic commands
Mar 23 02:32:18 <denkenz> Sounds like MBM is the better implementation
Mar 23 02:32:27 <denkenz> And more standard-compliant
Mar 23 02:33:28 <denkenz> So yeah, doing proper set with assumed arguments is the way to go
Mar 23 02:33:59 <zhenhua> so we will follow MBM's way.
Mar 23 02:34:19 <denkenz> we'll follow the standard ;)
Mar 23 02:34:20 <holtmann> Some parts of the PPP code are way to nested and complicated. I started fixing them. However this way at least we have a record of the changes.
Mar 23 02:36:23 <denkenz> holtmann: Nod, the nested ifs are something we need to unteach everyone, I see it from lots of people :P
Mar 23 02:37:02 <zhenhua> again, we'd better to have a guideline for code style.
Mar 23 02:37:25 <zhenhua> you cann't keep this secret in your mind.;-)
Mar 23 02:37:57 <denkenz> Not a secret when every bloody file does it this way :P
Mar 23 02:38:31 <zhenhua> how about create a wiki page in some place?
Mar 23 02:38:49 <holtmann> If I find some time, I write a presentation with the bad examples.
Mar 23 02:38:50 <zhenhua> i can draft that. won't take much time actually
Mar 23 02:39:11 <denkenz> holtmann: Time to activate our wiki.ofono.org ;)
Mar 23 02:39:25 <holtmann> This is not about spelling out the coding style. It is more about getting the nasty stuff the university teaches out of the system ;)
Mar 23 02:39:35 <holtmann> It must be learn by examples.
Mar 23 02:40:26 <denkenz> I suggest we do put it up in a wiki too though
Mar 23 02:40:34 <holtmann> zhenhua: However I am more than happy if you start with such a document. Also I don't want a wiki page. I want a simple text documentation inside the source tree itself.
Mar 23 02:40:59 <holtmann> Lets have everything next to the code instead of asking people to go to a website ;)
Mar 23 02:41:20 <denkenz> The doc in the code should also be there
Mar 23 02:41:26 <holtmann> zhenhua: The the code should now compile again on a 32-bit system. If you find more issues, let me know. I will fix them.
Mar 23 02:41:27 <zhenhua> okay
Mar 23 02:41:41 <denkenz> Do all three :)
Mar 23 02:41:58 <denkenz> Maybe that will reach enough people :)
Mar 23 02:42:00 <zhenhua> holtmann: thanks. and will draft a doc inside ofono/doc.
Mar 23 02:42:30 <holtmann> denkenz: The reason why I want text files is that we can easily publish them as HTML or on wiki.
Mar 23 02:44:08 <zhenhua> holtmann: will we support doxygen in the future?
Mar 23 02:44:45 <holtmann> I prefer gtkdoc since it creates nice HTML pages and can create devhelp docs.
Mar 23 02:44:58 <holtmann> However gtkdoc itself is a pretty ugly perl script.
Mar 23 02:45:32 <holtmann> For all of you who haven't installed it, install devhelp and the glib and dbus docs packages. Then you can search the API docs offline as well.
Mar 23 02:46:01 <holtmann> But then again, I am maybe the only person that sits in an airplane and needs access to API, because of no Internet ;)
Mar 23 02:49:16 <zhenhua> heh, let me dig out some details gtkdoc later. ;-)
**** ENDING LOGGING AT Tue Mar 23 02:59:57 2010