יום שישי, אפריל 29, 2016

יש בקהל משהוא שרוצה לשבור לאנשים את רשתות הסלולאר ?

    implementations derive the realm name from the IMSI by
    concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits
    of IMSI, and ".owlan.org".  For example, if the IMSI is
    123456789098765, and the MNC is three digits long, then the derived
    realm name is "mnc456.mcc123.owlan.org".  As there are no DNS servers
    running at owlan.org, these realm names can only be used with
    manually configured AAA routing
 
$whois owlan.org
NOT FOUND
>>> Last update of WHOIS database: 2016-04-29T13:44:05Z <<<
דרך 4186

אם אני מבין נכון, אם עדיין יש כאלה שמשתמשים בשיטת הזיהוי הזאת ומישהוא באמת יכול לרשום את הדומיין הזה הם יקבלו מזהיי SIM ויכול להיות שיפילו את שירות ההזדהות של מספר חברות סלולאר.

VoLTE בקוד חופשי

כשאני חושב על האפשרוית שיש היום לגולן לצאת מהבעיה אליה נכנסה החברה אני חושב על פריסת נתבים  (או שימוש בנתבים של חברה מסויימת) ושימוש בנתבים כנקודות גישה ל LTE באמצעות מה שמכונה כ Offloading.

מדוע זה יענה על הצורך משרד התקשורת ? מכיוון ש EGAN מגדיר את ה WiFI כתשתית הרדיו שלו לאספקת שירות (RAN). הדרישה של משרד התקשורת לכיסויי ולאחזקה של אנטנות תענה. ועל הדרך גולן יקבל פריסת דור 4 ואפילו תמיכה ב VoLTE (שאני לא חושב שיש מישהוא שמספק את זה בארץ).

VoLTE הוא דרך (שיטה?) להעביר את המידע שבדר"כ עבר דרך circuit switch תחת תקשורת IP. כלומר דברים כמו קול , SMS ו הודעות broadcast עוברים באפיק הנתונים. כאשר עוברים להשתמש באפיק נתונים מקצה אל קצה הדבר מאפשר לתמוך באיכות קול גבוהה יותר (במקום להשתמש ב 3.5 קילו הרץ אנו משתמשים ב 16), לספק יותר שירותים חכמים ולייצר רווח על שירותים בהשקעה נמוכה.

אחד הדברים היפים ב VoLTE הוא העובדה שהכל עובר דרך אפיק הנתונים, מה שמבטל את הצורך האחרון להחזיק אנטנות מהסוג הישן. מספיק להחזיק רק אפיק של נתונים בשביל לספק את כל היכולות עבור LTE.

לשם ההתחלה ספק הטלפוניה יצטרך להקים תמיכה ב VoLTE בצד השרת, להקים שרתי דיאמטר,שרתי DNS ,  SIP ו XCAP.

לקוחות הקצה יוכלו לרכוש מכשירי סלולאר שתומכים ב VoLTE וגיקים כמוני ינסו להשתמש בזה דרך הכלים הפתוחים שיש ברשותינו.

