| 00:43.07 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:43.08 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:10.04 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:10.04 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 03:20.00 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 03:20.00 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 04:54.20 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 04:54.20 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:54.21 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 04:54.21 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 06:31.35 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 06:31.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:44.11 | snuff-work | wedhorn: ping? |
| 06:54.12 | wedhorn | pong |
| 06:54.41 | snuff-work | i has some ideas for the soft key config stuff.. i really suck @ bitmasking :) |
| 06:54.56 | snuff-work | took me most of the day to remember how to |
| 06:55.08 | wedhorn | cool, I was thinking a function that creates the bitmask may be easier |
| 06:56.38 | snuff-work | http://pastebin.com/JpEk5Rtx |
| 06:57.26 | snuff-work | my rough idea.. so u can set a device + line masks |
| 06:57.48 | snuff-work | figure the line mask goes in line.. ph in device.. |
| 06:58.14 | snuff-work | course i haven't even got it working yet but ideas are ticking over.. |
| 06:58.54 | wedhorn | okay, you lost me with your pastebin, not that that means much |
| 06:59.48 | snuff-work | k will put slightly more thought into 1 more pb |
| 07:00.15 | wedhorn | backing up a bit, we've about 15 keysets, each can have 0 (although practically should be 1) to (dunno, 16?) |
| 07:00.57 | wedhorn | each could have theoretically "lots" of keymasks (but practically probably only a few) |
| 07:01.09 | wedhorn | probably usually just 1 |
| 07:02.10 | snuff-work | http://pastebin.com/6DPkmdrc |
| 07:02.21 | wedhorn | wouldn't we want a struct for each keyset that holds the keys (fixed set or a list) and a list of masks? |
| 07:02.38 | snuff-work | might even just state it as disabledonhookkeys or something |
| 07:02.52 | wedhorn | ah, you're talking reading the config? |
| 07:03.10 | snuff-work | and when it comes to setting masks.. |
| 07:03.33 | snuff-work | we have to define new keysets per device.. unless they want the default |
| 07:04.28 | snuff-work | aka for each of onhook/offhook/dafd |
| 07:05.17 | wedhorn | why wouldn't you just load up the default and overwrite any that happen to be specified? |
| 07:06.00 | wedhorn | I don't think you want the mask in the config. skinny should decide whether a button is disabled or not |
| 07:06.29 | snuff-work | but.. say i have a device with 2 lines.. 1 allows cfwd.. 1 doesn't |
| 07:07.08 | wedhorn | that should be a general config allowcfwd=no, rather than trying to fiddle with bitmasks |
| 07:07.37 | snuff-work | guess it depends how configurable u want to me |
| 07:07.38 | snuff-work | *be |
| 07:08.18 | wedhorn | I think we disable a button when it is not usable in that callstate |
| 07:08.51 | wedhorn | so if forwarding is disabled for a line, it should appear disabled for all keystates on that line |
| 07:10.00 | wedhorn | going back to your 'dial now', it should only be greyed when it is not sensible but may become usable |
| 07:10.20 | snuff-work | i understand that 1.. |
| 07:11.03 | snuff-work | when we make the keystate for a device.. if its non standard (aka offhook was to only have 'redial'/endcall) |
| 07:11.04 | wedhorn | So if callfwd is greyed out and the user asks when, should the answer be because the bitmask does it or because callfwd is disabled on that line |
| 07:12.30 | wedhorn | while you could go to extremes with putting weird buttons in places, I think it's better to work on the basis that people may want to swap the order of buttons or possibly to add buttons |
| 07:12.34 | snuff-work | i will attempt later tonight to see if i can manage to cobble together some code that makes coherent sense |
| 07:13.39 | snuff-work | to save my brain and compile errors etc.. probably wont be direct patch on chan_skinny |
| 07:14.10 | snuff-work | more fully complete pseudo code / comment code |
| 07:14.10 | wedhorn | I think we need to work through the struct that we stores these keysets |
| 07:14.39 | snuff-work | i was thinking of storing keysets per device |
| 07:15.02 | snuff-work | because that's the only place u can get ur buttons on/off... |
| 07:15.28 | snuff-work | aka an ast_list or similar of keysets.. |
| 07:16.42 | snuff-work | we know the 'logical' keys to disable (by mask) by iterating the keyset looking for the SOFTKEY_xxx |
| 07:18.29 | snuff-work | we know which keyset index to look at because of our defines also.. |
| 07:18.43 | snuff-work | so won't even need to iterate the list of keysets.. |
| 07:19.20 | snuff-work | on load we set each devices keysets to the 'default' static ones.. if they specify their own use that instead |
| 07:21.25 | wedhorn | yep, that all sounds right (especially given that we send keysets to the device) |
| 07:22.15 | snuff-work | so each skinny device would have a struct soft_key_definitions softkey[no of softkey sets]; (rather than dynamic ) |
| 07:23.17 | snuff-work | then we just add each keyset simliar to what that current const struct one does.. |
| 07:23.37 | snuff-work | gotta go.. i think we have progress/understanding :) |
| 07:23.40 | snuff-work | *train* |
| 07:29.33 | wedhorn | snuff-home: if you look when you get there ;) |
| 07:30.36 | wedhorn | the number of keysets for each device would be the same (eg keyset 1 is used when the device is onhook) |
| 07:32.04 | wedhorn | but each keyset can have a different set of keys, in any order, but are limited to defined keys (0x00 to 0x14, or 0x15 with force dial) |
| 07:33.49 | wedhorn | each keyset could have 1 or more (numerous) bitmasks - this is theoretical as the force dial patch would result in all keysets only having one bit mask and the DAFD would have 2, but it is possible that we may add more |
| 07:36.31 | wedhorn | it'd be handy if we could call the bitmask by some sort of name (eg set_keyset(KEYDEF_DADFD, NOFORCEDIAL)) |
| 07:37.43 | wedhorn | or possibly with some easy buttontype masking(eg set_keyset(KEYDEF_DADFD, ALLBUTTONS&!FORCEDIAL) |
| 07:38.33 | wedhorn | actually, if we can do that, we probably don't need to keep bitmasks for each state, just keep the current one with the sub and only set an update if it's changed... |
| 08:16.39 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:7524:13b:4b5b:4844) |
| 08:44.47 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.226.79) |
| 08:44.47 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:49.36 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 09:25.38 | *** join/#asterisk-dev jmls (~somefake@77.107.171.82) |
| 10:39.49 | snuff-home | wedhorn: that's partially what i already said :).. we can call via the set_keyset(d->keyset[KEYDADFD],...) the mask added like u've shown is cool idea though |
| 10:47.31 | wedhorn | snuff-home: not quite what I meant, try set_keyset(d, KEYDADFD, ALLBUTTONS&~FORCEDIAL). So pretty much the same call as current with the exception of the added bitmask |
| 10:48.25 | wedhorn | there is no point in referencing a keyset structure as the keysets are sent when the device registers and keyset only send the appropriate reference |
| 10:50.23 | snuff-home | true.. we only care bout the mask at this point.. any user def keys cannot be masked.. or how u want to approach that ? |
| 10:51.08 | wedhorn | I don't know, if someone decides to add a redial button to a connected call, what should we do with it |
| 10:51.36 | wedhorn | but its not limited to softkeys, what should we do with a hard button redial in the middle of an active call? |
| 10:51.52 | snuff-home | mm.. good q.. they can't really make 'custom' buttons without coding for it to have some use |
| 10:52.14 | wedhorn | probably do the same for a softbutton (so it behave similarly if someone is silly enough to add it to a connected state) |
| 10:52.36 | wedhorn | no true, skinny includes hardbutton devices |
| 10:52.42 | wedhorn | they are always there |
| 10:53.17 | snuff-home | mm i should try doing a keyset with only make call.. nothing after answer.. |
| 10:53.27 | snuff-home | see if it still puts up other buttons |
| 10:53.29 | wedhorn | basically, chan_skinny should be able to handle any softbutton in any call state |
| 10:53.52 | wedhorn | like it has to handle any hardbutton in any callstate |
| 10:54.33 | snuff-home | i never seen a hard button phone.. only used 40/41's n 60/61's |
| 10:55.19 | *** join/#asterisk-dev jmls (~somefake@77.107.171.82) |
| 10:55.50 | wedhorn | got some 30vips, they are purely hard button. I think there are some 79xx (7910?) that have some hard buttons as well |
| 10:56.25 | snuff-home | damn u freecell.. play nice |
| 10:56.39 | snuff-home | (stuck same game for 5 tries ;) |
| 11:07.16 | wedhorn | snuff-home: partial patch for you http://pastebin.com/2ZUaVn3g |
| 11:08.07 | wedhorn | note at the bottom that we can set the keymask on the fly with ALL&~SOME |
| 11:10.07 | wedhorn | excuse some of the coding (such as the not using the first bit in the KEYMASK_ defines), too many beers followed by too much rum |
| 11:10.39 | snuff-home | heh |
| 11:11.12 | wedhorn | but hey, it works |
| 11:11.33 | snuff-home | it does? |
| 11:13.00 | wedhorn | yep, when i offhook, cfwdall is greyed (as per last line of the pastebin) |
| 11:13.33 | snuff-home | mm.. ur foo is much stronger than mine.. |
| 11:14.17 | wedhorn | nah, i've probably just got a decade on you with fiddling with skinny |
| 11:14.35 | snuff-home | i think i'll still spend another 20 minutes figuring out how it workin |
| 11:15.14 | wedhorn | dont try to understand keyset_translatebitmask |
| 11:15.15 | snuff-home | how are u making sure u disable cfwd all... when it could be any button number |
| 11:15.47 | wedhorn | if you get that then you can understand transmit_softkeysetres |
| 11:16.01 | wedhorn | cycle through each keyset |
| 11:16.09 | wedhorn | iterate even |
| 11:16.13 | snuff-home | in my poor mans effort earlier today i would scan the template of on_hook.. looking for the SOFTKEY_CFWDALL |
| 11:16.29 | snuff-home | number so then i knew to disable that button |
| 11:16.59 | wedhorn | translatebitamask takes a keyset_int and the mask |
| 11:17.21 | wedhorn | iterates through all keysets til it finds the correct on (default sets) |
| 11:17.50 | wedhorn | then iterates through each button in that keyset and sets the mask |
| 11:19.25 | wedhorn | basically defaults[y] will give the y'th button in the appropriate keyset, I offset that many bits and check it against the intmask (which is based on the same offsets) |
| 11:19.32 | snuff-home | mm i get most of it.. |
| 11:19.52 | snuff-home | aka finding right keyset etc.. |
| 11:21.03 | snuff-home | its the finding the cfwd key in the set and then masking it.. that i'm just not getting.. |
| 11:21.55 | snuff-home | like i said when i was coding my idea earlier.. i'd look for the number for softkey_cfwdall.. in that softkey def.. to then mask correct key |
| 11:22.25 | wedhorn | okay we send in ALL&~CFWDALL (that's 1111111111111111 & 11111111101111111 which is 11111111101111111 - ie 7th bit not set) |
| 11:22.51 | snuff-home | yes i get that part |
| 11:22.54 | wedhorn | that and the keysetno gets passed to translate |
| 11:23.14 | wedhorn | iterate through keysets til we get to the correct one |
| 11:23.20 | snuff-home | and that |
| 11:23.26 | wedhorn | sorry if i'm stating the obvious |
| 11:24.24 | wedhorn | grab the pointer to softkeymode->defaults (which is the bunch of int8's that make up each keyset) |
| 11:24.52 | wedhorn | iterate through each int8 which are the softbuttons |
| 11:25.22 | snuff-home | so like the 'softkey cfwdall = 0x05' |
| 11:25.31 | snuff-home | through 0x07 |
| 11:25.47 | wedhorn | now, when we get to the 3rd button (which is 0x05 ... |
| 11:27.02 | snuff-home | k |
| 11:27.13 | wedhorn | we test intmask (which has the 7th bit nul) with 1<(0x05+1) |
| 11:27.41 | wedhorn | if it's true, we set the 1<<3 to 1 else set it to 0 (ie the 3rd button) |
| 11:27.46 | snuff-home | see that's the line i didn't get :) |
| 11:28.33 | wedhorn | intmask = 10111111 and (1<<0x05+1) = 01000000 |
| 11:28.40 | wedhorn | & = 00000000 |
| 11:28.52 | wedhorn | man, that is messy as hell |
| 11:29.10 | wedhorn | intmask 10111111 |
| 11:29.25 | wedhorn | test (1<<0x05+1) = 01000000 |
| 11:29.44 | wedhorn | 10111111 & 01000000 = false |
| 11:31.30 | wedhorn | ah sorry, forgot to say. Have a look at the top of the code, those KEYMASK_ offsets align with the SOFTKEY_ numbers |
| 11:31.43 | wedhorn | ie, if you know the softkey, you know the offset |
| 11:32.00 | wedhorn | well, they sort of align, they're off by one |
| 11:32.29 | snuff-home | yep was bout to say off by 1.. |
| 11:33.04 | snuff-home | now i get how it works.. |
| 11:33.10 | wedhorn | yeah, blame that on the beer and rum |
| 11:33.40 | snuff-home | like i was saying i didn't understand how u got the magic.. now it makes sense since the keymask and the sofkey values match |
| 11:34.27 | snuff-home | is a crap coder.. n bows to ur foo |
| 11:37.37 | wedhorn | and google helps |
| 12:38.44 | *** join/#asterisk-dev alsuren (~dlaban@80.169.133.251) |
| 13:55.37 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-rxaojrzcyyggnxoc) |
| 13:59.22 | *** join/#asterisk-dev sustav (~vpp@nat/digium/x-bggiogjpozehahkc) |
| 14:04.25 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:04.25 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:15.23 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-qkrsmlrsshnjsokl) |
| 14:15.23 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:25.23 | *** join/#asterisk-dev saghul (~saghul@ip3e830637.speed.planet.nl) |
| 14:28.11 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.226.79) |
| 14:28.11 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 14:31.12 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:31.12 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:43.03 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 14:56.00 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 15:42.17 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-yhujdnqgkbqlxkrt) |
| 15:46.50 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:46.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:03.04 | mjordan | file: your SIP shall be pimped |
| 16:03.16 | file | I'm sure I could make a song out of that |
| 16:04.45 | mjordan | might be *nearly* time for a sip channel driver project update |
| 16:05.20 | file | points at putnopvut |
| 16:06.03 | mjordan | poor, poor putnopvut |
| 16:08.04 | leifmadsen | heh |
| 16:17.26 | putnopvut | I ' |
| 16:18.18 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:03.59 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:03.59 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:04.42 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 18:19.31 | mjordan | last 'normal' release of Asterisk 10 should be going out today. Sorta feels like there should be ... something celebratory. |
| 18:20.09 | file | I have a cupcake in the kitchen, does that count? |
| 18:20.18 | Qwell | I do too! |
| 18:20.53 | mjordan | file: is it stale? |
| 18:20.58 | file | mjordan, no! |
| 18:21.04 | Qwell | mine is! |
| 18:21.54 | mjordan | Qwell: excellent. |
| 18:22.16 | mjordan | perhaps a trip to the Nook would be in order later this week. Monday feels a bit too early for celebrations. |
| 18:22.38 | Qwell | Everybody is also at home sick. |
| 18:22.43 | Qwell | stay away. SHUN. |
| 18:22.44 | file | my mind took Nook and turned it into Newk's |
| 18:22.46 | file | and now I want Newk's |
| 18:23.03 | file | mjordan, CURSE YOU |
| 18:24.06 | mjordan | mmm. |
| 18:29.51 | leifmadsen | I also have cupcakes |
| 18:30.41 | mjordan | leifmadsen: canadian cupcakes? |
| 18:31.24 | Qwell | mjordan: back cupcakes* |
| 18:31.30 | tzanger | leifmadsen is a canadian beefcake |
| 18:31.41 | leifmadsen | BEEF CAKE!!!!! |
| 18:31.57 | mjordan | leifmadsen: you're really starting to fill out nicely |
| 18:32.03 | leifmadsen | true story |
| 18:45.35 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 19:07.36 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 19:50.07 | jmls | hey guys |
| 19:50.32 | jmls | is there any ami command that exposes / uses vm_change_password() in app_voicemail.c ? |
| 19:51.21 | jmls | would be very useful for a web / gui interface so that an admin can reset the pin if the user forgot without having grant access to voicemail via the voicemailmain |
| 19:53.49 | mjordan | huh |
| 19:53.53 | mjordan | that would be useful |
| 19:54.12 | mjordan | jmls: not that I'm aware of, but it would be fairly trivial to write |
| 19:57.02 | jmls | static char *handle_voicemail_reload(struct ast_cli_entry *e, int cmd, struct ast_cli_args *a) |
| 19:57.11 | jmls | urgh. |
| 19:58.24 | jmls | I meant *handle_voicemail_changepw |
| 19:58.59 | jmls | voicemail change password mbox@context 1234 |
| 20:29.44 | tzafrir_laptop | is working on rpm packaging of dahdi for centos6. Initial version of rpm packages: http://git.tzafrir.org.il/?p=rpm/dahdi-tools.git;a=summary |
| 20:30.28 | tzafrir_laptop | Qwell, why did you separate kmod out to its ouwn package? |
| 20:32.30 | mjordan | wedhorn: ping |
| 20:32.37 | wedhorn | pong |
| 20:33.11 | leifmadsen | tzafrir_laptop: ya good luck with that :) |
| 20:33.15 | mjordan | wedhorn: going through some really old issues. Is there any reason why a small modification to the patch on ASTERISK-14964 wouldn't be acceptable? |
| 20:33.32 | leifmadsen | tzafrir_laptop: build via mock? |
| 20:33.37 | tzafrir_laptop | yes |
| 20:33.55 | leifmadsen | I had it working, but then I think I gave up and built against atrpms dahdi |
| 20:34.07 | mjordan | or rather: is anything in ASTERISK-14964 still needed? |
| 20:34.11 | tzafrir_laptop | I still have to figure out how to properly use mock |
| 20:34.14 | leifmadsen | the firmware is not built for centos/rhel 6 so I got blocked |
| 20:34.24 | leifmadsen | tzafrir_laptop: I can help if you wish, I've done it a bunch |
| 20:34.59 | tzafrir_laptop | I have a pending ITP to get mock running on Debian. But there are still some problems with it. |
| 20:35.11 | tzafrir_laptop | So I run mock in a centos6 chroot |
| 20:35.52 | mjordan | wedhorn: it doesn't appear as if it's needed, since rtp_engine doesn't assume that get_codec is implemented. But I figured I'd check before I started closing things out |
| 20:36.03 | wedhorn | mjordan: it's not needed. Basically I haven't worked through the codec side of things on skinny so it was just a reminder. |
| 20:36.22 | leifmadsen | so basically I use a command similar to: mock --quiet --root epel-6-i386 --buildsrpm --spec rpmbuild/SPECS/dahdi.spec --sources rpmbuild/SOURCES --resultdir rpmbuild/SRPMS |
| 20:36.30 | leifmadsen | that'll build the SRPMs using mock |
| 20:36.30 | mjordan | wedhorn: is it useful to you to keep it open? |
| 20:36.34 | wedhorn | mjordan: and if it is not implemented it grabs the same value from the chan as the suggested implementation in that but |
| 20:37.29 | leifmadsen | then resulting .src.rpm do something like: mock --quiet --root epel-6-i386 --arch i386 --rebuild --resultdir rpmbuild/RPMS/dahdi/i386 rpmbuild/SRPMS/dahdi-tools*.src.rpm |
| 20:37.40 | leifmadsen | but I never got dahdi-linux to build due to firmware issues |
| 20:37.56 | tzafrir_laptop | I ended up writing a wrapper script: http://paste.debian.net/224672/ |
| 20:37.57 | leifmadsen | broke down and just built using atrpms |
| 20:38.15 | tzafrir_laptop | You have to either download the firmware in advance, or disable downloading it. |
| 20:38.33 | tzafrir_laptop | (In advance: part of the package) |
| 20:38.38 | leifmadsen | I think the problem I was running into was something wasn't built for a kernel I was using |
| 20:38.55 | leifmadsen | that was relied upon upstream that I had no control of |
| 20:39.24 | leifmadsen | tzafrir_laptop: nice -- I have a script as well which looks like it does the same thing as yours |
| 20:39.31 | tzafrir_laptop | If you see the script: I cheat a bit with the kernel version number. Though I hope for the best with kmod |
| 20:39.50 | leifmadsen | I just build dahdi, then createrepo locally, modify my mock config file, and build against that for each asterisk version |
| 20:39.57 | leifmadsen | tzafrir_laptop: gotcha |
| 20:40.07 | wedhorn | mjordan: given that skinny wouldn't/can't change codecs on the fly, it's probably redundant, so as long as core doesn't and won't need a response, may as well close it |
| 20:40.39 | leifmadsen | tzafrir_laptop: the alternative is to use https://build.opensuse.org/ |
| 20:41.04 | jsmith | pretends he didn't see that |
| 20:41.06 | leifmadsen | it's been my intention to get that working locally |
| 20:41.11 | jsmith | ducks and hides |
| 20:41.12 | leifmadsen | jsmith: it's a nice interface |
| 20:41.21 | leifmadsen | I'd use a Fedora based one if it existed :) |
| 20:41.33 | jsmith | leifmadsen: Sure... I just wish... well... that things were different |
| 20:41.37 | leifmadsen | :) |
| 20:41.48 | jsmith | is obviously biased and too picky about RPMs |
| 20:42.05 | leifmadsen | I'd be happy to see official rpms built via mock at the least; I don't care what the base infrastructure is :) |
| 21:31.40 | *** join/#asterisk-dev jmls (~somefake@77.107.171.82) |
| 23:05.53 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 23:28.56 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-qkrsmlrsshnjsokl) |
| 23:31.12 | snuff-work | wedhorn: got 1 error msg.. |
| 23:35.48 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:35.49 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:35.58 | wedhorn | snuff-work: yeah |
| 23:36.09 | snuff-work | did u see my other msg? |
| 23:36.17 | snuff-work | <PROTECTED> |
| 23:36.18 | snuff-work | <PROTECTED> |
| 23:36.23 | wedhorn | did now |
| 23:36.34 | snuff-work | is what i tried to type when my pidgin went caput |
| 23:36.58 | wedhorn | -home died as well ... |
| 23:37.46 | snuff-work | mm.. probably more it died and it can't auto-rejoin cause its got an un-ident nick |
| 23:38.52 | snuff-work | mm.. maybe snuff-home is really offline.. could be power out.. |
| 23:40.46 | wedhorn | okay, so read only returns 1456 bytes when skinny expects it to read 1844 |
| 23:42.25 | snuff-work | mm |
| 23:44.49 | snuff-work | btw.. updated to use ur bitmask code.. |
| 23:46.17 | snuff-work | seems to work fine (i ditched ur +1) and moved the shifts back to start at 0.. |
| 23:52.09 | wedhorn | snuff-work: just an idea, maybe the packets are split so it can only grab part of the packet (1456 is in the ballpart of MTU etc) |
| 23:52.47 | wedhorn | I think the skinny packet would be 1460 bytes (1456 + 4 for identifier) |
| 23:52.56 | wedhorn | + ip overhead |
| 23:53.10 | wedhorn | does that align with some limit's on your network? |
| 23:53.11 | snuff-work | mm |
| 23:57.21 | wedhorn | 1460 + 40 for ip4 and tcp seems to align with a 1500 mtu |
| 23:58.45 | wedhorn | looks like we'll need to rewrite to handle split packets |
| 23:59.29 | wedhorn | maybe your box is just to quick and so occasionally manages to read the buffer before the second packet has been tacked on |