search

stich86 / lpac-libmbim-wrapper

This is a wrapper for LPAC client to used libmbim to manage euICC on Linux client
MIT License
7 stars 2 forks source link

Fix issues #4 and #5. Also add another common MBIM port value for DEV (as a comment). #6

Closed AndySchroder closed 3 months ago

AndySchroder commented 4 months ago

Fix issues #4 and #5. Also add another common MBIM port value for DEV (as a comment).

AndySchroder commented 4 months ago

The reason I did it this way was because if using the vi editor, you can quickly switch between the two options by doing dd to delete the line of the active variable value and x to uncomment inactive variable value. Or, you can just leave the first line there because uncommenting the second variable value just overwrites the first when running.

AndySchroder commented 4 months ago

At https://github.com/stich86/lpac-libmbim-wrapper/blob/7c282a675472d973a7d06a961b9dcdd69fe3f634/wrapper.py#L17 it indicates the channel_id is never provided again. The param you get seems to be something different. I think that variable name is used in about 3 different ways in the script, I think that is why the bug was created.

stich86 commented 4 months ago

At

https://github.com/stich86/lpac-libmbim-wrapper/blob/7c282a675472d973a7d06a961b9dcdd69fe3f634/wrapper.py#L17

it indicates the channel_id is never provided again. The param you get seems to be something different. I think that variable name is used in about 3 different ways in the script, I think that is why the bug was created.

i'll try in the next days to check and i let you know ;)

AndySchroder commented 4 months ago

Also added 78346b47400801938a8dc8c79f525ecff2178400 , "moved device definition to the command line, created setup.cfg, and updated install instructions". I think this should make the script a lot easier to use.

bam80 commented 4 months ago

@AndySchroder I see you got involved into this project, would you like to try to solve #7?

AndySchroder commented 4 months ago

@AndySchroder I see you got involved into this project, would you like to try to solve #7?

I'm happy to test it, but I don't have the capability to do more than that. The changes I propose in this PR make a clean and workable enough solution for me right now. #7 will be great to further simplify of course, so I'll be glad when this wrapper becomes obsolete, but the wrapper does work well.

bam80 commented 4 months ago

Any update on this PR?

stich86 commented 4 months ago

I should receive next week some LTE modules, so I can test the PR on it

AndySchroder commented 4 months ago

I have no more changes planned. Would appreciate it being merged. If no merge, I'll continue my fork and change the reference download path for the pip command to point to my fork.

AndySchroder commented 4 months ago

What model module will you be testing with?

stich86 commented 4 months ago

I have no more changes planned. Would appreciate it being merged. If no merge, I'll continue my fork and change the reference download path for the pip command to point to my fork.

This is a free time project, and as I've said want to test it with these new modules (Quectel EP-06, a 4G Sierra Wireless and a Huawei module)

If you're in a hurry, go ahead with your fork, nothing prevents you from doing so :)

stich86 commented 3 months ago

merged, should receive next week some modules So I'll update the table ;)

AndySchroder commented 3 months ago

so you were able to test with an existing module you already have, or you didn't test at all yet?

stich86 commented 3 months ago

so you were able to test with an existing module you already have, or you didn't test at all yet?

not yet.. my friend had a problem.. hope he will send me modules by end of this week :(