מה שנזדקק לו זה:

  1. משהוא שיודע לבצע EAP-AKA לקוח ההזדהות שאנו משתמשים לו wifi הידוע כ wpa_supplicant יודע לבצע את זה בלי שום בעייה.

    קובץ ההגדרות יכול את ההגדרה הבאה עבור הרשת GolanOverWifi אם היא תתמוך בהזדהות EAP-AKA:

    #this may be added into /etc/wpa_supplicant.conf
    network={
     ssid="GolanOverWifi"
     key_mgmt=WPA-EAP
     eap=AKA
     pin="1234"
     pcsc="" # define as empty to allow pcsc usage (you are allowed to add args inside)
    }
    

  2. רכיב תוכנה שיודע לבצע זיהוי על גבי UICC - שד ברירת המחדל pcscd יודע לעשות זאת מצויין.

    מה שיהיה צריך לעשות זה לקחת קורא כרטיסים שנתמך בלינוקס ולהשתמש ב pcscd לקרוא את הנתונים ממנו.

    לאחר שחיברנו את קורא הכרטיסים למחשב והפעלת pcsc_scan נוודא שהכרטיס זוהה (פלט לדוגמא) :

  3. PC/SC device scanner
    V 1.4.26 (c) 2001-2011, Ludovic Rousseau <ludovic.rousseau@free.fr>
    Compiled with PC/SC lite version: 1.8.15
    Scanning present readers...
    0: Gemalto PC Twin Reader (70D7E2EE) 00 00
    
    Fri Apl 29 11:47:42 2016
    Reader 0: Gemalto PC Twin Reader (70D7E2EE) 00 00
      Card state: Card inserted, 
      ATR: 3B 7E 13 00 00 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
    ATR: 3B 7E 13 00 00 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
    + TS = 3B --> Direct Convention
    + T0 = 7E, Y(1): 0111, K: 14 (historical bytes)
      TA(1) = 13 --> Fi=372, Di=4, 93 cycles/ETU
        43010 bits/s at 4 MHz, fMax for Fi = 5 MHz => 53763 bits/s
      TB(1) = 00 --> VPP is not electrically connected
      TC(1) = 00 --> Extra guard time: 0
    + Historical bytes: 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
      Category indicator byte: 00 (compact TLV data object)
        Tag: 6, len: A (pre-issuing data)
          Data: 11 63 54 05 48 05 02 C6 01
        Mandatory status indicator (3 last bytes)
          LCS (life card cycle): 22 (Proprietary)
          SW: 9000 (Normal processing.)
    
    Possibly identified card (using /home/user/.cache/smartcard_list.txt):
    3B 7E 13 00 00 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
    3B 7E 13 00 00 00 6A 11 63 54 05 48 .. .. .. 01 22 90 00
    




  4. לקוח SIP בעל הדרישות הבאות  :

    • לתמוך ב IPv4 ו IPv6
    • להחזיק לקוח XCAP  - לצערי linphone ו yate-qt אינם יודעים אבל jitsi יודע.
    • לקוח ה XCAP צריך לדעת לעבוד ללא chalange (לא יודע jitsi יודע או לא ) , לקוח ה SIP צריך לדעת להחליף את הזהות לזהות אותה קיבל לאחר ביצוע ה Register.

    • צריך לדעת לבצע register מחדש לאחר איבוד תקשורת (לא ראיתי את זה קורה ב yate-qt).
    • צריך לדעת לתמוך ב SIMPLE ו הודעות SM-IP  (למעשה מדובר על מקרה פרטי של 3428) )
    • צריך לדעת להוסיף את הכותרות  הבאות:

      phone-context  ו P-Aasserted-Identity ו P-Called-Party-ID. ולדעת להקים שיחה עם SIP-URI בצורה של MSISDN או של TEL.

      דוגמאות:

      sip:alphanumericusername@operator.tld

      sip:+33123456@free.fr;user=phone

      tel:+33123456;phone-context=free.fr

    • צריך לדעת להוסיף את ערך ה ICSI לשדה ה contact עם הכתובת הנגישה לרשת הסלולאר.דוגמא:

      Contact:sip:<+33123456@172.16.10.1:5060&gt
      ;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gppservice.ims.icsi.mmtel"
      


    • צריך לדעת לתמוך בשירותים הבאים (מינימום) :

      Originating Identification Presentation 3GPP TS 24.607 [23]
      Terminating Identification Presentation 3GPP TS 24.608 [24]
      Originating Identification Restriction 3GPP TS 24.607 [23] (Note 1)
      Terminating Identification Restriction 3GPP TS 24.608 [24] (Note 1)
      Communication Forwarding Unconditional 3GPP TS 24.604 [20] (Note 1)
      Communication Forwarding on not Logged in 3GPP TS 24.604 [20] (Note 1)
      Communication Forwarding on Busy 3GPP TS 24.604 [20] (Note 1)
      Communication Forwarding on not Reachable 3GPP TS 24.604 [20] (Note 1)
      Communication Forwarding on No Reply 3GPP TS 24.604 [20] (Note 1)
      Barring of All Incoming Calls 3GPP TS 24.611 [26] (Note 1)
      Barring of All Outgoing Calls 3GPP TS 24.611 [26] (Note 1)
      Barring of Outgoing International Calls 3GPP TS 24.611 [26] (Note 2)
      Barring of Outgoing International Calls – ex Home Country 3GPP TS 24.611 [26] (Note 2)
      Barring of Incoming Calls - When Roaming 3GPP TS 24.611 [26] (Note 1)
      Communication Hold 3GPP TS 24.610 [25]
      Message Waiting Indication 3GPP TS 24.606 [22] (Note 1)
      Communication Waiting 3GPP TS 24.615 [27] (Note 1)
      Ad-Hoc Multi Party Conference 3GPP TS 24.605 [21] (Note 1)
      

      למרות  שאני לא מכיר לקוחות SIP חופשיים שתומכים ב Bearing , אני לא חושב שזה יהיה נורא אם תהיה הצגה לא טובה של שם המשתמש המתקשר או אני אקבל הודעה שגויה אם לא הצלחתי להתקשר.

    • לקוח ה SIP צריך לדעת לתמוך בזימון אנשים להוסיף לשיחת וועידה (כבר קיים היום ) ב yate-qt לא יודע לגבי אחרים.

    • לקוח ה SIP רצוי שיידע לבצע פעולות כמו העברת שיחה ו History-Info.

    • לקוח ה SIP צריך לדעת לתמוך ב DTMF לפי נספח G
    • לקוח SIP שיודע לעבוד עם הקודקים AMR (כולל wideband).

אני לא מזכיר לקוח ANDSF מכיוון שאנחנו כבר מתחברים לרשת ידוע אז אין צורך לדרוש מהמשתמש שיעבור לרשת כיסויי אחרת.

ואם אני מבין נכון אז זה הכל, ככל אנדרויד עדכני תומך כמעט בהכול פה במידה ויהיה ביצוע offload כמו שצריך (עם כיסוי עירוני) אני מאמין שזה יענה על הצורך של גולן בכיסוי אנטנות (כי נתב מכיל אנטנות) ואם בזק תאפשר לנצל את משתמשיה שמפיצים גם ככה את הרשת Bezeq_Free יהיה כיסויי יחסית יפה.


שיטת ההזדהות לא שונה ממה שיש כיום והיא תראה בערך כך :



UE                   Bezeq Free Access Point     Bezeq Radius server              Translator        GT HSS
|<----WLAN registration--->|                            |                              |                 |
|                          |                            |                              |                 |
| --------EAP-AKA-------------------------------------->|                              |                 |
|                          |                            | ---Radius proxy the request->|                 |
|                          |                            |                              | ---Rad2Diam---->|
|                          |                            |                              |<--USIM register-|
|                          |                            |<--- USIM registration request|                 |
| <-------EAP-AKA---AUTH ACTIONs----------------------> |                              |                 |


אם זה נראה לכם כמו חור אבטחה לא קטן, זה בסדר גם ככה יש דרישה שהחברה (גולן) תעביר את המפתחות הפרטיים של הלקוחות שלהם (ככל הנראה שניתן יהיה להקים מרכז הזדהות עצמאי) כאן לפחות ינסו לסמוך על חברה ידועה ולא על גורם עלום שם שיקבל גישה לכלהמפתחות הפרטיים של הלקוחות.

