**** BEGIN LOGGING AT Tue Mar 30 02:59:57 2010 Mar 30 03:05:33 denkenz: i describe my thought in mail and send to u already. Mar 30 03:24:22 denkenz: You advised to pass len as parameter to parse_dataobj_common_byte_array(). Mar 30 03:24:53 But it could be unsigned char * or unsigned int *. Need I split them to two different functions? Mar 30 03:26:01 Or can I use unsigned int for all such len? Mar 30 03:29:58 unsigned int is fine here Mar 30 13:44:10 ygu5_ubuntu: is it desired that stk_cause->has_cause is always set to TRUE? Mar 30 14:17:23 balrog-k2n: In that case yes, the Cause with length 0 is 'special' Mar 30 15:46:58 denkenz: but we already know the length from stk_cause->len Mar 30 15:47:13 has_cause carries no information Mar 30 15:48:28 balrog-k2n: Except we need to know whether it is a null object or an object with len = 0 Mar 30 15:48:42 balrog-k2n: Cause is marked as an optional CTLV Mar 30 15:50:12 yeah, although in that case the parsing will fail and parse_dataobj_cause returns FALSE Mar 30 15:50:31 but i see your point, this saves the caller updating some flag Mar 30 15:51:09 But because it is optional, we never know whether it was there or not Mar 30 15:51:15 So we have to use a flag Mar 30 15:53:12 we know it from the return value :) Mar 30 15:53:29 return value is never propagated up though Mar 30 15:53:48 oh right Mar 30 15:53:50 Just the immediate parser knows and it only fails if the object is mandatory Mar 30 15:54:10 Also remember that this most likely will need to be encoded too Mar 30 15:54:32 So we need to tell whether the object should be included in the CTLV list even if len = 0 Mar 30 17:03:30 holtmann: pon? Mar 30 20:26:58 holtmann: denkenz: btw, I took a look at the output from using cgdata. Everything goes along fine, and the modem accepts our auth response, but then sends "NO CARRIER" the next time we read. Not sure what's up with that. Seems like maybe bad firmware? Mar 30 20:29:12 either that or it expects us to read from a different tty maybe after we transition to the network stage? No idea. Mar 30 20:29:38 CGDATA should not be sent to the control channel, are we doing that by any chance? Mar 30 20:30:35 * kristenc checks gsmdial code Mar 30 20:31:08 actually, I'm using a single tty for control & data when I get this problem. I don't usually test with separate. Mar 30 20:31:59 So when we use such modems for real we'd never use the control channel for ppp Mar 30 20:32:21 We must keep it useable for other atoms Mar 30 20:32:40 the gsmdial code is correct -- so it must just be that we have to use separate data tty. I think marcel also uses a single tty if I recall from one of his mails. Mar 30 20:32:45 * kristenc tests Mar 30 20:33:57 hum, that really doesn't work :). I bet gsmdial is passing in a reference to the wrong tty when you use separate. Mar 30 20:34:58 hum, nope, that looks right. I will have to examine the strace logs and see what is going on. Mar 30 20:37:38 hum, the modem just doesn't repond to us at all if I use the data tty. If I use the control tty, we get through Link Establishment and Authentication phase, but then get a NO CARRIER when we switch to network phase. I wonder if it expects you to start using the control for the first phases, but then switch to the data at the Network phase. That would be annoying. Mar 30 20:41:04 no idea, maybe cgdata doesn't even work there Mar 30 20:41:41 see if *99 on the data port works Mar 30 20:50:51 using the control port for the lcp traffic doesn't seem to work either. Mar 30 20:51:06 * kristenc tests *99 on data port now Mar 30 20:54:48 it does not. Mar 30 20:55:26 oh, oops. I did something wrong... Mar 30 20:58:48 well - it does the same thing as cgdata - except you don't get the NO CARRIER message, you just start getting -EIO when reading on the channel after we get a SUCCESS response to our authentication response. Mar 30 20:59:17 holtmann mentioned that the dongle needs to be pulled out after cgdata fucks up Mar 30 20:59:20 and that is using the data port for all of the traffic -- lcp, chap etc. Mar 30 20:59:43 I don't think that's the problem because it does respond correctly to lcp and chap traffic. Mar 30 20:59:50 but I'll do that and retry. Mar 30 21:00:31 Do you have any other modems? I seriously suspect that Qualcomm firmware is bonkers Mar 30 21:00:58 dude - you were right, that fixed it. weird. Mar 30 21:01:55 I have this gobi thing that I've never tried because it is just a board with no housing and I guess it always looked like it was probably broken. But I can try that out in a little bit. Mar 30 21:02:25 gobi is probably useless Mar 30 21:02:42 I suspected so - when majid gave it to me he couldn't tell me whether it worked or not. Mar 30 21:03:22 just fyi - NetworkManager does not use a separate data and control port with this sierra modem, so it could very well just not work at all. Mar 30 21:03:36 (with cgdata) Mar 30 21:03:44 Very well might be Mar 30 21:04:06 I guess I'll try the gobi anyway just for fun. Mar 30 21:09:37 kristenc: One important advice is to unplug the dongle and try again. Some of this CGDATA stuff really fucks up the firmware. Mar 30 21:17:50 holtmann: thanks, we already did that. Mar 30 21:20:04 kristenc: We need some more debug for LCP. Something like option A received. sending ack etc. Mar 30 21:20:51 If we can't get CGDATA to work properly, we have a few problems with these modems. The *99 legacy mode is not suppose to be used inside a telephony stack. That is more a dialer use case. Mar 30 21:23:12 is there someone at qualcomm who can answer questions for us? Mar 30 21:24:36 I wouldn't count on that. Mar 30 21:24:36 holtmann: pppcp trace does that Mar 30 21:25:09 pppcp_trace has not that many information. At least not easy enough for me to work through them. Mar 30 21:28:55 maybe we should add levels to ppcp trace so you can turn off info you dont want to see. maybe its too much information for you to see what you are looking for. Mar 30 21:33:27 I don't think it is too much information. Just how it is presented. Mar 30 21:35:00 hum, I think I lent the gobi modem to mohammed. Mar 31 01:18:33 denkenz: hah, this tricky async part finally be pushed into upstream. Mar 31 01:19:55 denkenz: but i don't see how you ignore the incoming bytes during processing_cmdline is TRUE. Mar 31 01:29:52 I don't, fix it ;) Mar 31 01:30:26 There are two places that need it, and test the hell out of it Mar 31 01:30:31 But I think we're nearly there Mar 31 01:45:56 denkenz: yes, and i will add basic command register functions Mar 31 02:20:16 denkenz: two places? I only see received_data need to check processing_cmdline. Mar 31 02:23:03 zhenhua1: One other place in case we receive command line like foo\r\n Mar 31 02:23:46 We need to actually stop feeding the parser Mar 31 02:35:07 denkenz: why need to stop? Mar 31 02:35:24 denkenz: stop feeding or stop processing the command line? Mar 31 02:35:45 Cuz I could send you AT+FOO\rAT+BAR\r Mar 31 02:35:53 We should ignore the AT+BAR part Mar 31 02:36:11 At least for now Mar 31 02:36:31 sure, that's patch 2/2 does Mar 31 02:36:56 so i just continue the loop if it is parsing the AT+FOO Mar 31 02:37:21 yeah, just rebase your patch Mar 31 02:40:41 denkenz: sent. now, i am testing the rest part. Mar 31 02:59:54 That one applied **** ENDING LOGGING AT Wed Mar 31 02:59:56 2010