**** BEGIN LOGGING AT Fri Apr 30 02:59:57 2010
Apr 30 13:37:24 <denkenz> kvalo: here
Apr 30 13:37:25 <denkenz> ?
Apr 30 13:37:54 <kvalo> yeah
Apr 30 13:38:42 <kvalo> denkenz: flame away ;)
Apr 30 13:39:06 <denkenz> tell me what is the point of creating struct atmodem_network_registration with a single chat channel?
Apr 30 13:40:17 <kvalo> denkenz: there should be a patch witch adds second field later
Apr 30 13:40:29 <kvalo> *which
Apr 30 13:42:07 <denkenz> holtmann: I don't even get your feedback :)
Apr 30 13:42:41 <denkenz> kvalo: I'm not seeing the follow on patch that touches that struct
Apr 30 13:42:44 <holtmann> denkenz: Feedback on what.
Apr 30 13:43:03 <denkenz> holtmann: kvalo's patch
Apr 30 13:43:22 <holtmann> kvalo: See my replies. I think you are trying to make this a bit more too complicated. The problem has already been solved for other hardware.
Apr 30 13:43:25 <kvalo> denkenz: damn, I guess I did something stupid when I reshuffeled the order
Apr 30 13:43:46 <holtmann> Only leftover to do is dealing with out of band CGREG ;)
Apr 30 13:43:46 <kvalo> holtmann: ok, I'll read it. thanks
Apr 30 13:44:04 <denkenz> kvalo: No I see it now
Apr 30 13:45:38 <denkenz> Yeah, so both approaches suck
Apr 30 13:45:48 <denkenz> Huawei is simply being stupid with their side channel
Apr 30 13:45:50 <holtmann> denkenz: You don't see my replies?
Apr 30 13:46:11 <denkenz> holtmann: No I didn't get your replies, are you suggesting that notifications be handled entirely in the modem driver?
Apr 30 13:46:34 <denkenz> holtmann: as in 'don't understand' ;)
Apr 30 13:47:20 <holtmann> Just reply to the email. I am lost which one you are talking about.
Apr 30 13:48:25 <denkenz> please use ofono_netreg_strength_notify for this.
Apr 30 13:48:26 <denkenz> The Huawei specific details with this stupid extra channel need to be
Apr 30 13:48:28 <denkenz> handled inside the Huawei plugin. Cluttering the core with it is not a
Apr 30 13:48:29 <denkenz> good idea.
Apr 30 13:48:38 <kvalo> holtmann: I agree that they way I did it is ugly. I just was under impression that all AT commands have to be in atmodem driver.
Apr 30 13:49:16 <denkenz> btw, my Huawei modem is setup differently
Apr 30 13:49:28 <denkenz> It has two channels, one for control + events, one for PPP
Apr 30 13:49:37 <kvalo> yeah, I have three
Apr 30 13:50:03 <denkenz> So for that one, we'd need some sort of chat_pair structure anyway
Apr 30 13:50:06 <kvalo> I guess we have to add some kind of logic to sense all that :/
Apr 30 13:50:17 <denkenz> However, the worst part...
Apr 30 13:50:30 <kvalo> denkenz: what's the model of you huawei modem?
Apr 30 13:50:37 <kvalo> *your
Apr 30 13:50:38 <denkenz> When PPP connection is terminated, the modem actually closes the chat channel
Apr 30 13:50:47 <denkenz> E160G
Apr 30 13:51:29 <denkenz> holtmann: So for that case, we'd need to re-open the device within the GPRS context driver
Apr 30 13:51:58 <holtmann> Since we have IO abstraction. What about g_at_chat_reset() ;)
Apr 30 13:52:16 <denkenz> holtmann: So my suggestion is for these cases, we simply grab the modem object, get the 'Events' or 'Data' attribute and open the chat inside the gprs/netreg/gprs context driver
Apr 30 13:52:23 <denkenz> We don't know the file name
Apr 30 13:52:28 <denkenz> chat_reset won't help
Apr 30 13:52:53 <holtmann> Right. good point.
Apr 30 13:53:22 <holtmann> So please then lets not intermix this. The core should not know about the filenames. That is the correct approach.
Apr 30 13:53:43 <holtmann> So basically the GPRS has to be removed and re-added.
Apr 30 13:53:56 <denkenz> It would suck to create a copy-paste of gprs atom just for that
Apr 30 13:54:21 <holtmann> That is not what I meant.
Apr 30 13:54:37 <denkenz> Then I don't get it, kalle's patches don't touch the core
Apr 30 13:54:38 <holtmann> Maybe the GPRS atom just needs a callback for reopen.
Apr 30 13:54:59 <holtmann> We are talking on two different levels here.
Apr 30 13:55:10 <holtmann> Do you wanna talk about GPRS or Kalle's patches?
Apr 30 13:55:29 <denkenz> err..., none of this is actually touching the core
Apr 30 13:55:35 <denkenz> this is a driver issue
Apr 30 13:55:36 <holtmann> He has to solve that CGREG comes on the Huawei I am stupid channel.
Apr 30 13:55:58 <holtmann> So I proposed to it similar to the netreg_status_notify like we have for netreg.
Apr 30 13:56:17 <holtmann> Then we have the case where PPP down closes the TTY.
Apr 30 13:57:07 <denkenz> Yeah, I'm totally lost what you're proposing
Apr 30 13:57:16 <denkenz> there is already ofono_gprs_status_notify
Apr 30 13:57:32 <holtmann> Okay. Then he should just use that one. Sorry, I didn't realize that.
Apr 30 13:58:11 <holtmann> kvalo: Hope you are following.
Apr 30 13:58:52 <kvalo> holtmann: I'm logging all this :)
Apr 30 13:58:53 <denkenz> lol, I hope so too, because I'm lost
Apr 30 13:59:30 <kvalo> and it's first of may parties all over here. I'm not drunk, yet ;)
Apr 30 14:00:04 <holtmann> Let me try again. inside plugins/huawei.c he can open the "event" channel and listen for CREG, CGREG and ^RSSI, parse these and feed them via netreg_status_notify, netreg_signal_strengh_notify and gprs_status_notify.
Apr 30 14:00:29 <holtmann> kvalo: That can be easily fixed, just get a beer. Helps with coding ;)
Apr 30 14:01:17 <kvalo> holtmann: if I can do all that in huawei.c, that's very cool
Apr 30 14:01:22 <denkenz> holtmann: Ok, so my original assumption is correct
Apr 30 14:01:42 <holtmann> Huawei is a pretty stupid modem, yes, I am with you ;)
Apr 30 14:02:17 <denkenz> Ok, so I'm fine doing that, but we still need to fix the issue of re-opening the port in gprs-context
Apr 30 14:02:26 <holtmann> Yes, that is a different issue.
Apr 30 14:02:43 <holtmann> kvalo: Does it also happen to you that the PPP TTY receives HUP when terminating PPP?
Apr 30 14:03:15 <holtmann> denkenz: I was purely looking at the patches on the mailing list.
Apr 30 14:03:50 <kvalo> holtmann: I don't know. ofono segfaults for me when I deactivate gprs context. maybe it crashes because of that?
Apr 30 14:03:51 <denkenz> holtmann: Well I guessed what you meant, you just were extremely cryptic
Apr 30 14:04:12 <holtmann> denkenz: I was understanding myself perfectly clear ;)
Apr 30 14:04:15 <denkenz> kvalo: deactivate context doesn't actually work
Apr 30 14:04:28 <kvalo> I need to leave now, I will be back later
Apr 30 14:04:34 <kvalo> denkenz: oh?
Apr 30 14:04:34 <denkenz> kvalo: You might have to check that I ported it properly for ppp
Apr 30 14:04:45 <denkenz> kvalo: Yeah, that one was a quick hack / port
Apr 30 14:04:54 <denkenz> kvalo: Not sure if I did the  deactivate part properly
Apr 30 14:04:57 <holtmann> denkenz: So for the reopen part. I think we should solve this generic inside GAtChat.
Apr 30 14:05:14 <holtmann> What about adding a g_at_set_hangup_function().
Apr 30 14:05:17 <kvalo> denkenz: thanks, that's good to know.
Apr 30 14:05:34 <denkenz> holtmann: we already have a disconnect function
Apr 30 14:05:42 <holtmann> Is that the same?
Apr 30 14:05:54 <denkenz> holtmann: disconnect is called when the other side hups
Apr 30 14:05:55 <holtmann> It gets called on HUP. Stupid me asking since I neve used it.
Apr 30 14:06:05 <holtmann> Okay. So lets use disconnect then.
Apr 30 14:06:22 <denkenz> holtmann: Doesn't help unless we also add reopen(GIOChannel *foo)
Apr 30 14:06:23 <holtmann> And having a g_at_chat_reopen(GAtChat, GIOChannel).
Apr 30 14:07:01 <denkenz> The other nasty complication is that it hups for x seconds
Apr 30 14:07:58 <holtmann> So the plugins/huawei.c code needs to figure something out here. Suspend the chat before calling disconnect callback. And reopen then resumes it.
Apr 30 14:08:08 <holtmann> Question is if we have to tell the GPRS atom something about this.
Apr 30 14:08:14 <denkenz> that's the issue
Apr 30 14:08:27 <denkenz> gprs atom can't start the context activation during a hup
Apr 30 14:08:49 <holtmann> Can we just gprs_status_notify(searching) or something.
Apr 30 14:09:04 <holtmann> Or busy, or invalid, or suspend or something like that.
Apr 30 14:09:09 <denkenz> don't even go there ;)
Apr 30 14:09:32 <denkenz> Anyway, this requires more thought
Apr 30 14:09:45 <holtmann> I am thinking from a pure ConnMan point of view who would use this context.
Apr 30 14:09:45 <denkenz> However, opening the modem channel within gprs-context is actually easiest
Apr 30 14:10:07 <holtmann> Don't mix device names into the src/* or drivers/* code.
Apr 30 14:10:27 <holtmann> You are getting potential race conditions like crazy
Apr 30 14:10:41 <holtmann> Let all the udev and modemconf magic nicely in plugins/*
Apr 30 14:10:44 <denkenz> well, I'd use the modem_get_property
Apr 30 14:11:15 <holtmann> Still not gonna work. Since every modem detection plugins can use these as they feel like.
Apr 30 14:11:23 <holtmann> You are starting a mess here now.
Apr 30 14:11:42 <denkenz> Yeah, I know, but we can make a gprs-context specifically for this Huawei behavior
Apr 30 14:11:59 <denkenz> and either pass it a struct (GAtChat, String), or set a property
Apr 30 14:12:03 <holtmann> That we could do, but then again, this maybe a big issue with other modems as well.
Apr 30 14:12:19 <denkenz> The Option modem doesn't HUP, neither does MBM
Apr 30 14:12:27 <denkenz> have to test others
Apr 30 14:12:40 <holtmann> So one problem could be that the device node actually changes.
Apr 30 14:12:56 <holtmann> plugins/* could detect this and then just open the new node.
Apr 30 14:12:56 <denkenz> when?
Apr 30 14:13:39 <holtmann> Potentially all the time. Of course already opened fd are fine, but renaming can happen. Especially when HUP or something real stupid like USB disconnect.
Apr 30 14:13:54 <holtmann> You can only handle this with the help of udev.
Apr 30 14:14:00 <denkenz> Which is why I want to use a property
Apr 30 14:14:23 <holtmann> Lets go one step back here.
Apr 30 14:14:42 <holtmann> You need to signal this to ConnMan in a way it understands that the GPRS is currently not available.
Apr 30 14:14:47 <denkenz> Problem with reopen and communication between modem driver & context driver is that it gets even nastier
Apr 30 14:15:08 <holtmann> Lets go at this from the top to bottom, not the other way around.
Apr 30 14:15:13 <denkenz> sure
Apr 30 14:15:29 <holtmann> So ConnMan needs to know if it can't open the context. Meaning calling Activate would fail.
Apr 30 14:15:40 <holtmann> How do you wanna signal that?
Apr 30 14:15:53 <denkenz> The core doesn't even know, nothing we can do
Apr 30 14:16:14 <holtmann> Hence we have to tell the GPRS atom if we HUP.
Apr 30 14:16:14 <denkenz> Besides, this can be solved in the driver
Apr 30 14:16:19 <holtmann> No it can not.
Apr 30 14:16:28 <denkenz> yes it can, it can simply add a busy wait
Apr 30 14:16:42 <holtmann> ConnMan needs to know that GPRS is not available right now. We need to switch to something else.
Apr 30 14:16:58 <holtmann> Especially if it takes multiple seconds before it comes back.
Apr 30 14:16:59 <denkenz> ConnMan does know that the context is not active
Apr 30 14:17:11 <holtmann> Yes, but it would try to re-activate it.
Apr 30 14:17:23 <denkenz> yes, and it'll take some time regardless
Apr 30 14:17:32 <denkenz> so you shouldn't switch your connection until it is active
Apr 30 14:17:35 <holtmann> If reactivation takes 10 seconds, then that is not acceptable. In that time it could try something else.
Apr 30 14:18:00 <denkenz> shrug, tough.  My Option modem takes 30-60 seconds to activate the first time
Apr 30 14:18:11 <denkenz> and at least 10 the subsequent times
Apr 30 14:18:18 <holtmann> Mine doesn't.
Apr 30 14:18:29 <holtmann> Your AT&T network at your place must really suck.
Apr 30 14:18:47 <denkenz> T-Mobile, but my point is, these things do take time
Apr 30 14:18:57 <denkenz> especially if the signal is low
Apr 30 14:19:21 <denkenz> If the hardware goes off the bus for a second, we shouldn't fake stuff
Apr 30 14:19:22 <holtmann> Yes, they can take time, but that are things where we have no clue and no way to figure it out.
Apr 30 14:19:33 <holtmann> In this case we know. The hardware is not available. So why bother trying.
Apr 30 14:19:35 <denkenz> we should simply wait
Apr 30 14:19:59 <holtmann> That is my point. Not fake something. Just tell ConnMan that hardware is unavailable.
Apr 30 14:20:08 <holtmann> Or call it resources or whatever.
Apr 30 14:20:19 <holtmann> Just letting us activate and wait and see, that is faking it.
Apr 30 14:20:30 <denkenz> It hups and resets quickly enough that this isn't required IMO
Apr 30 14:20:53 <holtmann> Okay. I need to test this by myself. Maybe you just have one of the really fucked Huawei modems/.
Apr 30 14:21:14 <denkenz> Hey, it doesn't do the unsolicited channel BS
Apr 30 14:21:20 <denkenz> So it can't be 'really fucked' ;)
Apr 30 14:21:47 <holtmann> They fixed that and fucked it up on a different level ;)
Apr 30 14:22:03 <denkenz> The HUP time itself isn't the issue
Apr 30 14:22:17 <denkenz> The issue is that we can't open the device from within the disconnect callback
Apr 30 14:22:30 <denkenz> We probably need to wait 100ms or something
Apr 30 14:22:48 <denkenz> So that 100 ms is where you get race conditions
Apr 30 14:23:44 <holtmann> You could do g_at_chat_suspend() in the disconnect callback, g_timeout_add. And the g_at_chat_reopen() + g_at_chat_resume().
Apr 30 14:23:55 <holtmann> In the timeout callback.
Apr 30 14:24:11 <denkenz> suspend is actually pointless, we need to reinit everything
Apr 30 14:24:58 <holtmann> The suspend / resume was more targeted to not throw the command queue away.
Apr 30 14:25:11 <denkenz> but it also assumes that the modem hasn't hupped
Apr 30 14:25:39 <denkenz> See this is fucked, imo the easiest is to just re-open the chat during context activation
Apr 30 14:26:05 <denkenz> And close it during deactivation
Apr 30 14:26:30 <holtmann> I disagree. That should be kept separated. It can be done inside the plugin itself. Otherwise you need some magic Huawei GPRS context driver.
Apr 30 14:26:49 <denkenz> we might need that anyway
Apr 30 14:26:59 <denkenz> And again, ideally we shouldn't do this
Apr 30 14:27:02 <holtmann> What else is so special about Huawei?
Apr 30 14:27:07 <denkenz> But this is just a stupid case
Apr 30 14:27:36 <holtmann> No argument here. Huawei is pretty much fucked firmware. On different levels with different devices as it seems :(
Apr 30 14:28:07 <denkenz> Get Majid to send you the E160G
Apr 30 14:28:13 <denkenz> he should still have 2-3 available
Apr 30 14:28:34 <denkenz> I will try to test the timing of the hup after I come back from vacation
Apr 30 14:29:06 <denkenz> maybe its a fake hup
Apr 30 14:29:43 <holtmann> Hope that it is not a kernel bug with some signal issues. Anyhow, I asked Majid to send me one. Lets see how quick he is.
Apr 30 14:30:15 <holtmann> denkenz: Other than that, start enjoying your vacation.
Apr 30 14:30:33 <holtmann> I go and look at ConnMan patches now ;)
Apr 30 14:30:48 <denkenz> not today I'm not ;)
Apr 30 16:27:49 <denkenz> holtmann: Another funny one, both the Huawei and the Option firmware fuck up when the context APN is wrong
Apr 30 16:28:09 <denkenz> holtmann: They simply stop responding :)
Apr 30 16:35:16 <holtmann> Meaning wrong APN for that network?
Apr 30 16:35:46 <holtmann> With the Novatel you get NO CARRIER as past of the IPCP negogiation.
Apr 30 16:36:11 <holtmann> s/past/part/
Apr 30 16:41:57 <denkenz> holtmann: Yeah, wrong APN
Apr 30 16:42:12 <holtmann> Check the PPP stream for NO CARRIER.
Apr 30 16:42:19 <denkenz> holtmann: The Option hardware simply stops responding, so our IPCP negotiation fails, but we never get a disconnect callback
Apr 30 16:42:42 <denkenz> holtmann: ok, will check
Apr 30 16:42:48 <holtmann> As I said, dump it in pppdump and open it. My Novatel has NO CARRIER embedded between two ~
Apr 30 16:43:08 <holtmann> This whole PPP stuff is utterly crap with the modems.
Apr 30 16:43:18 <holtmann> It is so good that they are moving away from it.
Apr 30 16:43:27 <holtmann> If they just would find a common spec. for it.
Apr 30 16:44:02 <denkenz> yeah right, this shit is all ultra secret
Apr 30 16:44:13 <denkenz> So that means they all get it wrong, but differently
Apr 30 16:47:45 <denkenz> holtmann: Yep, you're right, embedded NO CARRIER
Apr 30 16:47:47 <denkenz> rcvd "\0d\0aNO CARRIER\0d\0a"
Apr 30 16:57:09 <holtmann> All these Qualcomm ones seems to be same stupid.
Apr 30 16:57:41 <holtmann> Drove me nuts btw.
Apr 30 16:57:53 <holtmann> Took me two days to figure out what the fuck I was doing wrong.
Apr 30 16:58:14 <holtmann> Would not have guessed this.
Apr 30 16:58:33 <holtmann> Hence the pppdump support :)
Apr 30 17:01:22 <denkenz> yeah, problem is it means we need to stuff the syntax into HDLC
Apr 30 17:02:41 <denkenz> Btw, can we make our HDLC send frames with a flag on the beginning and the end?
Apr 30 17:02:58 <holtmann> Yes we can. Why?
Apr 30 17:03:47 <holtmann> It is an optimization to not include beginning and ending flags. Only one is really needed.
Apr 30 17:04:01 <denkenz> I know, but all stacks seem to do both flags
Apr 30 17:04:13 <denkenz> Maybe at some point one will get confused
Apr 30 17:04:25 <holtmann> Then we can do that as well. The ones in between are empty PPP frames that silently get dropped.
Apr 30 17:04:46 <denkenz> I know, but I also abuse this in the GAtSyntax
Apr 30 17:04:59 <denkenz> since I can skip everything between ~..~
Apr 30 17:05:05 <holtmann> It is not guaranteed that the remote side will do this all the time.
Apr 30 17:05:20 <holtmann> Really you should not rely on it.
Apr 30 17:05:39 <denkenz> Its only for those really silly modems that send the first PPP frame before the connect
Apr 30 17:05:52 <holtmann> That one, yeah, that should be fine.
Apr 30 17:06:01 <holtmann> As I said, it is just an optimization.
Apr 30 17:06:27 <denkenz> Nod, I know its fine, but something we might have to keep in mind
Apr 30 19:58:08 <denkenz> holtmann: for ppp connect / disconnect functions, do we want to tweak them a bit?  Right now it is really hard to figure out when we should call connect callback with a failure, and when disconnect should be called instead
Apr 30 19:59:50 <holtmann> What do you have in mind.
Apr 30 20:00:18 <denkenz> so instead of connect being called with an enum, only call connect when the interface is up
Apr 30 20:00:40 <denkenz> in all other cases call disconnect with a failure code (e.g. peer closed, link dead, auth failure, ipcp failure, etc)
Apr 30 20:00:49 <holtmann> And call disconnect in case of error. Sounds fine to me.
Apr 30 20:03:07 <denkenz> ok, it is a bit backwards, but becomes a bit nasty otherwise
Apr 30 20:39:00 <denkenz> Hmm, now how to solve the silly no carrier issue...
Apr 30 20:48:43 <denkenz> holtmann: Btw, "
Apr 30 20:48:45 <denkenz> It is suggested that implementations will achieve the best results by
Apr 30 20:48:46 <denkenz>    always sending an opening Flag Sequence if the new frame is not
Apr 30 20:48:48 <denkenz>    back-to-back with the last
Apr 30 20:48:49 <denkenz> "
Apr 30 20:49:25 <holtmann> Okay. That is fine. I was just optimizing it.
Apr 30 20:49:42 <holtmann> About the no carrier issue, I don't know. We have to detect it somehow.
Apr 30 20:51:50 <denkenz> In theory we can send everything to the syntax when we're not within a frame
Apr 30 20:52:00 <holtmann> Maybe a good idea.
Apr 30 20:53:07 <denkenz> However, that means we must pass in a syntax to HDLC
Apr 30 20:53:10 <denkenz> That is a bit nasty
Apr 30 20:54:24 <holtmann> Can just have something like set_syntax(hdlc, syntax) so that only chat based systems give the syntax.
Apr 30 20:56:14 <denkenz> So here's my thinking, we do a g_at_chat_suspend, gatppp_new, syntax = g_at_chat_get_syntax, hdlc_set_syntax(hdlc, syntax)
Apr 30 20:56:52 <holtmann> Just wrap it around g_at_ppp_set_syntax().
Apr 30 20:57:00 <denkenz> actually, not going to work...
Apr 30 20:57:05 <holtmann> We need to hide the HDLC detail here. No one should care.
Apr 30 20:57:20 <denkenz> I'm thinking we need to have these notifications magically show up on the original chat object
Apr 30 20:58:07 <holtmann> We could just have g_at_ppp_set_chat()
Apr 30 20:58:28 <holtmann> Since that is what you really want from a pure user perspective.
Apr 30 20:58:29 <denkenz> not without exposing the chat feed function
Apr 30 20:58:57 <denkenz> and really you probably want it the other way, g_at_chat_set_online_handler()
Apr 30 20:59:43 <denkenz> However, I'm starting to think we're going down the wrong path here
Apr 30 21:00:38 <denkenz> We should just forget about this and always close the chat when ppp drops
Apr 30 21:00:46 <denkenz> Then re-open the device
Apr 30 21:01:22 <holtmann> You mentioned that we have to deal with these things since CONNECT is not a final response.
Apr 30 21:02:05 <denkenz> But that is assuming we actually want to use the port for something
Apr 30 21:02:13 <denkenz> I'm now thinking that's silly
Apr 30 21:02:27 <denkenz> The only thing we should send to the port is an ATD
Apr 30 21:02:32 <denkenz> or +CGDATA
Apr 30 21:02:43 <holtmann> So in theory we wanna support dropping out of PPP and send an AT command, then go back to PPP stream.
Apr 30 21:03:25 <holtmann> However maybe that is not really pratical.
Apr 30 21:04:19 <denkenz> yeah, the only way to do that is to parse everything through yet another syntax looking for +++
Apr 30 21:05:23 <holtmann> Is it not enough to just feed the data into syntax and then it goes into chat anyway.
Apr 30 21:05:30 <denkenz> This is only really needed on modems like Huawei, for real hardware we can create as many mux channels as we want
Apr 30 21:06:10 <denkenz> no, unfortunately chat drives the syntax, not the other way around
Apr 30 21:06:29 <denkenz> so we'd have to call into chat's new_bytes function
Apr 30 21:10:08 <holtmann> Why? The ->feed function is exposed.
Apr 30 21:11:04 <holtmann> The result handling is in new_bytes, I see.
Apr 30 21:11:30 <holtmann> So we need g_at_chat_feed_input() function.
Apr 30 21:12:05 <denkenz> yep, something like that
Apr 30 21:12:29 <denkenz> so all this gets totally hairy and hard to explain 
Apr 30 21:12:40 <holtmann> So that would need to resume chat, process the input and the resume again or something.
Apr 30 21:13:31 <holtmann> of course suspend ;)
Apr 30 21:13:44 <denkenz> yep, except if you have more data than just NO CARRIER in the buffer
Apr 30 21:13:52 <denkenz> Chat will happily run the syntax over that too
Apr 30 21:14:01 <denkenz> probably OK in this case
Apr 30 21:15:59 <holtmann> I think we might be good actually. These are small cases with one or two lines. If we have more input then there are other problems.
Apr 30 21:17:56 <denkenz> that is probably true
Apr 30 21:37:01 <denkenz> Only issue with all of this is that we don't know when we're inside an HDLC frame :(
**** ENDING LOGGING AT Sat May 01 02:59:56 2010