הסיבה שצריך מתרגם , היא שככל הנראה פפקי תשתית הויפי מפעילים רדיוס אבל ב LTE אנו משתמשים בדיאמטר. ועל מנת להפוך הודעות מרדיוס ל דיאמטר צריך להשתמש ביישות שנקראת Diameter Translator.

יום חמישי, אפריל 28, 2016

המלצות פריסת שרתי Diameter לנדידה

GSMA ממליץ שכאשר בונים מערכת שתתמוד בנדידה יש להתקין סוכני דיאמטר (diameter agent) בכל קצה של Public Mobile Network (שמכונים כ DEA).

ישנם מספר סוגים של Diameter Agents שאשר להתקין אבל תחת הדומיין של נדידה מה שיעניין זה Relay ו Proxy.

כאשר Relay אינו בודק תוכן אלא מעביר אותו בהתאם ל Application Id  ו Destination -Realm/
ו Proxy מכיל פונקציונאל שמטפל ב AVP שאינם קשורים לניתוב, יכול לבצע טיפול בהודעות להפעיל policy  ולהוסיף עוד AVPים.

בהתאם לטבלת הניתוב (Realm routing table), סוכן הקצה (DEA) ישמש כפרוקסי במקרה מסויים בעוד במקרים אחרים יתפקד כRelay בלבד.

כל מופע של סוכן מחוג יכול להיות רק מסוג אחד (פרוקסי או relay), לכן קיימת המלצה שעבור לקוחות חיצונים לרשת יפורסם כ Relay בעוד בתוך הרשת יעבוד כפרוקסי. בצורה כזאת פעולות הניתוב הפנימיות לרשת אינן קשורות לאפליצקיות הפנימיות שרצות בתוך הרשת.

כמו כן קיימת המלצה להחזיק פרוקסי עובר כל אפליקציה.



דוגמאת תצורה  : 

 --- VPMN -----     -  --- HPMN -----
|  MME  --- DEA+|++++++|+DEA---HSS   |
| SSGN  --- DEA+|++++++|+DEA----|    |
|               |      |             |
| vPCRF --- DEA+|++++++|+DEA-- hPCRF |
---------------         -------------

ה HPMN ו VPMN הם רשת הבית והרשת המארחת , HSS הוא Home Subscriber Server ו PCRF זה Policy and Charging Rules Function.


זיהוי התחנה הבא (next hop)  יתבצע דרך RFC3588 שעבר שינוי:
עוברים על רשימת השרתים הקיימת בהתחלה.

