**** BEGIN LOGGING AT Thu Jun 24 02:59:58 2010
Jun 24 03:15:01 <denkenz> zhenhua: try it first
Jun 24 03:15:27 <denkenz> zhenhua: May be we need a timeout mechanism in our server implementation
Jun 24 03:18:17 <zhenhua> sure we need timeout handling for server.
Jun 24 03:19:09 <zhenhua> i cann't dial MBM with gsmdial, guess some issues in ppp client code. hmmm...
Jun 24 03:19:32 <denkenz> MBM works, but you might need the right port
Jun 24 03:19:57 <zhenhua> ttyACM0?
Jun 24 03:20:08 <zhenhua> which port shall i use?
Jun 24 03:20:09 <denkenz> don't remember, method of elimination helps
Jun 24 03:20:23 <zhenhua> will try
Jun 24 03:20:31 <denkenz> But as far as I remember we tested ppp on mbm, hso, novatel and huawei
Jun 24 03:20:41 <denkenz> Some ppp dongles don't do it though
Jun 24 03:20:46 <zhenhua> i could even start ppp handshake and server response NAK and ACK
Jun 24 03:20:46 <denkenz> s/ppp/hso
Jun 24 03:21:00 <zhenhua> but later we Conf-Rej server option
Jun 24 03:21:11 <zhenhua> looks weird to me
Jun 24 03:21:45 <denkenz> Try to debug it and post the ppp dump to the mailing list
Jun 24 03:22:05 <zhenhua> sure, will do
Jun 24 03:22:11 <denkenz> It might be that APN is not configured properly
Jun 24 03:22:42 <zhenhua> no i have set APN through -a option
Jun 24 03:23:18 <denkenz> Nod, but if it is wrong some modems just hang up on you after going through initial IPCP handshake
Jun 24 03:24:19 <zhenhua> maybe, but that's no the same case i have now.
Jun 24 03:24:27 <denkenz> And sometimes the firmware shoots itself that you need to re-plug the dongle ;)
Jun 24 03:25:13 <zhenhua> haha. yeah. MBM always try to kill itself when i use it:-D
Jun 24 03:26:08 <zhenhua> how to format output in wireshark, like u post just right now?
Jun 24 03:26:57 <denkenz> That was manual ;)
Jun 24 03:27:17 <zhenhua> okay. lunch time for us. see u.;-)
Jun 24 03:29:43 <denkenz> And mbm works for me, but you need to be root in order to create ppp link with gsmdial, otherwise we just close the ppp session
Jun 24 11:58:54 <kvalo> denkenz: holtmann did some hack to workaround the at chat hangup problem, right? would it make sense to add the same for huawei? unplugging my huawei modem all the time pisses me off
Jun 24 13:24:04 <balrog-k1n> denkenz: should multiple agents be allowed to register?
Jun 24 13:24:22 <balrog-k1n> in principle i don't see why not
Jun 24 13:24:49 <balrog-k1n> when one agent replies all other get a Cancel()
Jun 24 13:40:55 <balrog-k1n> denkenz, holtmann: also, what should happen if the value returned by agent is invalid or there's an error sending that to the card?
Jun 24 14:09:14 <denkenz> balrog-k1n: I don't see the point for multiple agents
Jun 24 14:09:22 <denkenz> balrog-k1n: So feel free to ignore that for now
Jun 24 14:09:59 <denkenz> balrog-k1n: And what can the agent do about an error sending to the card? Nothing probably
Jun 24 14:10:08 <denkenz> So don't do anything
Jun 24 14:15:47 <balrog-k1n> we could retry the call or something
Jun 24 14:16:01 <balrog-k1n> with some indication that previous attempt failed
Jun 24 14:16:21 <denkenz> You could re-send the info to the card without retrying either
Jun 24 14:17:12 <balrog-k1n> yeah, you could try n times, but in the end you'll want the user to make a different choice
Jun 24 14:17:24 <balrog-k1n> and indicate that something's wrong with what the user first chose
Jun 24 14:17:30 <denkenz> I doubt the user would have any clue
Jun 24 14:17:59 <denkenz> Lets see if this is actually a problem first
Jun 24 14:18:10 <denkenz> Or are you running into this issue?
Jun 24 14:18:24 <balrog-k1n> if there's a menu and a given item doesn't work, i'd want to chose another item as a user
Jun 24 14:18:40 <balrog-k1n> or if my client is sending wrong info to ofono i want to know about it too
Jun 24 14:18:57 <balrog-k1n> (like with the current api i sent)
Jun 24 14:19:26 <denkenz> But then the menu doesn't change
Jun 24 14:19:53 <balrog-k1n> right
Jun 24 14:20:15 <denkenz> and doesn't the SIM retry the command?
Jun 24 14:20:54 <balrog-k1n> if the SIM receives the command then it's no problem
Jun 24 14:20:54 <denkenz> e.g. what happens today if the SIM sends a Select Item, and you send a terminal response with the wrong item?
Jun 24 14:21:14 <balrog-k1n> but there may be an error anywhere before that, or the agent may simply return an integer out of range
Jun 24 14:21:31 <balrog-k1n> we wouldn't even send it because we wouldn't know how to encode it
Jun 24 14:21:47 <balrog-k1n> since we have to map the item number to item id
Jun 24 14:21:58 <denkenz> Then structure the API so that the id returned is a byte
Jun 24 14:22:28 <denkenz> Or treat invalid input as a user cancel
Jun 24 14:22:57 <denkenz> I really don't want to overcomplicate the core just because some agent doesn't know what its doing
Jun 24 14:23:01 <balrog-k1n> seems like working around bad api
Jun 24 14:23:38 <denkenz> The simpler it is to write the agent the better
Jun 24 14:23:50 <denkenz> You'll have a hell of a time trying to explain the error conditions
Jun 24 14:24:19 <balrog-k1n> we could simply return some generic error like all the other ofono interfaces do
Jun 24 14:24:37 <balrog-k1n> also the api i proposed does it, so it seems we're going for a poorer api then
Jun 24 14:24:55 <balrog-k1n> it also allows many agents to observe what's happening and one to drive the app
Jun 24 14:28:41 <balrog-k1n> here's an example where returning an error would be useful
Jun 24 14:29:16 <balrog-k1n> you select "top up my account" from the menu, and the modem dies about that time or the sim is removed
Jun 24 14:29:54 <balrog-k1n> if dbus returns success it will mean that the sms or ussd or whatever has been sent, and if it returns an error it means it hasn't
Jun 24 14:30:08 <balrog-k1n> there might have been a network error sending the ussd too
Jun 24 14:32:06 <denkenz> Ok, we're talking about two things here
Jun 24 14:32:16 <denkenz> One is an Agent returning bad data
Jun 24 14:32:24 <denkenz> The other is an Application sending bad data
Jun 24 14:33:05 <balrog-k1n> yes, we have different errors for them, on all the other interfaces
Jun 24 14:33:10 <denkenz> If oFono calls into an Agent saying byte SelectItem(items)
Jun 24 14:33:17 <denkenz> And the Agent returns something wrong
Jun 24 14:33:26 <denkenz> Then we just treat it as a user cancel
Jun 24 14:33:53 <balrog-k1n> sounds ok, but that's already worse than what we have today
Jun 24 14:34:25 <denkenz> Doubtful, the UI cannot do anything with those errors
Jun 24 14:34:33 <denkenz> And informing the user is useless
Jun 24 14:34:50 <balrog-k1n> right
Jun 24 14:34:55 <denkenz> You're going to say to your Granma that sending to the SIM failed?
Jun 24 14:35:05 <denkenz> Think she'll understand?
Jun 24 14:35:07 <balrog-k1n> no, i'm not going to tell that to user
Jun 24 14:35:20 <denkenz> So what's the point? :)
Jun 24 14:35:47 <balrog-k1n> same reason as retuning __ofono_error_invalid_args everywhere else
Jun 24 14:36:01 <balrog-k1n> you're claiming it's pointless everywhere in ofono
Jun 24 14:37:03 <denkenz> See, we agree, but disagree on the implementation
Jun 24 14:37:39 <denkenz> Since the caller-callee relationship is flipped with an Agent, we can't really do error handling
Jun 24 14:37:51 <denkenz> Not without complicating the hell out of the core
Jun 24 14:38:10 <denkenz> For regular Menu Items we can still do invalid_args, error, etc
Jun 24 14:38:10 <balrog-k1n> right, so i'm just saying that it's not optimal to flip it
Jun 24 14:38:14 <denkenz> Just not for Agent ones
Jun 24 14:38:27 <balrog-k1n> that it's not better than the api i proposed on the list
Jun 24 14:39:12 <balrog-k1n> but i'm okay with this tradeoff, just want to make a note that there's a tradeoff
Jun 24 14:39:22 <denkenz> Of course, there's always a tradeoff
Jun 24 14:39:32 <denkenz> But I think in this case its relatively minor
Jun 24 14:40:08 <denkenz> And this is not all set in stone
Jun 24 14:40:09 <balrog-k1n> however the other case is more difficult, where the response returns an actual error and the user needs to know about it
Jun 24 14:40:29 <denkenz> Which response?
Jun 24 14:40:53 <balrog-k1n> we send terminal response to card, and card sends a status different than 0x90, 0x00, so the modem sends ERROR
Jun 24 14:40:59 <balrog-k1n> or the modem dies
Jun 24 14:41:15 <denkenz> The command is still over at that point
Jun 24 14:41:24 <balrog-k1n> i sure would expect a well behave dbus daemon to indicate whether what i sent to it had succeeded
Jun 24 14:42:04 <balrog-k1n> liek when i top up the account or do something else that does something else with my account
Jun 24 14:42:20 <denkenz> You generally get SMS or CBS broadcasts to confirm
Jun 24 14:42:27 <denkenz> Or an immediate Display Text
Jun 24 14:42:39 <balrog-k1n> not if the modem just died
Jun 24 14:42:47 <denkenz> In which case you won't get them
Jun 24 14:42:56 <denkenz> And your phone UI is showing no bars
Jun 24 14:43:02 <balrog-k1n> yeah, and i'm missing an information that i would have with the current api
Jun 24 14:43:06 <denkenz> You reset the phone and try again
Jun 24 14:43:25 <denkenz> You just think you do ;)
Jun 24 14:43:46 <denkenz> Give me your strategy for handling such a case
Jun 24 14:43:59 <balrog-k1n> if there's no network then there's no point for the card to send a display text, it can just return an error status immediately
Jun 24 14:44:17 <balrog-k1n> either way it's not ofono that should decide
Jun 24 14:44:44 <balrog-k1n> i proposed the api in a patch that does something, if i'm to invest time in rewriting it i want the new api to be better :)
Jun 24 14:45:14 <denkenz> Seriously, have you _actually_ encountered a case where the SIM sends an error to the terminal response?
Jun 24 14:45:52 <balrog-k1n> no, but i haven't encountered one where it _actually_ sends a display text or sms confirmation either
Jun 24 14:46:01 <balrog-k1n> it depends on the sim, on the modem, etc
Jun 24 14:46:50 <denkenz> I think you're overcomplicating things
Jun 24 14:47:24 <denkenz> And you need to also step back and look at it from a POV of the guy who has no freaking idea how STK works between oFono and the modem
Jun 24 14:47:44 <balrog-k1n> yeah, i'm looking at it from that point now
Jun 24 14:47:55 <balrog-k1n> if i chose to top my account and it failed, i want a popup that says so
Jun 24 14:48:10 <balrog-k1n> no matter what the reason was for the failure
Jun 24 14:48:27 <balrog-k1n> it might have been some nokia daemon's segfault or whatever
Jun 24 14:50:56 <denkenz> ok, what does the spec say about terminal responses returning an error
Jun 24 14:51:56 <balrog-k1n> there are temporary and permanent, for temporary the modem may retry
Jun 24 14:52:23 <denkenz> No, you're talking about terminal response pdu submission returning an error here
Jun 24 14:52:32 <denkenz> so what does the spec say about that
Jun 24 14:53:08 <denkenz> I'm not going to twist an API for mal-behaved clients
Jun 24 14:53:15 <balrog-k1n> about what exactly? i thought you asked about ther terminal response submission
Jun 24 14:53:35 <denkenz> Ok, so we're considering two things here
Jun 24 14:53:54 <denkenz> 1. oFono calls into the agent and it returns bad data -> oFono generates a cancel / error
Jun 24 14:54:05 <denkenz> 2. oFono calls into the agent, it returns right data -> submission fails
Jun 24 14:54:48 <denkenz> So I really don't care about 1, we just handle it the easiest way we can
Jun 24 14:57:50 <denkenz> my question is, what does spec say about 2?
Jun 24 14:59:34 <balrog-k1n> about situations like some daemon below ofono failing, i'm sure it doesn't say anything
Jun 24 15:00:20 <kvalo> denkenz: holtmann did some hack to workaround the at chat hangup  problem, right? would it make sense to add the same for huawei?  unplugging my huawei modem all the time pisses me off
Jun 24 15:00:36 <denkenz> kvalo: Yeah, check novatel driver for details
Jun 24 15:00:46 <denkenz> balrog-k1n: what daemon below ofono?
Jun 24 15:00:57 <kvalo> denkenz: next question, will you accept such patch from me? ;)
Jun 24 15:01:10 <denkenz> kvalo: Why wouldn't I?
Jun 24 15:02:03 <kvalo> denkenz: just being lazy here, don't want to do extra work :)
Jun 24 15:04:28 <balrog-k1n> denkenz: say there's something like that csd n900 thing running below ofono or a serial driver, doesn't matter
Jun 24 15:04:41 <balrog-k1n> or say there's no network coverage and the card knows about it
Jun 24 15:05:31 <denkenz> I think you're dealing with hypotheticals
Jun 24 15:06:02 <denkenz> and you know how much I encourage that ;)
Jun 24 15:07:12 <denkenz> Besides, any decent SIM application sends a USSD/SMS when the user hits Top Up
Jun 24 15:07:38 <denkenz> Or even sets up a call
Jun 24 15:07:42 <balrog-k1n> yes, we deal with thing much more hypothetical in ofono, than lack of network coverage
Jun 24 15:08:14 <balrog-k1n> it sends an SMS/USSD to the operator to make the top up
Jun 24 15:08:31 <denkenz> exactly, so network coverage has no bearing on the Select Item
Jun 24 15:08:49 <denkenz> so I've no idea what you're arguing for now
Jun 24 15:09:18 <balrog-k1n> i see no reason why the terminal response to select item should not return error if the card can't send the sms
Jun 24 15:10:02 <denkenz> Seriously, I don't want to complicate the API and handle tons of hypothetical cases if those cases never materialize
Jun 24 15:10:43 <denkenz> The whole thing isn't set in stone either, if it doesn't work, we do something else
Jun 24 15:15:07 <denkenz> why don't you try a few sims with top up outside network coverage and report back
Jun 24 15:15:45 <denkenz> especially ones that use Select Item for this and not the regular menu
Jun 24 15:16:22 <balrog-k1n> don't have a phone with stk support right now :)
Jun 24 15:16:43 <balrog-k1n> Select Item is for everything that's not in the main menu
Jun 24 15:16:55 <balrog-k1n> main menu is only about 5-10 top level items
Jun 24 15:18:10 <balrog-k1n> denkenz: so back to the multiple agents support, do you see any problem if i do implement it?
Jun 24 15:19:31 <balrog-k1n> i'm thinking particularly about the clients connecting over http where you can't know when they disconnected, or about observing the state like in the proposed api
Jun 24 15:33:50 <denkenz> I don't see a point for multiple agents
Jun 24 15:34:09 <denkenz> and I think you don't completely know how they work
Jun 24 15:34:16 <denkenz> You can always know when the agent has gone away
Jun 24 15:34:34 <balrog-k1n> http clients that connect every now and then to read state?
Jun 24 15:34:46 <denkenz> That is not an agent ;)
Jun 24 15:35:05 <balrog-k1n> it'll need to be an agent if it wants to drive ofono
Jun 24 15:35:25 <denkenz> Not really, it needs to be an agent to accept stk commands
Jun 24 15:35:33 <denkenz> Not drive other aspects of ofono
Jun 24 15:35:45 <balrog-k1n> yeah, but we're talking about stk applications :)
Jun 24 15:36:02 <denkenz> Then there are no transient agents
Jun 24 15:36:12 <denkenz> agent register themselves and are then tracked by oFono
Jun 24 15:36:20 <denkenz> if it goes away, the agent is unregistered
Jun 24 15:37:58 <balrog-k1n> so what if you don't know that the client went away?
Jun 24 15:38:28 <denkenz> we don't track clients, only agents
Jun 24 15:38:34 <denkenz> and you always know an agent went away
Jun 24 15:39:13 <balrog-k1n> every client now needs to be an agent to have a sim application ui, or am i missing something?
Jun 24 15:39:35 <denkenz> No, there's no rule like that
Jun 24 15:39:45 <denkenz> You can have Dialer, Sim App, homescreen
Jun 24 15:40:02 <denkenz> Only Sim App or Homescreen needs the Agent
Jun 24 15:40:06 <denkenz> Not both
Jun 24 15:40:20 <balrog-k1n> i didn't say every client needs the agent
Jun 24 15:40:33 <balrog-k1n> every client that wants to have a Sim App ui
Jun 24 15:40:56 <denkenz> Which will be 1 / system
Jun 24 15:41:18 <balrog-k1n> unless it's connected over http
Jun 24 15:42:10 <denkenz> Then create a multiplexer in your http daemon
Jun 24 15:42:25 <denkenz> I seriously don't consider that a usecase here ;)
Jun 24 15:43:06 <denkenz> I know where's you're coming from, but oFono is not a generic low level stack
Jun 24 15:43:22 <denkenz> It is meant for the 99% usecase, namely UI apps on a phone/netbook
Jun 24 15:44:05 <balrog-k1n> yeah i agree http probably is not going to be a useful case
Jun 24 15:44:29 <denkenz> again, you can still accomplish what you want with a single agent
Jun 24 15:44:38 <denkenz> You just have to multiplex inside http 
Jun 24 15:44:58 <denkenz> Its more work, but so is multiple agents
Jun 24 16:59:15 <balrog-k1n> is the Release method any useful?
Jun 24 16:59:57 <denkenz> It may be actually
Jun 24 17:00:04 <denkenz> I think BlueZ uses it when an Adapter goes away
Jun 24 17:00:15 <denkenz> so in our case it would be the Modem going away / powering down
Jun 24 17:00:39 <balrog-k1n> the client would find out anyway
Jun 24 17:01:10 <denkenz> yeah, this might be more a consistency thing
Jun 24 17:01:20 <denkenz> I wouldn't worry too much about that one right now
Jun 24 17:01:40 <balrog-k1n> ok, can always be added
Jun 24 17:02:33 <denkenz> exactly, also see if ConnMan uses Release on its agent
Jun 24 17:06:21 <balrog-k1n> the handler is print("Release")\nmainloop.quit() in the python examples, maybe let's add it
Jun 24 17:06:37 <balrog-k1n> ConnMan has two of its own agent interfaces both of which have this method
Jun 24 17:06:50 <denkenz> Ok, so lets add it then
Jun 24 17:07:36 <denkenz> It sort of makes sense anyway, the agent can be much dumber than Dialer / Homescreen
Jun 24 17:08:01 <denkenz> so it doesn't have to care about Powered, etc, especially on hardware that never truly shuts the modem down
Jun 24 17:08:03 <denkenz> e.g. Nokia
Jun 24 17:08:56 <balrog-k1n> to register the agent you need to access the manager object anyway, but Release saves you from listening on it
Jun 24 17:09:32 <denkenz> yep
Jun 24 17:09:43 <denkenz> Its a bit redundant, but the aim is to make it easier on the apps
Jun 24 17:25:38 <balrog-k1n> denkenz: i think it makes sense for the main menu to be handled by the agent too, so when an agent connects we send it whatever command is currently executing or the main menu
Jun 24 17:26:27 <denkenz> Its a bit tricky for the main menu
Jun 24 17:26:36 <denkenz> The timeouts are potentially hours long
Jun 24 17:26:37 <balrog-k1n> the other option is that main menu is always available and when you select something from the menu, you pass a path to an agent at the same time, and if the agent disconnects, we send a quit and go back to main menu
Jun 24 17:27:27 <denkenz> If the agent disconnects we send a user ended session anyway
Jun 24 17:28:11 <balrog-k1n> well we don't have to do that, we could just forward the current command to the next agent that connects
Jun 24 17:28:29 <denkenz> which could be hours or never
Jun 24 17:28:50 <balrog-k1n> we can only send a session ended when a command is executing, there's no envelope for that
Jun 24 17:28:51 <denkenz> be realistic, on a well integrated platform, agents don't just come and go
Jun 24 17:29:11 <denkenz> That's for main menu, that one can be 'always on'
Jun 24 17:30:29 <balrog-k1n> shouldn't a SimApp app be an agent and just register/unregister when you open/close it?
Jun 24 17:30:55 <denkenz> I think of it this way:
Jun 24 17:31:11 <denkenz> HomeScreen registers as the Agent and is always on
Jun 24 17:31:30 <denkenz> Home Screen handles auth tasks like prompting the user to ack Setup Call, Send USSD, etc
Jun 24 17:31:48 <denkenz> Handles Setup Idle Mode text, display text, get input, etc
Jun 24 17:32:07 <denkenz> While the Main Menu is done by a separate SIM Application that you launch
Jun 24 17:32:22 <denkenz> That one can be started, uses GetProperties to grab the menu and displays it
Jun 24 17:32:43 <balrog-k1n> hmm
Jun 24 17:33:06 <balrog-k1n> but then if you select something from the menu, it will send a display text and this will show in the Home Screen
Jun 24 17:33:25 <balrog-k1n> rather than the window where the menu is
Jun 24 17:33:52 <denkenz> well, the menu hasn't changed
Jun 24 17:34:02 <denkenz> And Display Text can happen any time
Jun 24 17:34:11 <denkenz> You have no context whether the display text is related to the menu
Jun 24 17:34:16 <balrog-k1n> right
Jun 24 17:34:32 <denkenz> so you're in a losing proposition here
Jun 24 17:34:40 <denkenz> you have to handle them separately anyway
Jun 24 17:35:17 <denkenz> The entire system is stupid
Jun 24 17:35:33 <balrog-k1n> the question is do we want to handle Display Text outside of the sim-menu app
Jun 24 17:35:34 <denkenz> Lets do the best we can, and we can't do that much
Jun 24 17:35:45 <balrog-k1n> idle text i can understand and i think it should be a property
Jun 24 17:35:56 <denkenz> I think we do, because display Text can be sent by the SIM for various things
Jun 24 17:36:13 <balrog-k1n> okay
Jun 24 17:36:30 <denkenz> Again, this is my feeling right now as to what makes sense
Jun 24 17:36:38 <denkenz> We might find that no network actually uses STK this way
Jun 24 17:36:55 <denkenz> But lets do the simplest thing that works and then go from there
Jun 24 17:37:06 <balrog-k1n> i'm still not sure about the main menu, the long timeouts are not really a problem
Jun 24 17:37:47 <denkenz> I agree, but it seems twisted to do it through an Agent
Jun 24 17:37:53 <balrog-k1n> this way we can handle Select Item and the main menu exactly same way
Jun 24 17:37:54 <denkenz> I'm open to the idea though
Jun 24 17:38:08 <balrog-k1n> rather than one of them be an agent call, and the other a set of properties + 2 methods
Jun 24 17:38:53 <denkenz> Care to come up with a quick Agent proposal and email it to me?
Jun 24 17:39:30 <balrog-k1n> sure
Jun 24 17:39:32 <denkenz> I'm just thinking it'll be extremely kludgy to handle menu this way
Jun 24 17:39:42 <denkenz> But maybe it'll work out
Jun 24 17:39:52 <balrog-k1n> i think both ways are kludgy :)
Jun 24 17:40:22 <denkenz> Well, the lesser kludginess wins
Jun 24 17:40:39 <denkenz> STK is a PoS never really designed properly
Jun 24 17:40:54 <denkenz> The fact that it works is an 8th wonder of the world
Jun 24 17:44:08 <denkenz> Besides, I haven't heard a better idea from you yet ;)
Jun 24 17:45:14 <balrog-k1n> i'll write the api descriptiosn for both proposals and then let's decide
Jun 24 17:45:18 <balrog-k1n> i can send it to the list too
Jun 24 17:45:38 <denkenz> yep, sounds good
Jun 24 17:47:11 <balrog-k1n> actually, i'll do in 30 mins, have to go out before they close stores
Jun 25 02:29:28 <zhenhua> denkenz: any comments for pppd log?
Jun 25 02:33:51 <denkenz> zhenhua: What was the issue exactly?
Jun 25 02:35:28 <zhenhua> we should use Conf-Nak server response instead of Conf-Rej all options
Jun 25 02:35:49 <denkenz> Yeah I told you this in one of my earlier reviews
Jun 25 02:35:59 <zhenhua> once client get local_addr, dns, we should return Ack
Jun 25 02:37:09 <zhenhua> any comments for my latest patches I sent u?
Jun 25 02:37:31 <zhenhua> i will send the ML for review
Jun 25 02:38:15 <denkenz> So one thing you might want to do is accept the Id option for both client and server instead of Rejecting it
Jun 25 02:38:25 <denkenz> We don't particularly care about it
Jun 25 02:39:45 <denkenz> And in ipcp_server_rcr, you need to reject any unrecognized option
Jun 25 02:40:17 <denkenz> So you might want to memcpy the requested option to the rejected options list in the default: label
Jun 25 02:40:22 <zhenhua> Id option?
Jun 25 02:41:41 <zhenhua> if they are unrecoginzed option, why not silient discard? let me see the spec
Jun 25 02:42:14 <zhenhua> how to fill the IP with the type?
Jun 25 02:42:21 <denkenz> Actually nevermind
Jun 25 02:42:28 <denkenz> I'm confused
Jun 25 02:44:41 <zhenhua> so in ipcp_client_rcr, we should also reject unrecogizned option in default option.
Jun 25 02:44:51 <zhenhua> i understand u point now
Jun 25 02:49:06 <zhenhua> denkenz: what is id option in 'accept the Id option for both client and server instead of Rejecting it'?
Jun 25 02:58:41 <denkenz> Nevermind that one
Jun 25 02:58:47 <denkenz> I misread the pppd output
**** ENDING LOGGING AT Fri Jun 25 02:59:57 2010