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

an error occurred while windows was synchronizing with time.windows.com

ניסיתי גם סרברים אחרים ויש אותה הודעה (בשני מחשבים שמריצים ויסטה ו 7 )

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

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

תוכנה אחרת (NETTIME) עבדה ללא בעייה.

הנתב הוא TP LINK 841

רעיונות איך לפתור את הבעייה?

תודה

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

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

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

אם W32TIME (הוא עבד בצורה דיי דומה לNTP) לא עובד, אתה צריך לבצע troubleshooting בדיוק כמו לכל שירות מבוסס רשת.

http://www.meinbergglobal.com/english/info/ntp-w32time.htm

עברת על השלבים האלו?

גם אצלי קיימת בעיה דומה, עם TP-Link WR1043ND v2. הבעיה התחילה על כל המחשבים ברשת הפנימית ועל כל השרתים, ברגע שהחלפתי לראוטר הזה.

אצלי הפניית פורטים לא עוזרת, וככלל אני מסכים עם multicore שלא אמור להיות שום קשר להפניית פורטים, מכיוון שהמחשב הפנימי הוא זה שיוזם את ה-session.

כשאני מנסה לבצע סנכרון ברשת אחרת עם ראוטר אחר (למשל עם הסמארטפון כ-WiFi hotspot), הסנכרון מצליח.

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

בדגם שלך, כנראה שהפניית הפורט מתפקדת כ-workaround לבאג הזה.

טוב, אז מסתבר שהאשמתי את הראוטר(ים) מוקדם מדי.

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

ווינדוס מוציא את פקטות ה-NTP עם dst port של 123 כנדרש, אבל מאיזשהי סיבה לא ברורה גם עם src port של 123 קבוע (במקום לשנות אותו בכל session כמו בכל אפליקציה אחרת).

לכן, כל ראוטר עם מנגנון NAT/NAPT שמנסה לעשות Port preservation (אני מניח שרובם) עלול להיתקל בבעיות במקרים כאלה, כתלות באופן המימוש (שאינו מחוייב לפי RFC 4787). בפרט, אם בחרו להשתמש בשיטת ה-Port overloading, התוצאה תהיה כישלון ביצירת התקשורת, כמו שמצויין ב-RFC וחווינו באמת בעצמנו.

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

טוב, אז מסתבר שהאשמתי את הראוטר(ים) מוקדם מדי.

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

ווינדוס מוציא את פקטות ה-NTP עם dst port של 123 כנדרש, אבל מאיזשהי סיבה לא ברורה גם עם src port של 123 קבוע (במקום לשנות אותו בכל session כמו בכל אפליקציה אחרת).

לכן, כל ראוטר עם מנגנון NAT/NAPT שמנסה לעשות Port preservation (אני מניח שרובם) עלול להיתקל בבעיות במקרים כאלה, כתלות באופן המימוש (שאינו מחוייב לפי RFC 4787). בפרט, אם בחרו להשתמש בשיטת ה-Port overloading, התוצאה תהיה כישלון ביצירת התקשורת, כמו שמצויין ב-RFC וחווינו באמת בעצמנו.

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

שימוש של NTP ב source port של 123 הוא חוקי לפי ה-RFC (נקרא symmetric mode):

http://tools.ietf.org/html/rfc958#appendix-A

Batnun

.

לא הכרתי את ה-symmetric mode.

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

בתוך שדה ה-flags בפקטות שווינדוס מוציא רואים שנקבע mode=3, שמייצג באופן ברור לפי ה-RFC מצב client ולא symmetric.

לכן שימוש ב-src port 123 הוא חד-משמעית באג.