שולחים בקשת NAPTR לRealm המתאים. (זה מבוצע ע"י בחירת השרת בעל הערך AAA+D2S , ואם אין רשומת NAPTR מנסים לאתר את _diameter._sctp.REALMNAME).

ממולץ להגדיר את ה TC ל 30 שניות

כמה מילים על צורת החיבור שלנו בLTE

אז איך בערך נראה החיבור שלנו כשאנו גולשים ברשת ה LTE ?

הציוד שלנו (UE) מתחבר לרשת ה Evolved UMTS Terrestrial Radio Access Network אל תוך ה Evolved Packet Core (EPC) ומשם לשירותים.

בתוך ה E-UTRAN זה נראה בערך כך:

 UE<--------> eNodeB <----S1 -----> EPC
 
 

במבט על ב eNodeB (השם המלאה הוא E-UTRAN-Nodb-B מסומל גם כ eNB) זה נראה בערך כך :
      S1....EPC...S1....
     .                  .
    .                    .
   .
eNodeB ------ x2 ------ eNodeB
   \                     /
    \                   /
     \                 / 
      x2             x2
       \             /
        \           /
         \  eNodeB /

המסלול בין ה eNodeB  מול ה EPC נקרא  S1 , והמסלול בין eNodeB אחד למשנהוא נקרא X2.


ה UE שלנו מזוהה מול ה EPC שבתורו מזהה את המשתמש דרך ה Home Subscriber Server (בדומה ל AuC), את השירות הוא יקבל מהeNodeB עליו חובר.

הEPC בתורו מורכב מרכיבים כמו ה Home Subscriber Server , Mobility Mangment Entity ,Packet Data Network Gateway (P-GW) ו Servicing Gateway

ה MME מתפקד כVLR בעוד P-GW  מחליף את הGGSN.

האחריות של ה eNodeB  היא :

הצפנת התעבורה
בחירת MME מתאים ל UE
ניתוב התעבורה ל Serving Gateway
העברת הודעות מה MME לUE
העברת Broadcast כלפי ה UE.
העברת הודעות חירום על ה UE.

האחריות של ה MME היא:

זיהוי ה UE כלפי ה HSS (איומות והרשאה) לעבודה בPLMN.
תקשור NAS.
המקום בו נבצע האזנה ללקוחות .
אחרי על מעקב ומשלוח חוזר של הודעות כלפי ה UE.
הפעלה וכיבוי של שירותים (Barrer Actviation/deactivtion)
ניהול ניידות (Mobility) עבור UE.
רגל ב handoffs.
יצרת מזהה אירעי GUTI (המקבילה ל T-IMSI)
ניתוב וקישור במקרה של נדידה.


כאשר אנו מתחברים לרשת יתבצע תהליך של זיהוי האם אנו שייכים לרשת או שצריך לבצע נדידה.
במקרה של נדידה ה MME של הרשת אליה התחברנו יתקשר ל HSS שלנו (הרשת אליה ה סים שלנו שייך) ה Servicing Gateway יוצא תקשורת ל P-GW ברשת שלנו (הקו בין ה Servicing Gateway של המארחים ל P-GW שלנו יקרא S8).

ה HSS יכול לדבר באמצעות פרוטקול דיאמטר (ב LTE עברו מ רדיוס לדיאמטר) אל מול שירות ה AAA של הרשת שלנו.

למידע נוסף ETSI TS 136 300 (הקישור הראשון בדף)

offloading

שמתי לב למשהוא יחסית מעניין, למרות שהביקוש לגלישה גדל ואף חלק מחברות נותנות חבילות של 2-4 ג"ב /לחודש כמעט ולא נתקלתי בספקים שנתנו תמיכה ב Offloading (פרט לצרפת אבל שם זה מקרה מיוחד).

בשונה מ3G/UMTS קלאסי, הקמה של רשתות אלחוט על  בסיס WLan זול בסדר גודל (פשוט תשוו מחיר של נתב  (כ 100 דולר) כעמדת שידור לעומת BSS (כ 4000-5000 אלף דולר להקמה) .

הרעיון של ה I-Wlan מציע העברת צרכני Data ל שימוש ברשתות האלחוט וחיבור בו זמני גם לאספקת שיחות / SMS וגם לגלישת נתונים. פרוטוקול נוסף ה EGAN (specs) מאפשר העברת כול פעולות הרשת ע"ג ה Wi-Fi ובכך לאפשר שימוש ברכיבים קיימים כספקי שירות.

ההבדלים העיקרים  (שאני חושב לציין ) בין EGAN ל I-Wlan הוא שב EGAN יש Tight coupling ורשת ה WiFi משמשת כ RAN, בעוד ב I-Wlan יש loose coupling ותקשורת הנתונים יכולה (אבל לא חייבת) לעבור דרך רשת ה WiFi אבל יש חיבור לשני ההתקנים בו זמנית.

נניח ואני חברת תשתית ואני רוצה לחסוך הקמת אנטנות, שימוש ב EGAN ו I-Wlan יאפשר לי להשתמש בפריסת הנתבים שלי אצל המשתמשים (אהם .. bezeqfree אהםם ... ) בשביל לספק תשתית לכל המשתמשים.  מכיוון שעמדות Wi-Fi אינו דורש התרי בנייה הדבר הופך לפתרון זמין לחברות. חשוב לציין שאם חברות שפרשו רשתות אלחוט היו דואגות לשים התקן נוסף בנתבים הם היו יכולות לקבל femocells בחינם אבל מכיוון שהם לא עשו זאת ולבקש מהלקוחות להחליף נתב זה לא אופציה אני לא מכסה את האפשרות הזאת פה.

מכיוון שכבר היום עולם ה LTE נכנס יפה לשוק ומצד שני משתמשי לינוקס ותוכנה חופשית גם נפוצים מאוד, קל לראות ששימוש במערכות מתוקננות תאפשר הוזלת עלויות לחברה באספקת התוכן.

מכיוון שספק התשתית רוצה להמליץ דרך איזו תשתית להשתמש (בשביל שהוא יוכל לייצר חיוב) המציאו שיטה הנקראת ANDSF.

נכון להיום איתור התמיכה בשיטות (Access network discovery and selection function) קיים כבר במספר מימושים (כולל תכונות קוד פתוח ). הרעיון ב ANDSF לצורתיו מתכונן ע"י ה TSים הבאים : 
TS-23402
TS-24302
TS-24312

מאוד בגודל ANDSF מאפשר לרכיב הלקוח (UE), לאתר יכולת רשת חיצוניות ולרשת לספק יכולות אלו.
צורת העבודה היא שה UE ניגש לספקANDSF ומדבר ב S14. וזה עונה לו עם מיקום (או אף מקשר ) של ספקי השירות אותם הוא צריך (לדוגמה ע"י SMS). אחת השיטות שה UE מגלה התקן ANDSF היא באמצעות בקשת DHCP (6153) מיוחדת.

לאחר איתור המזההים ההתקן מתחבר לספקי השרות לקבלת השירות.

אחת הצורות לעבודה ב I-WLAN נראת בערך כך :
 
UE                            Acess Point (WiFi)     Network Core (AAA) 
<----EAP-SIM (ipsec tunnel) -------><-----Operator tunnel------------->


אני הפשטתי את הדיאגרמה (והסרתי נושאים כמו GTP ו GRE ואימות בצד הרשת כי הם מחוץ לסקופ של הפוסט) .

ואם נראה לכם מוכר ואתם שאולים את עצמכם האם אני כמתמש לינוקס אוכל להתחבר לשירותי ספק הסלולאר שלי ? אז כן זה אפשרי (עקום אבל עובד) צריך להתקין את pscd ואת wpa_supplicant ולהגדיר את wpa_supplicant_eap_sim.conf ואם ספק הסלולאר שלכם פרס נקודות wifi במקום בו אין קליטה לרשת הסלולאר תהיה לכם גישה לשירותים המתקדמים של הרשת דרכו.

לדוגמה קובץ ההגדרות עבור Free Telecom נראה כך :
network={
    ssid="FreeWifi_secure"
    key_mgmt=WPA-EAP IEEE8021X
    eap=SIM
    priority=1
    pin="9999"
}

מרבית הכרטיסים יתמכו ע"י libccid ואחרים (יהיה צריך לכוון את קורה ה SIMים שלך להתקן ttyusb הנכון).

מפה עולה השאלה האם נוכל באמצעי תוכנה חופשית להשתמש בשני המסלולים בו זמנית  (WiFi ו LTE) ?
לצערי נכון להיות הפתרון הידוע בשם MAPCON רשום כפטנט ולכן ככל הנראה לא נוכל להשתמש בו.

כמה מילים על AuC

לאחרונה יש הודעה כי רשויות התקשורת דרשו את המפתחות הפרטיים הדרושים להצפנת תקשורת הרדיו המשומשים בהזדהות.

פוסט זה ינסה לתת מעט רקע לדרישה זו בהקשר של אימות משתמשים.

בעולם ה 3G יש לנו מספר ישיות מרכזיות ברשת האלחוט שמספקת תשתית.

מכרז האימות - Authtication Server (AuC)

ה AuC הוא מערכת ששומרת העתק של המפתח הפרטי של כל כרטיס חכם, המערכת מחזיקה מפתח מסטר K וSeed מידע (נקרא לו RAND) באמצעות שילוב של השנים נוצר מזהה איתו נבצע פעולות אימות ואישור ברשת התקשורת.

בGSM יש לנו שלשה של RAND  , תוצאה צפוייה (XRES) ומפתח הצפנה איתו נעבוד (CK)

צורת העבודה של שימוש במפתח סימטרי איפשרה לבצע אימות דו צדדי של הלקוח (הכרטיס החכם) ומערכת הזיהוו שאמורה להיות ברשת הביתית (HE). שני הצדדים גם שומרים על שני מזהיים SQNMS ו  SQNHE שנועדו לביצוע אימות הרשת ואימות תחנת הממסר (Mobile Station = MS).

יש הבדל באלגורתמי הזיהויי בין UMTS לבין 3G גם בגודל וגם באלגירתם עצמו,המפתחות הם בדרך כלל בגודל של 64 ביט (GSM) ו 128 ביט (UMTS).

ב UMTS זה יתנהג בערך כך -

הרשת המאחרת (היכן שנמצא ה MS) שולחת בקשה לווקטור (מערך) של אמצעי הזדהות ל AuC ברשת הביתית. כאשר כל תא בווקטור מכיל: מספר שרירותי, תוצאה צפוייה , מפתח הצפנה(CK) , בדיקת שלמות IK (אין קשר ל IK שלנו :) ) ו תוקן הזדהות (AUTN).

הרשת הביתית מייצרת ווקטור של N ומעבירה את המידע לרשת המארחת.
הרשת המאחרת בוחרת ווקטור הזדהות (i) שולחת בקשת הזדהות לציוד הקצה :
AUTN(i) || RAND(i)

ציוד הקצה מוודא את תוקן ההזדהות ושולח תשובה (RES) ומחשב CKו IK.
במידע והתוצאה של RES ו XRES זהות הרשת המארחת תאפשר שימוש במשאביה.

כאשר אין גישה לרשת הביתית אבל נבחרו רכיבי אימות, מפעילי המערכות  ברשתות המארחות יכולים לבטל את רכיב הזמן של המזהים (לכל כרטיס SIM יש בדרך כמות מקסימלית של אפשרויות שימוש בIK).

לקריאה נוספת TS 33.102 פרקים 6.3 ו 6.4

יום רביעי, אפריל 27, 2016

הצטרפתי אל הצד האפל.

גם אני הצטרפתי אל הצד האפל , ואני חייב להגיד לכם זה סיוט לא קטן.
לאחר שאולצתי לעבור שידרוג (לאחר דחייה אין קץ ) היום עשיתי את הצעד.

התהליך החל בערך בשעה 14:00 אז ניסיתי לבצע את השידרוג דרך windows update , שנכשל מספר פעמים לאחר שהוריד את הקובץ .

המשכתי לנסות להפעיל את תוכנת ה update עם דגל updatenow שגם הוא לאחר הורדת win10 נכשל שוב.

רק לאחר שהורדתי את MeidaCreateTool ויצרתי ISO, עיגנתי את ה ISO עם תוכנת WinCDEmu והפעלתי את מערכת העדכון הצלחתי להתקין.

מרגע הפעלת ה setup ועד reboot לlogin לקח שעה 25 (אני עם כונן SSD ובחרתי לשמור את כל האפליקציות על המערכת).

מאז ימי WinXp אני לא זוכר סרטוני קדימונים כאלה אבל יאללה קיבלנו.


git המשיך לעבוד.
אבל git-bash הוסר מתפריט התוכנות , ביצוע git svn rebase מכבה את המסך .
marble עובד.
pidgin  עובד

Nokia Pc Internet Access ממשיך לעבוד.

מסך ה VGA שלי הפסיק להיות מזוהה - כאשר ניגשתי להוספת מסכים ידנית הציעו לי להתקין דריברים לכרטיס מסך , אני יודע אני רגיל לעולם וורוד של לינוקס בו דריברים להתקנים בני שלוש שנים כבר נמצאים אבל אני צריך ללמוד להתרגל למערכות עקומות.

לא ניתן להגיע ל Administrative Tools בצורה פשוטה , צריך לחפש את הUtility שאתה צריך להשתמש בה. 

רכיב ה Ethernet  החליט שהוא לא מזוהה ולא עובד עם DHCP רק שWireshark מזהה traffic, לאחר חיבור כרטיס אלחוט והתחברות לאותה הרשת הוא התחיל לעבוד.

תוכנות ברירת המחדל שלי השתנו לדברים אחרים (במיוחד ה PDF שזה מעצבן אני משתמש בתוכנה חופשית מצויינת להציג את הPDFים שלי).

מרגע תחילת התקנה - ועד יכולת לעשות build  ב VS (שהיה מותקן לפני זה ) - 8 שעות.

אני חושב שהיה לי לוקח להתקין ולהגדיר מאפס ארצ' בפחות זמן.

EIR

שאלו אז אני עונה , בערך מתחילת העשור הנוכחי (2010) מספר אזורים החליטו כי הקמת EIR חיוניות לממניעת שימוש חוזר במכשירי סלולאר.


מאוד בגדול בדרך כלל EIR - Equipment Identity Register היה ישות בתוך רשת ה GSM שאפשרה בדיקה עם הציוד הקצה (UE) איתו אנו משתמשים מותר לו להתחבר לרשת שלנו (וזאת בשונה מהמזהה אותו אנו מקבלים דרך הכרטיס החכם שאומת על ידי הרשת). ככל ה EIR היה בדרך כלל מקומי לספק והכיל רשימה לבנה ורשימה שחורה של ציוד שיכל להתחבר לרשת (יש גם רשימה אפורה) .

העברת מידע על מכשירים חסומים בוצעה דרך בדיקה מול בסיסי נתונים כמו של GSMA ו imeichecker.

באופן לא ממש מפתיע הרבה חברות לא דיווחו ולא בדקו רכיבים מה שתרם להתפשטות תופעת ציוד גנוב שעובר שימוש שני בין מדינות. אני חושב שדווקא Orange דחפה שימוש ב EIR בתחילת שנות ה 2000 לסגירת מכשירים חסומים.

 הפתרון שתורקיה הגיע עליו פותר את הבעיה על ידי זה שהיא פשוט מנתקת כל מכשיר חדש שאינו רשום במדינה.

יום שני, אפריל 25, 2016

מישהוא שם לב לפיטצ'ר חמוד במפה ?

מה חסר במפה ?


שימוש בשירותי גוגל בפידג'ין



בפידג'ין מה שאני מכנה היונה (ואני יודע שזה לא בדיוק התרגום) ניתן להשתמש במספר דרכים בשירות ההודעות המיידיות.


על ידי שימוש בפלאגין של  XMPP ועל ידי שימוש בפלאגין חיצוני של Hangouts.


הייתרונות שימוש באפשרות ה XMPP :
תמיכה מובנית בשיחות קול ווידאו
הרגל
מובנה בתוך פיד'ין עצמו (לא דורש התקנה נוספת)
העברת קבצים מתבססת על הגדרות המערכת ולא על אפשרויות השרת.
 משתמש באותה הסיסמה כמו Gmail
חיסרון -  כאשר נשלחות הודעות המכילות תמונה מHanguots יתקבל קישור דרך Google+ לצפייה בתמונות.

Hangouts:

דורש סיסמא ייחודית דרך OAUTH2.
תמונות שנשלחות מוצגות בתוך התוכנה ללא צורך בשימוש ב Google+.

חסרונות:
אינו מכיל תמיכה בשיחות קול ווידאו.
אינו נמצא בתוך פידג'ין (דורש התקנה נוספת)
מזוהה כ IOS.

PCRF/PCEF/PCC

ב UMTS ו LTE יש לנו מספר מודלים לבצע חיוב, בחירת אופן החיוב והpolicy שלו מבוצע ע"י מה שמכונה Policy and Charing  Center (PCC).

ה PCC הוא יישות (אפשר להגיד מערכת שלמה) שיכולה לבצע החלטות ברשתות 3GPP (למשל UTMS ו LTE) וגם מערכות שהם לא בדיוק 3GPP (למשל כאשר יש שימוש ב I-WLAN).

ככל יש 5 מודלים של עבודה :
  1. חיוב לפי כמות שימוש.
  2. חיוב לפי זמן שימוש.
  3. חיוב לפי זמו וכמות שימוש.
  4. חיוב לפי אירוע.
  5. אי חיוב כלל
חיוב לפי כמות שימוש נמדד ביחידות (למשל KB ) וחיוב לפי זמן שימוש נמדד לפי זמן (לדוגמה גלשתי במשך שעה) .

מערכות ה PCC תבצע חיוב שונה כאשר קיימת נדידה, בהתאם למיקום (LAI , GeoFence) , בהתאם לסוג ה CSG (קבוצת מאפיינים ללקוח) של הלקוח ,  בהתאם לסוג השירות הנצרך בהתאם לזמן השימוש.

בצורה כזאת ניתן לחייב תושבי צפון תל אביב יותר מאשר למשל תושבי דרום תל אביב על אותו השירות, או להגיד שכל מי שיש לו איפון נשייך אותו לקבוצות חיוב גבוהה יותר (כי אני לא אוהב איפונים :) ).

כמו כן ניתן להגדיר כי כל מי שמתחבר לשירות הזרמת וידאו של Binge-On לא ישלם על השירות אבל אם יתחבר לצפות ב youtube הוא יחוייב בתשלום מלא.

המערכת יודעת לשלוח ל Policy and Charging Enforcement Function
 (PCEF) הודעות של כמה נשאר (זמן וכמות) לביצוע מעקב.

במידה ואנו עובדים במצב של חיוב בזמן אמת, ה PCEF יזהה מתי המשתמש חרג מהכמות המותרת וכאשר זה יקרה הוא ישלח הודעה ל Online Charging System (OCS) לזיהוי מחדש וקבלת משאבים (לדוגמה לשלם על עוד חבילת גלישה).

דרישות המינימום לאופן החיוב הן :

IP Connectivity Access Network  ברשת הביתית או המארחת.
מאפייני CSG של המשתמש.
QOS.
זמן ביממה.
מאפיני  IP Connectivity Access Network.



המארחת מחזיקה מערכת תעריפים והתעריפים יכולים להשתנות בהתאם לאירועי מערכת (למשל התחברות מחדש).

דוגמא קלאסית היא חיוב לשימוש בשירותי המייל של חברה מסויימת, ב uplink אנו מגדירים את שכל מה נשלח לפורט 80 ו 443 לחברה (בהתאם למשפחת כתובות מקור) וכל מה שמגיע מפורט 443 ו 80 ב downloing מהחברה.

השימוש ימדד על ידי ה Policy and Charging Rules Function (PCRF). שיקבל מידע פר משתמש ופר session זה נועד בשביל להפעיל החלטות בצורה דינאמית לפי אופן השימוש. ה PCRF שמבצע החלטות ישלח את הכמויות ה מותרות ל PCEF ו ה PCEF ישלח ל PCRF מתי משתמש מסויים הגיע לכמות שימוש מסויימת וידווח את כמות השימוש מאז הדיווח הקודם.

ה PCRF יבצע מעקב ברמת שירות , קבוצות שימושים ואף session בתוך IP-CAN.

למידע נוסף TS 23.203

יום שישי, אפריל 22, 2016

תקלות קידוד שפה בבסיס נתונים PostgreSql.

תקלות קידוד שפה בבסיס נתונים  PostgreSql .

על מנת להקל על הקורא דבר ראשון אם אתה רוצה להמנע מחיים קשים בהקשר של קידוד (ואתה לא על  SQL Server ) המנע מהתקנת השרת על וינדוס. אם אתה לא יכול לפחות המנע ממה שהוא לא SQL_ASCII והשתמש רק בשפה האנגלית.

אם אתה בוחר להתקין שרת בסיס נתונים על וינדוס או שאתה בוחר להשתמש בשפה שאינה אנגלית (אמריקאית) צפה לפגיעה.

הקורא הממוצע ישאל מה יש לכותב כנגד שפות שהן לא אנגלית אמריקאית ?

אתם מבינים בעולם התוכנה, יש מספר יצרנים לצערי מרמת מערכת ההפעלה ועד שמירת המידע בבסיס הנתונים הנחת הבסיס היא שיש שימוש באנגלית אמריקאית  (אפילו התקן של בסיס הנתונים מתייחס ל ANSI).

מדוע אני בתור איש וינדוס אומר להמנע משימוש בוינדוס כמערכת עבור בסיס נתונים במקרה הזה ?
התמיכה בקידודים ו locale שאינם en_us לדעתי לוקה בחסר, כברירת מחדל אין תמיכה ביוניקוד (צריך להריץ chcp 65001 בשביל להפעיל תמיכה למשל ביניקוד).

כאשר אנו מעבירים מידע  בין תוכנת לקוח לשרת  -  אנו  כפופים  לסוג הקידוד של מערכת הפעלה (מה שידוע כ code page) למאפייני השפה הנוכחים (locale) אופי קידוד המידע שיועבר ממערכת ההפעלה של הלקוח , אופי קידוד המידע בצד שרת ברמת הצד המקבל, אוקי קידוד המידע ברמת מערכת ההפעלה בצד המקבל , אוקי קידוד המידע בתוך בסיס הנתונים עצמו.

בעייה קלאסית כשמתקינים בסיס נתונים היא שימוש בשפה שאינה אנגלית ו Collate ברירת מחדל.

הבעיה היא שבדר"כ יש יותר מדרך אחת להציג מידע ובחירת השפה "עברית" בצד שרת ובחירת שפה "עברית" בצד לקוח לא באמת מחייב שהמידע יעבור תקין.

סיבה קלאסית היא הסתמכות על הקידוד מערכת ההפעלה ושימוש בקידוד ברירת מחדל, כשאנו למשל מדברים על עברית זה יכול להיות : UTF16* , ISO-8859-8, UTF8, CP1255,CP 862 ,ISO646.

ממה שאני ראיתי לרוב באפליקציות מהעשור האחרון דובר על CP122 ו iso8859-8 (לא נתקלתי במצב הגיוני של UTF16 או 8 כברירת מחדל עד היום).

בעולם הוינדוס בשביל לגלות במה משתמשים נשתמש בפקודה CHCP בשביל לגלות על איזה קידוד נמצא המשתמש בחיבור הנוכחי (session).

במידה ונבחרו ברירות מחדל נאלץ לגלות מהו קידוד השרת בsession הנוכחי  (המידע בתוך בסיס הנתונים ומערכת ההפעלה בבסיס הנתונים עצמו) ולנסות לכוון את האפליקציה להשתמש באותו הקידוד (להגדיר chcp זהה) .


אם יש לנו גישה לקוד המקור נוכל להגדיר את הקידוד ברמת ה session (במקרה של ODBC) -
לדוגמה עבור PG ניתן להגדיר את הקידוד בצורה הבאה :

"SET client_encoding= 'UTF8'"

ואז לשלוח את המידע כשהוא עבר קידוד ל UTF8 (כל מחרוזת שנשלח צריכה לעבור קידוד ישירות ל UTF8 לפני ההגעה לקו)

פתרון נוסף הוא בחירת הקידוד ברמת החיבור בהנחה שהדריבר שאנו עובדים איתו תומך בunicode :

std::string url = "odbc:postgresql://url:ip/databse&client_encoding=UTF8"

חשוב לציין שאם מחרוזת החיבור נובעת מ DSN אז אפשר לבצע את ההחלפה גם בתוך ה DSN עצמו.

במידה ומשתמשים ב DSN תחת FreeTDS שם הפרמטר הוא ClientCharset והקידוד הוא לפי iconv ובגרסה הקניינית שם הפרמטר הוא Charset.
אצל אורקל שם הארגומנט הוא DatabaseCharacterSet


במידה במידה ואנו עובדים עם קידוד פנימי של שני בתים (wchar_t/UCS2)  ולא יכולים לשנות את מחרוזת החיבור הוא להחליף את הדריבר הרגיל לדוגמה psqlodbc.so ל psqlodbcw.so) ולהתבסס על המרת ברירת מחדל (בגרסאות ישנות של posgresql הפתרון היה פשוט להשתמש ב UCS2 ל UCS2 אם גם השרת וגם הלקוח הם עובדים על וינדוס).

לפעמים נתפתה פשוט תמיד להשתמש ב UTF8 תמיד ולצפות לטוב, הבעיה (אהם פרל אהם פרל) שלא כל השפות והדריברים תומכים בהמרה בין יוניקוד לשפה הנדרשת (EUC_JP לדוגמה) ואז נצטרך לבצע את ההמרה או באפליקציה שלנו או ברמת הדריבר או לבקש מבסיס הנתונים שלנו לבצע המרה.

המרה  ברמת הפעולה בבסיס הנתונים תראה בערך כך :

convert ( text , 'sourceencoding' , 'destencoding')

הממרה ברמת השפה איתה אנו משתמשים תראה בערך כך :

Perl:
$internalEncoding = decode( 'iso-8859-8', $var );
$result = encode( 'utf-8', $internalEncoding );
Java:
Charset utf8 = Charset.forName("UTF-8");
Charset iso8859_8 = Charset.forName("ISO-8859-8");
CharBuffer data = iso8859_8.decode(inputBuffer);
ByteBuffer output = utf8.encode(data);


iconv - C:

iconv_t cnv = iconv_open("UTF-8", "ISO_8859-8"); if (-1 == cnv) { return ; }
int ret = iconv(cnv, &text_in_8859_8, &length_of_text_in_8859_8, &text_in_utf8, &length_of_text_in_utf8);


עבודה עם PG דרך ODBC

כשעובדים עם בסיס נתונים אפשר לעבוד קשה ולהשתמש בפקודות הספציפיות לבסיס הנתונים (כמו למשל PGConnect). ואפשר לעבוד בשיטה הסטראדנרטית שימוש ב ODBC.

בשביל לגשת ולהשתמש ב PG תחת ODBC קודם כל נגדיר DSN עבורו בדביאן קודם נתקין את הדריבר (מתוך  odbc-postgresql)

 זה יראה כך במקרה של UNICODE:

[otherdb]
Description         = PostgreSQL connection to otherdb
Driver              = PostgreSQL Unicode
Database            = otherdb
Servername          = 192.168.1.35
UserName            = 
Password            = 
ReadOnly            = No
RowVersioning       = No
ShowSystemTables    = No
Trace               = No 
#uncomment for traces
#TraceFile           = /tmp/psqlodbc.log 

לאחר מכן בקוד שלנו נוכל להתחבר באמצעות התחביר הבא :

"DSN=otherdb;DATABASE=otherdb;UID=%s;PWD=%s"  
את ה %s כמובן מחליפים לפי הנתונים הנכונים.

חשוב לזכור שאת המידע עצמו אנו צריכים לקודד ל unicode בעצמינו, בחלק מהספריות זה כבר יתבצע עבורנו (למשל תחת java) אבל במקרים אחרים נדרש לקידוד עצמאי.

ביצוע שאילתה מ PG ב C

איך לקבל נתונים מ PG באמצעות שימוש ב libpq:
#include <stdio.h>
#include <string.h>
#include <postgresql/libpq-fe.h>

void usage();

int main(int argc , char * argv[])
{
  PGconn          *db_connection;
  PGresult        *connection_result;
  const  char *    connection_info;
  PGresult        *request_result;
  int              number_of_records;
  int              number_of_fields;
  int              column_index;//column index in record 
  int              record_index;//record index under process

  db_connection  = NULL;
  connection_result = NULL;
  request_result = NULL;

  if (argc != 2) 
  {
    usage (argv[0]);
    return 1;
  }
  connection_info = argv[1];
  db_connection = PQconnectdb(connection_info);
  if (NULL == db_connection)
  {
    printf("%s:%d Failed connection to %s\n",
            __FUNCTION__,__LINE__, connection_info);
    return 1;
  }

  if (CONNECTION_BAD == PQstatus(db_connection) )
  {
     printf("%s:%d bad connection to %s=>%s\n",
             __FUNCTION__,__LINE__, 
             connection_info,
             PQerrorMessage(db_connection));

     goto error;
  }
  //execute over a db connection, the executation may fail or success
  request_result =  PQexec(
                           db_connection,
                           "SELECT field1 FROM mytable where field2=value");
  if (NULL == request_result)
  {
    printf("%s:%d Failed to execute command with error: %s\n",
           __FUNCTION__,__LINE__, PQerrorMessage(db_connection));
    goto error;
  }
  //checing here for PGRES_TUPLES_OK and not PGRES_COMMAND_OK because the request need to return data
  if (PQresultStatus(request_result) != PGRES_TUPLES_OK)
  {
     printf("%s:%d Failed to execute command with error : %s\n",__FUNCTION__,__LINE__, PQerrorMessage(db_connection));
     goto error;
  }
  number_of_records  = PQntuples(request_result);
  number_of_fields   = PQnfields(request_result);

  if (0 >   number_of_fields)
  {
     printf("%s:%d Invalid number of fields in result set (%d) : %s\n",__FUNCTION__,__LINE__, 
     number_of_fields,
     PQerrorMessage(db_connection));

     goto error;
  }
 
  printf("Result set have %d records and %d fields each\n,number_of_records,number_of_fields);
 
  for (record_index = 0 ; record_index < number_of_records;record_index++)
  {
    printf("record %d/%d:\n",record_index,number_of_records);
    for (column_index = 0 ; column_index < number_of_fields;column_index++)
    {
      printf("%d/%d field value <%s>\n",PQgetvalue(request_result, record_index, column_index));
    }
    printf("\n");
  }
  PQfinish (db_connection);
  return 0;

error:
  if (NULL != request_result)
  {
    PQclear(request_result);
  }
  if (NULL != connection_result)
  {
    PQclear(connection_result);
  }
  if (NULL!= db_connection) 
  {
    PQfinish (db_connection);
  }
  return 1;

}

void usage(const char * program_name)
{
  printf("USAGE: %s connection_string\n"
         "connection_string := keyValue|URI\n",
         "URI example:\n"
         "postgresql://other@localhost/otherdb?connect_timeout=10&application_name=myapp&client_encoding=UTF8\n",
         program_name);
}