From scd@daukas.com Wed Nov 28 13:28:46 2007 From: Stephen Daukas To: wlug@lists.wlug.org Subject: [Wlug] Any XMl-types out there? Date: Wed, 28 Nov 2007 13:28:33 -0500 Message-ID: <19badd460711281028l4742e015r7f11ca2aaa4b5a9c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8347177999996132940==" --===============8347177999996132940== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello Everyone! So, I have to teach myself myself XML, XSL, et al., for work... (The VB stuff is in the background for now!) I started playing with XML yesterday, and have gotten pretty far along. But... I have to deal with M$-generated XML files that looks like the following (I added the first two lines for display in a browser): [snip] [~11,000 lines snipped] So, I wrote the following SOURCES.xsl file to display this beast in a browser (it uses recursion):

():

- -

And it works (surprised the hell out of me)! But now I'm having the hardest time figuring out how to format this the way I'd like. This is how it currently looks in the browser: MA11002 (2002): 537 - 226 - 180 MA11002 (2002): 537 - 448 - 140 MA11002 (2002): 538 - 226 - 180 MA11002 (2002): 538 - 413 - 140 MA11002 (2002): 538 - 413 - 177 MA11002 (2002): 539 - 226 - 180 MA11002 (2002): 539 - 413 - 140 MA11002 (2002): 541 - 226 - 180 MA11002 (2002): 541 - 478 - 140 MA11002 (2002): 541 - 413 - 140 MA11018 (2002): 538 - 413 - 140 MA11018 (2002): 539 - 413 - 140 MA11018 (2002): 541 - 413 - 140 MA11019 (2002): 537 - 312 - 140 MA11019 (2002): 538 - 312 - 140 MA11019 (2002): 539 - 312 - 140 MA11019 (2002): 541 - 312 - 140 [... other IDs in between 2002 and 2008 ...] MA11002 (2008): 537 - 226 - 180 MA11002 (2008): 537 - 478 - 92 MA11002 (2008): 537 - 312 - 156 [... thousands of additional IDs ...] And I'd like the output to look something like: MA11002 (2002): 537 - 226 - 180 - 448 - 140 538 - 226 - 180 - 413 - 140 - 177 539 - 226 - 180 - 413 - 140 MA11002 (2008): 537 - 226 - 180 - 478 - 92 - 312 - 156 [...] So, things would need to be grouped by ID305B and CYCLE, then by USE_ID, then by CAUSE_ID, then by SOURCE_ID. But, I'd even settle for output that looks like: MA11002 (2002): 537 - 226 - 180 MA11002 (2002): 537 - 448 - 140 MA11002 (2002): 538 - 226 - 180 MA11002 (2002): 538 - 413 - 140 MA11002 (2002): 538 - 413 - 177 MA11002 (2002): 539 - 226 - 180 MA11002 (2002): 539 - 413 - 140 MA11002 (2002): 541 - 226 - 180 MA11002 (2002): 541 - 478 - 140 MA11002 (2002): 541 - 413 - 140 MA11002 (2008): 537 - 226 - 180 MA11002 (2008): 537 - 478 - 92 MA11002 (2008): 537 - 312 - 156 [... thousands of additional IDs ...] where the IDs from the two different years are adjacent to one another... I believe this will involve much pain and suffering while I try to figure out such things as XML nodes, grouping, sorting, and the like... But, I'm hoping someone will look at this and say "boy Daukas, that's easy... just do this, and then that, and voila - your done!". Anyone? Anyone? ;-) Thanks in advance for any help! Steve --===============8347177999996132940== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PGRpdj5IZWxsbyBFdmVyeW9uZSE8YnI+PGJyPlNvLCBJIGhhdmUgdG8gdGVhY2ggbXlzZWxmIG15 c2VsZiBYTUwsIFhTTCwgZXQgYWwuLCBmb3Igd29yay4uLiZuYnNwOyAoVGhlIFZCIHN0dWZmIGlz IGluIHRoZSBiYWNrZ3JvdW5kIGZvciBub3chKSZuYnNwOyZuYnNwO0kgc3RhcnRlZCBwbGF5aW5n IHdpdGggWE1MIHllc3RlcmRheSwgYW5kIGhhdmUgZ290dGVuIHByZXR0eSBmYXIgYWxvbmcuJm5i c3A7IEJ1dC4uLiBJIGhhdmUgdG8gZGVhbCB3aXRoIE0kLWdlbmVyYXRlZCBYTUwgZmlsZXMgdGhh dCBsb29rcyBsaWtlIHRoZSBmb2xsb3dpbmcgKEkgYWRkZWQgdGhlIGZpcnN0IHR3byBsaW5lcyBm b3IgZGlzcGxheSBpbiBhIGJyb3dzZXIpOgo8L2Rpdj4KPGJsb2NrcXVvdGUgZGlyPSJsdHIiIHN0 eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+CjxkaXY+Jmx0Oz94bWwgdmVyc2lvbj0mcXVvdDsxLjAm cXVvdDs/Jmd0Ozxicj4mbHQ7P3htbC1zdHlsZXNoZWV0IHR5cGU9JnF1b3Q7dGV4dC94c2wmcXVv dDsgaHJlZj0mcXVvdDtTT1VSQ0VTLnhzbCZxdW90Oz8mZ3Q7PGJyPjxicj4mbHQ7eG1sIHhtbG5z OnM9JiMzOTt1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4MiYjMzk7PGJy PiZuYnNwO3htbG5zOmR0PSYjMzk7dXVpZDpDMkY0MTAxMC02NUIzLTExZDEtQTI5Ri0wMEFBMDBD MTQ4ODImIzM5Owo8YnI+Jm5ic3A7eG1sbnM6cnM9JiMzOTt1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOnJvd3NldCYjMzk7PGJyPiZuYnNwO3htbG5zOno9JiMzOTsjUm93c2V0U2NoZW1hJiMzOTsm Z3Q7PGJyPiZsdDtzOlNjaGVtYSBpZD0mIzM5O1Jvd3NldFNjaGVtYSYjMzk7Jmd0Ozxicj4mbmJz cDsmbHQ7czpFbGVtZW50VHlwZSBuYW1lPSYjMzk7cm93JiMzOTsgY29udGVudD0mIzM5O2VsdE9u bHkmIzM5OyZndDs8YnI+Jm5ic3A7Jm5ic3A7Jmx0O3M6QXR0cmlidXRlVHlwZSBuYW1lPSYjMzk7 SUQzMDVCJiMzOTsgcnM6bnVtYmVyPSYjMzk7MSYjMzk7IHJzOm51bGxhYmxlPSYjMzk7dHJ1ZSYj Mzk7IHJzOm1heWRlZmVyPSYjMzk7dHJ1ZSYjMzk7IHJzOndyaXRldW5rbm93bj0mIzM5O3RydWUm IzM5OyZndDsKPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZsdDtzOmRhdGF0eXBlIGR0OnR5cGU9JiMz OTtzdHJpbmcmIzM5OyBkdDptYXhMZW5ndGg9JiMzOTs1MCYjMzk7LyZndDs8YnI+Jm5ic3A7Jm5i c3A7Jmx0Oy9zOkF0dHJpYnV0ZVR5cGUmZ3Q7PGJyPjxicj4mbmJzcDtbc25pcF08YnI+PGJyPiZu YnNwOyZuYnNwOyZsdDtzOmV4dGVuZHMgdHlwZT0mIzM5O3JzOnJvd2Jhc2UmIzM5Oy8mZ3Q7PGJy PiZuYnNwOyZsdDsvczpFbGVtZW50VHlwZSZndDs8YnI+Jmx0Oy9zOlNjaGVtYSZndDsKPGJyPiZs dDtyczpkYXRhJmd0Ozxicj4mbmJzcDsmbHQ7ejpyb3cgSUQzMDVCPSYjMzk7TUExMTAwMiYjMzk7 IENZQ0xFPSYjMzk7MjAwMiYjMzk7IFVTRV9JRD0mIzM5OzUzNyYjMzk7IENBVVNFX0lEPSYjMzk7 MjI2JiMzOTsgU09VUkNFX0lEPSYjMzk7MTgwJiMzOTsgQ09ORklSTUVEPSYjMzk7TiYjMzk7LyZn dDs8YnI+PGJyPiZuYnNwOyBbfjExLDAwMCBsaW5lcyBzbmlwcGVkXTwvZGl2PjwvYmxvY2txdW90 ZT4KCjxkaXY+U28sJm5ic3A7SSB3cm90ZSB0aGUgZm9sbG93aW5nIFNPVVJDRVMueHNsIGZpbGUg dG8gZGlzcGxheSB0aGlzIGJlYXN0Jm5ic3A7aW4gYSBicm93c2VyIChpdCB1c2VzIHJlY3Vyc2lv bik6PC9kaXY+CjxibG9ja3F1b3RlIGRpcj0ibHRyIiBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgi Pgo8ZGl2PiZsdDs/eG1sIHZlcnNpb249JiMzOTsxLjAmIzM5Oz8mZ3Q7PGJyPiZsdDt4c2w6c3R5 bGVzaGVldCB4bWxuczp4c2w9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS9Y U0wvVHJhbnNmb3JtIj5odHRwOi8vd3d3LnczLm9yZy8xOTk5L1hTTC9UcmFuc2Zvcm08L2E+JnF1 b3Q7IDxicj4mbmJzcDsmbmJzcDt4bWxuczpycz0mIzM5O3VybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206cm93c2V0JiMzOTsKPGJyPiZuYnNwOyZuYnNwO3htbG5zOno9JiMzOTsjUm93c2V0U2NoZW1h JiMzOTsmbmJzcDt2ZXJzaW9uPSZxdW90OzEuMCZxdW90OyZndDs8YnI+PGJyPiZsdDt4c2w6dGVt cGxhdGUgbWF0Y2g9JnF1b3Q7LyZxdW90OyZndDs8YnI+Jm5ic3A7Jm5ic3A7ICZsdDtIVE1MJmd0 Ozxicj4mbmJzcDsmbmJzcDsgJmx0O0JPRFkgdG9wbWFyZ2luPSZxdW90OzAmcXVvdDsgbGVmdG1h cmdpbj0mcXVvdDswJnF1b3Q7Jmd0Ozxicj4mbmJzcDsmbmJzcDsgJmx0O3hzbDphcHBseS10ZW1w bGF0ZXMgc2VsZWN0PSZxdW90Oy94bWwvcnM6ZGF0YSZxdW90Oy8mZ3Q7Cjxicj4mbmJzcDsmbmJz cDsgJmx0Oy9CT0RZJmd0Ozxicj4mbmJzcDsmbmJzcDsgJmx0Oy9IVE1MJmd0OzwvZGl2Pgo8ZGl2 PiZsdDsveHNsOnRlbXBsYXRlJmd0Ozxicj4mbmJzcDs8L2Rpdj4KPGRpdj4mbHQ7eHNsOmtleSBu YW1lPSZxdW90O3Jvd3MtYnktQVUmcXVvdDsgbWF0Y2g9JnF1b3Q7ejpyb3cmcXVvdDsgdXNlPSZx dW90O0BJRDMwNUImcXVvdDsgLyZndDs8YnI+Jmx0O3hzbDp0ZW1wbGF0ZSBtYXRjaD0mcXVvdDt6 OnJvdyZxdW90OyZndDs8YnI+Jmx0O3hzbDphcHBseS10ZW1wbGF0ZXMgc2VsZWN0PSZxdW90O2tl eSgmIzM5O3Jvd3MtYnktQVUmIzM5OywgSUQzMDVCKSZxdW90OyAvJmd0Owo8YnI+Jm5ic3A7Jm5i c3A7ICZsdDtkaXYgQVVfSUQ9JnF1b3Q7e0lEMzA1Qn0mcXVvdDsmZ3Q7PGJyPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7eHNsOmFwcGx5LXRlbXBsYXRlcyBzZWxlY3Q9JnF1b3Q7 a2V5KCYjMzk7cm93cy1ieS1BVSYjMzk7LCBJRDMwNUIpJnF1b3Q7IC8mZ3Q7PGJyPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZGl2IFVTRV9JRD0mcXVvdDt7Q1lDTEV9JnF1b3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtkaXYgVVNFX0lEPSZxdW90O3tVU0VfSUR9JnF1 b3Q7Jmd0Owo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt4c2w6dmFsdWUtb2Ygc2VsZWN0PSZxdW90O0BJRDMw NUImcXVvdDsvJmd0Ozxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKCZsdDt4c2w6dmFsdWUtb2Ygc2VsZWN0PSZxdW90 O0BDWUNMRSZxdW90Oy8mZ3Q7KTogPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7eHNsOmFwcGx5LXRlbXBsYXRl cyBzZWxlY3Q9JnF1b3Q7a2V5KCYjMzk7cm93cy1ieS1BVSYjMzk7LCBVU0VfSUQpJnF1b3Q7LyZn dDsKPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7eHNsOnZhbHVlLW9mIHNlbGVjdD0mcXVvdDtAVVNFX0lEJnF1 b3Q7LyZndDsgLSA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt4c2w6dmFsdWUtb2Ygc2VsZWN0PSZxdW90O0BD QVVTRV9JRCZxdW90Oy8mZ3Q7IC08YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt4c2w6dmFsdWUtb2Ygc2VsZWN0 PSZxdW90O0BTT1VSQ0VfSUQmcXVvdDsvJmd0Ozxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9kaXYmZ3Q7Cjxicj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0Oy9kaXYmZ3Q7PGJyPiZuYnNwOyZuYnNwOyAmbHQ7L2RpdiZndDs8 YnI+Jmx0Oy94c2w6dGVtcGxhdGUmZ3Q7PGJyPiZsdDsveHNsOnN0eWxlc2hlZXQmZ3Q7IDwvZGl2 PjwvYmxvY2txdW90ZT4KPGRpdj5BbmQgaXQgd29ya3MgKHN1cnByaXNlZCB0aGUgaGVsbCBvdXQg b2YgbWUpISZuYnNwOyBCdXQgbm93IEkmIzM5O20gaGF2aW5nIHRoZSBoYXJkZXN0IHRpbWUgZmln dXJpbmcgb3V0IGhvdyB0byBmb3JtYXQgdGhpcyB0aGUgd2F5IEkmIzM5O2QgbGlrZS4mbmJzcDsg VGhpcyBpcyBob3cgaXQgY3VycmVudGx5IGxvb2tzIGluIHRoZSBicm93c2VyOjwvZGl2Pgo8Ymxv Y2txdW90ZSBkaXI9Imx0ciIgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4KPGRpdj5NQTExMDAy ICgyMDAyKTogNTM3IC0gMjI2IC0gMTgwPGJyPk1BMTEwMDIgKDIwMDIpOiA1MzcgLSA0NDggLSAx NDA8YnI+TUExMTAwMiAoMjAwMik6IDUzOCAtIDIyNiAtIDE4MDxicj5NQTExMDAyICgyMDAyKTog NTM4IC0gNDEzIC0gMTQwPC9kaXY+CjxkaXY+TUExMTAwMiAoMjAwMik6IDUzOCAtIDQxMyAtIDE3 Nzxicj5NQTExMDAyICgyMDAyKTogNTM5IC0gMjI2IC0gMTgwPGJyPk1BMTEwMDIgKDIwMDIpOiA1 MzkgLSA0MTMgLSAxNDA8YnI+TUExMTAwMiAoMjAwMik6IDU0MSAtIDIyNiAtIDE4MDxicj5NQTEx MDAyICgyMDAyKTogNTQxIC0gNDc4IC0gMTQwPGJyPk1BMTEwMDIgKDIwMDIpOiA1NDEgLSA0MTMg LSAxNDA8YnI+TUExMTAxOCAoMjAwMik6IDUzOCAtIDQxMyAtIDE0MAo8YnI+TUExMTAxOCAoMjAw Mik6IDUzOSAtIDQxMyAtIDE0MDxicj5NQTExMDE4ICgyMDAyKTogNTQxIC0gNDEzIC0gMTQwPGJy Pk1BMTEwMTkgKDIwMDIpOiA1MzcgLSAzMTIgLSAxNDA8YnI+TUExMTAxOSAoMjAwMik6IDUzOCAt IDMxMiAtIDE0MDxicj5NQTExMDE5ICgyMDAyKTogNTM5IC0gMzEyIC0gMTQwPGJyPk1BMTEwMTkg KDIwMDIpOiA1NDEgLSAzMTIgLSAxNDA8YnI+Wy4uLiBvdGhlciBJRHMgaW4gYmV0d2VlbiAyMDAy IGFuZCAyMDA4IC4uLl0KPGJyPk1BMTEwMDIgKDIwMDgpOiA1MzcgLSAyMjYgLSAxODA8YnI+TUEx MTAwMiAoMjAwOCk6IDUzNyAtIDQ3OCAtIDkyPGJyPk1BMTEwMDIgKDIwMDgpOiA1MzcgLSAzMTIg LSAxNTY8L2Rpdj4KPGRpdj5bLi4uIHRob3VzYW5kcyBvZiBhZGRpdGlvbmFsIElEcyAuLi5dPC9k aXY+PC9ibG9ja3F1b3RlPgo8ZGl2PkFuZCBJJiMzOTtkIGxpa2UgdGhlIG91dHB1dCB0byBsb29r IHNvbWV0aGluZyBsaWtlOjwvZGl2Pgo8YmxvY2txdW90ZSBkaXI9Imx0ciIgc3R5bGU9Ik1BUkdJ Ti1SSUdIVDogMHB4Ij4KPGRpdj5NQTExMDAyICgyMDAyKTogNTM3IC0gMjI2IC0mbmJzcDsxODA8 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSA0NDggLSAxNDA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUzOCAtIDIyNiAtIDE4MDxicj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDstIDQxMyAtIDE0MDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIDE3Nwo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUzOSAtIDIyNiAtIDE4MDxicj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDstIDQxMyAtIDE0MDxicj5NQTExMDAyICgyMDA4KTombmJzcDs1MzcgLSAyMjYgLSAxODA8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSA0NzggLSA5Mjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDst IDMxMiAtIDE1NjwvZGl2PgoKPGRpdj5bLi4uXTwvZGl2PjwvYmxvY2txdW90ZT4KPGRpdj5Tbywg dGhpbmdzIHdvdWxkIG5lZWQgdG8gYmUgZ3JvdXBlZCBieSBJRDMwNUImbmJzcDthbmQmbmJzcDtD WUNMRSwgdGhlbiBieSBVU0VfSUQsIHRoZW4gYnkgQ0FVU0VfSUQsIHRoZW4gYnkgU09VUkNFX0lE LiZuYnNwOyA8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5CdXQsIEkmIzM5O2QgZXZlbiBz ZXR0bGUgZm9yIG91dHB1dCB0aGF0IGxvb2tzIGxpa2U6PC9kaXY+CjxibG9ja3F1b3RlIGRpcj0i bHRyIiBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPgo8ZGl2Pgo8ZGl2Pk1BMTEwMDIgKDIwMDIp OiA1MzcgLSAyMjYgLSAxODA8YnI+TUExMTAwMiAoMjAwMik6IDUzNyAtIDQ0OCAtIDE0MDxicj5N QTExMDAyICgyMDAyKTogNTM4IC0gMjI2IC0gMTgwPGJyPk1BMTEwMDIgKDIwMDIpOiA1MzggLSA0 MTMgLSAxNDA8L2Rpdj4KPGRpdj5NQTExMDAyICgyMDAyKTogNTM4IC0gNDEzIC0gMTc3PGJyPk1B MTEwMDIgKDIwMDIpOiA1MzkgLSAyMjYgLSAxODA8YnI+TUExMTAwMiAoMjAwMik6IDUzOSAtIDQx MyAtIDE0MDxicj5NQTExMDAyICgyMDAyKTogNTQxIC0gMjI2IC0gMTgwPGJyPk1BMTEwMDIgKDIw MDIpOiA1NDEgLSA0NzggLSAxNDA8YnI+TUExMTAwMiAoMjAwMik6IDU0MSAtIDQxMyAtIDE0MDxi cj48YnI+TUExMTAwMiAoMjAwOCk6IDUzNyAtIDIyNiAtIDE4MAo8YnI+TUExMTAwMiAoMjAwOCk6 IDUzNyAtIDQ3OCAtIDkyPGJyPk1BMTEwMDIgKDIwMDgpOiA1MzcgLSAzMTIgLSAxNTY8L2Rpdj4K PGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5bLi4uIHRob3VzYW5kcyBvZiBhZGRpdGlvbmFsIElEcyAu Li5dPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPgo8ZGl2PndoZXJlIHRoZSBJRHMgZnJvbSB0aGUg dHdvIGRpZmZlcmVudCB5ZWFycyBhcmUgYWRqYWNlbnQgdG8gb25lIGFub3RoZXIuLi48L2Rpdj4K PGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5JIGJlbGlldmUgdGhpcyB3aWxsIGludm9sdmUgbXVjaCBw YWluIGFuZCBzdWZmZXJpbmcgd2hpbGUgSSB0cnkgdG8gZmlndXJlIG91dCBzdWNoIHRoaW5ncyBh cyBYTUwgbm9kZXMsIGdyb3VwaW5nLCBzb3J0aW5nLCBhbmQgdGhlIGxpa2UuLi4mbmJzcDsgQnV0 LCBJJiMzOTttIGhvcGluZyBzb21lb25lIHdpbGwgbG9vayBhdCB0aGlzIGFuZCBzYXkgJnF1b3Q7 Ym95IERhdWthcywgdGhhdCYjMzk7cyBlYXN5Li4uJm5ic3A7IGp1c3QmbmJzcDtkbyB0aGlzLCBh bmQgdGhlbiB0aGF0LCBhbmQgdm9pbGEgLSB5b3VyIGRvbmUhJnF1b3Q7Lgo8L2Rpdj4KPGRpdj4m bmJzcDs8L2Rpdj4KPGRpdj5BbnlvbmU/Jm5ic3A7IEFueW9uZT8mbmJzcDsgOy0pPC9kaXY+Cjxk aXY+Jm5ic3A7PC9kaXY+CjxkaXY+VGhhbmtzIGluIGFkdmFuY2UgZm9yIGFueSBoZWxwITwvZGl2 Pgo8ZGl2PlN0ZXZlPC9kaXY+Cg== --===============8347177999996132940==-- From kstratton@fastmail.us Thu Nov 29 21:42:15 2007 From: kstratton@fastmail.us To: wlug@lists.wlug.org Subject: [Wlug] ISP/Router/Modem Ethernet communications Date: Thu, 29 Nov 2007 21:42:05 -0500 Message-ID: <1196390525.14719.1224018399@webmail.messagingengine.com> In-Reply-To: <19badd460711281028l4742e015r7f11ca2aaa4b5a9c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5627357516611453361==" --===============5627357516611453361== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I just went through some painful debug session(s) with my ISP. For some reason, after forcing 10 base T half duplex through my windows box directly to my modem (I do not expect ISPs to support linux),everything suddenly worked (after reconnection and re-enabling of course). How often does this kind of thing happen? I have seen this kind of thing before only once before, and I was using an old hub that only supported 10 base T, not a home router that is supposed to autodetect the port type. I remember that the modem only supports 10 base T, but I am not 100% certain. Does anybody have an explanation of what most likely happened? Do not hesitate to skimp on technical details or references if is convenient. I desperately want to understand what happened. -- kstratton(a)fastmail.us --===============5627357516611453361==-- From fs@WPI.EDU Fri Nov 30 07:32:35 2007 From: Frank Sweetser To: wlug@lists.wlug.org Subject: Re: [Wlug] ISP/Router/Modem Ethernet communications Date: Fri, 30 Nov 2007 07:32:35 -0500 Message-ID: <475002E3.1050505@wpi.edu> In-Reply-To: <1196390525.14719.1224018399@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0938079713513953871==" --===============0938079713513953871== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit kstratton(a)fastmail.us wrote: > I just went through some painful debug session(s) with my ISP. For some > reason, after forcing 10 base T half duplex through my windows box > directly to my modem (I do not expect ISPs to support linux),everything > suddenly worked (after reconnection and re-enabling of course). > > How often does this kind of thing happen? I have seen this kind of > thing before only once before, and I was using an old hub that only > supported 10 base T, not a home router that is supposed to autodetect > the port type. I remember that the modem only supports 10 base T, but I > am not 100% certain. > > Does anybody have an explanation of what most likely happened? Do not > hesitate to skimp on technical details or references if is convenient. > I desperately want to understand what happened. Actually, that sounds like it's a problem on the PC end. Here's why. Back when there was only 10 half, it was easy to figure out what speed and duplex the other end was running at - 10 half! With 100M ethernet appearing, though, you soon had dual speed cards on the market. Rather than having to configure each and every port explicitly, users wanted to be able to plug in and have the card just do the right thing. Luckily, the signaling was different enough between 10 and 100 that it was relatively straightforward for a 100M card to detect whether the other end was speaking in 10M or 100M, and shift speeds appropriately. This is called, simply enough, autosense. However, speed is only half the equation. Along with 100M ethernet came switches. Switches, by allowing for a pseudo-dedicated link per machine (as opposed to hubs, in which the bandwidth of all links was shared by all stations), introduced and entirely new operating mode - full duplex. Unlike speed, there is no reliable way to passively detect what duplex the other end is configured for. So, to solve this, and also to lay down a foundation for interoperability as future network speeds appeared, the autonegotiation protocol was developed. Essentially, as soon as a link is established, both ends send a few magic packets at each other advertising what speed and duplex combinations it supports. The two ends pick the highest performance option supported by both, switch to that operational mode, and go on their merry way. Even after all this, you'll still see devices appearing which only support 10 half, and don't bother to do autonegotiation. When a newer device that does support autonegotiation is plugged into such an older device, autonegotiation will (obviously) fail. The new end will then default to autodetection for the speed, and will always use half duplex. This is why forcing on end of a link to full duplex, and leaving the other end on auto, will virtually always result in a duplex mismatch, and a link that works, just with really, really crappy performance. Donald Becker used to have a paper floating around describing this in a little more detail. I can't find the original anymore, but this looks like a copy of the same info: http://www.negotiateddata.com/files/Bunch_Article_020095.pdf So in the scenario you described, where the other end is sitting fixed at 10 half, it would have been up to your computer to gracefully fail autonegotiation, and use autosense to configure the link at 10 half. Sadly, such bugs, where chipset manufacturers assume that everyone else out there will always support autonegotiation, are not unheard of these days. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC --===============0938079713513953871==-- From john@stoffel.org Fri Nov 30 16:29:29 2007 From: John Stoffel To: wlug@lists.wlug.org Subject: Re: [Wlug] ISP/Router/Modem Ethernet communications Date: Fri, 30 Nov 2007 16:29:17 -0500 Message-ID: <18256.32941.315284.783296@stoffel.org> In-Reply-To: <1196390525.14719.1224018399@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7213096437901393761==" --===============7213096437901393761== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit kstratton> I just went through some painful debug session(s) with my kstratton> ISP. For some reason, after forcing 10 base T half duplex kstratton> through my windows box directly to my modem (I do not kstratton> expect ISPs to support linux),everything suddenly worked kstratton> (after reconnection and re-enabling of course). Can you give more details on the cable modem box you're using and the PC as well? Such as what network card in the PC you are using? kstratton> How often does this kind of thing happen? I have seen this kstratton> kind of thing before only once before, and I was using an kstratton> old hub that only supported 10 base T, not a home router kstratton> that is supposed to autodetect the port type. I remember kstratton> that the modem only supports 10 base T, but I am not 100% kstratton> certain. Sun and Cisco were notirious for having problems figuring our autonegotiation on the Sun hme (Happy Meal Ethernet) cards. They'd end up 100Full on one side and 100 Half Duplex on the other. It would work, just very slowly... kstratton> Does anybody have an explanation of what most likely kstratton> happened? Do not hesitate to skimp on technical details or kstratton> references if is convenient. I desperately want to kstratton> understand what happened. -- Something didn't autonegotiate properly. Did you try powering off both devices and then powering them on starting with the cable box? Also, alot of Cable Companies lock the cable box to the first MAC (ethernet hardware address) they see coming over the link. So if you boot up with a PC, and then try to move to something else like a NAT box or a linux box acting as a NAT box, things can go wonky. Usually a hard reset of the Cablemodem will do the trick, but sometimes you need to contact the ISP and ask them to reset it for you. In your case, it really sounds like a problem with Autonegotiation. Some devices just don't do a good job, esp older equipment from before the Gigabit ethernet stage. Just to expand on Frank's email, the people who designed the Gigiabit Ethernet standard over Copper (802.xxx I can't remember) saw all the problems with the 100/10 devices and autonegotiation and explicity made AutoNeg part of the spec in a very well detailed way, so that these problems won't happen again. As a matter of fact, Gigabit ports are much smarter and don't require crossover cables either, you can just plug them into back to back, they figure out what's going on automatically and adjust. The joys of big ASICs! John --===============7213096437901393761==-- From kstratton@fastmail.us Sat Dec 1 06:39:21 2007 From: kstratton@fastmail.us To: wlug@lists.wlug.org Subject: Re: [Wlug] ISP/Router/Modem Ethernet communications Date: Sat, 01 Dec 2007 06:39:11 -0500 Message-ID: <1196509151.20189.1224233513@webmail.messagingengine.com> In-Reply-To: <18256.32941.315284.783296@stoffel.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0804110991922638043==" --===============0804110991922638043== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thank you everybody for your replies. I now know that this autonegotiation issue can be potentially be a much bigger problem with 100 base T than I thought. Specifically, there is no defined mechanism in the spec to autonegotiate for 100 base T cards. If I actually have time for this, I guess I will have to find the spec and read it... My network driver (windows) is a "NVIDIA nForce MCP Networking Controller". It is an integrated network connector on a HP pavilion. I do not know of a windows equivalent to lspci, so I cannot get the actual reported hardware rev. Maybe I have to get a good live CD distro. In this case, resetting the cable modem did not fix the problem, although it may have fixed it in the past. My router is a four port Linksys Router about 5 to 8 years old. My modem is a Speedstream 5280. I am sufficiently annoyed by this problem to consider buying a new router if this router has a force 10 base T option for the WAN. I am willing to listen to any suggestions. On Fri, 30 Nov 2007 16:29:17 -0500, "John Stoffel" said: > > kstratton> I just went through some painful debug session(s) with my > kstratton> ISP. For some reason, after forcing 10 base T half duplex > kstratton> through my windows box directly to my modem (I do not > kstratton> expect ISPs to support linux),everything suddenly worked > kstratton> (after reconnection and re-enabling of course). > > Can you give more details on the cable modem box you're using and the > PC as well? Such as what network card in the PC you are using? > > kstratton> How often does this kind of thing happen? I have seen this > kstratton> kind of thing before only once before, and I was using an > kstratton> old hub that only supported 10 base T, not a home router > kstratton> that is supposed to autodetect the port type. I remember > kstratton> that the modem only supports 10 base T, but I am not 100% > kstratton> certain. > > Sun and Cisco were notirious for having problems figuring our > autonegotiation on the Sun hme (Happy Meal Ethernet) cards. They'd > end up 100Full on one side and 100 Half Duplex on the other. It would > work, just very slowly... > > kstratton> Does anybody have an explanation of what most likely > kstratton> happened? Do not hesitate to skimp on technical details or > kstratton> references if is convenient. I desperately want to > kstratton> understand what happened. -- > > Something didn't autonegotiate properly. Did you try powering off > both devices and then powering them on starting with the cable box? > > Also, alot of Cable Companies lock the cable box to the first MAC > (ethernet hardware address) they see coming over the link. So if you > boot up with a PC, and then try to move to something else like a NAT > box or a linux box acting as a NAT box, things can go wonky. > > Usually a hard reset of the Cablemodem will do the trick, but > sometimes you need to contact the ISP and ask them to reset it for > you. > > In your case, it really sounds like a problem with Autonegotiation. > Some devices just don't do a good job, esp older equipment from before > the Gigabit ethernet stage. > > Just to expand on Frank's email, the people who designed the Gigiabit > Ethernet standard over Copper (802.xxx I can't remember) saw all the > problems with the 100/10 devices and autonegotiation and explicity > made AutoNeg part of the spec in a very well detailed way, so that > these problems won't happen again. As a matter of fact, Gigabit ports > are much smarter and don't require crossover cables either, you can > just plug them into back to back, they figure out what's going on > automatically and adjust. > > The joys of big ASICs! > > John > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug -- kstratton(a)fastmail.us --===============0804110991922638043==-- From cfinlay@gmail.com Sat Dec 1 10:13:33 2007 From: Conner Finlay To: wlug@lists.wlug.org Subject: Re: [Wlug] ISP/Router/Modem Ethernet communications Date: Sat, 01 Dec 2007 10:13:19 -0500 Message-ID: <9d000acd0712010713x15378bfbpe9b74418d977a05a@mail.gmail.com> In-Reply-To: <1196509151.20189.1224233513@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5554505736880854972==" --===============5554505736880854972== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I've got a Linksys WRT54GL which in my opinion is a great router for the price. I then flashed it with dd-wrt. Here is a list of routers which can support it. http://www.dd-wrt.com/wiki/index.php/Supported_Devices -Conner On Dec 1, 2007 6:39 AM, wrote: > Thank you everybody for your replies. I now know that this > autonegotiation issue can be potentially be a much bigger problem with > 100 base T than I thought. Specifically, there is no defined mechanism > in the spec to autonegotiate for 100 base T cards. If I actually have > time for this, I guess I will have to find the spec and read it... > > My network driver (windows) is a "NVIDIA nForce MCP Networking > Controller". It is an integrated network connector on a HP pavilion. I > do not know of a windows equivalent to lspci, so I cannot get the actual > reported hardware rev. Maybe I have to get a good live CD distro. > > In this case, resetting the cable modem did not fix the problem, > although it may have fixed it in the past. > > My router is a four port Linksys Router about 5 to 8 years old. My > modem is a Speedstream 5280. I am sufficiently annoyed by this problem > to consider buying a new router if this router has a force 10 base T > option for the WAN. I am willing to listen to any suggestions. > > > > On Fri, 30 Nov 2007 16:29:17 -0500, "John Stoffel" > said: > > > > kstratton> I just went through some painful debug session(s) with my > > kstratton> ISP. For some reason, after forcing 10 base T half duplex > > kstratton> through my windows box directly to my modem (I do not > > kstratton> expect ISPs to support linux),everything suddenly worked > > kstratton> (after reconnection and re-enabling of course). > > > > Can you give more details on the cable modem box you're using and the > > PC as well? Such as what network card in the PC you are using? > > > > kstratton> How often does this kind of thing happen? I have seen this > > kstratton> kind of thing before only once before, and I was using an > > kstratton> old hub that only supported 10 base T, not a home router > > kstratton> that is supposed to autodetect the port type. I remember > > kstratton> that the modem only supports 10 base T, but I am not 100% > > kstratton> certain. > > > > Sun and Cisco were notirious for having problems figuring our > > autonegotiation on the Sun hme (Happy Meal Ethernet) cards. They'd > > end up 100Full on one side and 100 Half Duplex on the other. It would > > work, just very slowly... > > > > kstratton> Does anybody have an explanation of what most likely > > kstratton> happened? Do not hesitate to skimp on technical details or > > kstratton> references if is convenient. I desperately want to > > kstratton> understand what happened. -- > > > > Something didn't autonegotiate properly. Did you try powering off > > both devices and then powering them on starting with the cable box? > > > > Also, alot of Cable Companies lock the cable box to the first MAC > > (ethernet hardware address) they see coming over the link. So if you > > boot up with a PC, and then try to move to something else like a NAT > > box or a linux box acting as a NAT box, things can go wonky. > > > > Usually a hard reset of the Cablemodem will do the trick, but > > sometimes you need to contact the ISP and ask them to reset it for > > you. > > > > In your case, it really sounds like a problem with Autonegotiation. > > Some devices just don't do a good job, esp older equipment from before > > the Gigabit ethernet stage. > > > > Just to expand on Frank's email, the people who designed the Gigiabit > > Ethernet standard over Copper (802.xxx I can't remember) saw all the > > problems with the 100/10 devices and autonegotiation and explicity > > made AutoNeg part of the spec in a very well detailed way, so that > > these problems won't happen again. As a matter of fact, Gigabit ports > > are much smarter and don't require crossover cables either, you can > > just plug them into back to back, they figure out what's going on > > automatically and adjust. > > > > The joys of big ASICs! > > > > John > > _______________________________________________ > > Wlug mailing list > > Wlug(a)mail.wlug.org > > http://mail.wlug.org/mailman/listinfo/wlug > -- > > kstratton(a)fastmail.us > > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug > --===============5554505736880854972== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PGRpdj5JJiMzOTt2ZSZuYnNwO2dvdCZuYnNwO2EgTGlua3N5cyBXUlQ1NEdMIHdoaWNoIGluIG15 IG9waW5pb24gaXMgYSBncmVhdCByb3V0ZXIgZm9yIHRoZSBwcmljZS4gSSB0aGVuIGZsYXNoZWQg aXQgd2l0aCBkZC13cnQuIEhlcmUgaXMgYSBsaXN0IG9mIHJvdXRlcnMgd2hpY2ggY2FuIHN1cHBv cnQgaXQuPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+Jm5ic3A7PGEgaHJlZj0iaHR0cDov L3d3dy5kZC13cnQuY29tL3dpa2kvaW5kZXgucGhwL1N1cHBvcnRlZF9EZXZpY2VzIj5odHRwOi8v d3d3LmRkLXdydC5jb20vd2lraS9pbmRleC5waHAvU3VwcG9ydGVkX0RldmljZXM8L2E+PGJyPjwv ZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2Pi1Db25uZXI8YnI+PC9kaXY+CjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBEZWMgMSwgMjAwNyA2OjM5IEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmtzdHJhdHRvbkBmYXN0bWFpbC51cyI+a3N0cmF0dG9uQGZhc3RtYWlsLnVzPC9hPiZndDsgd3Jv dGU6PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxF RlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4 IHNvbGlkIj5UaGFuayB5b3UgZXZlcnlib2R5IGZvciB5b3VyIHJlcGxpZXMuICZuYnNwO0kgbm93 IGtub3cgdGhhdCB0aGlzPGJyPmF1dG9uZWdvdGlhdGlvbiBpc3N1ZSBjYW4gYmUgcG90ZW50aWFs bHkgYmUgYSBtdWNoIGJpZ2dlciBwcm9ibGVtIHdpdGgKPGJyPjEwMCBiYXNlIFQgdGhhbiBJIHRo b3VnaHQuICZuYnNwO1NwZWNpZmljYWxseSwgdGhlcmUgaXMgbm8gZGVmaW5lZCBtZWNoYW5pc208 YnI+aW4gdGhlIHNwZWMgdG8gYXV0b25lZ290aWF0ZSBmb3IgMTAwIGJhc2UgVCBjYXJkcy4gJm5i c3A7SWYgSSBhY3R1YWxseSBoYXZlPGJyPnRpbWUgZm9yIHRoaXMsIEkgZ3Vlc3MgSSB3aWxsIGhh dmUgdG8gZmluZCB0aGUgc3BlYyBhbmQgcmVhZCBpdC4uLjxicj4KPGJyPk15IG5ldHdvcmsgZHJp dmVyICh3aW5kb3dzKSBpcyBhICZxdW90O05WSURJQSBuRm9yY2UgTUNQIE5ldHdvcmtpbmc8YnI+ Q29udHJvbGxlciZxdW90Oy4gJm5ic3A7SXQgaXMgYW4gaW50ZWdyYXRlZCBuZXR3b3JrIGNvbm5l Y3RvciBvbiBhIEhQIHBhdmlsaW9uLiAmbmJzcDtJPGJyPmRvIG5vdCBrbm93IG9mIGEgd2luZG93 cyBlcXVpdmFsZW50IHRvIGxzcGNpLCBzbyBJIGNhbm5vdCBnZXQgdGhlIGFjdHVhbAo8YnI+cmVw b3J0ZWQgaGFyZHdhcmUgcmV2LiAmbmJzcDtNYXliZSBJIGhhdmUgdG8gZ2V0IGEgZ29vZCBsaXZl IENEIGRpc3Ryby48YnI+PGJyPkluIHRoaXMgY2FzZSwgcmVzZXR0aW5nIHRoZSBjYWJsZSBtb2Rl bSBkaWQgbm90IGZpeCB0aGUgcHJvYmxlbSw8YnI+YWx0aG91Z2ggaXQgbWF5IGhhdmUgZml4ZWQg aXQgaW4gdGhlIHBhc3QuPGJyPjxicj5NeSByb3V0ZXIgaXMgYSBmb3VyIHBvcnQgTGlua3N5cyBS b3V0ZXIgYWJvdXQgNSB0byA4IHllYXJzIG9sZC4gJm5ic3A7TXkKPGJyPm1vZGVtIGlzIGEgU3Bl ZWRzdHJlYW0gNTI4MC4gJm5ic3A7SSBhbSBzdWZmaWNpZW50bHkgYW5ub3llZCBieSB0aGlzIHBy b2JsZW08YnI+dG8gY29uc2lkZXIgYnV5aW5nIGEgbmV3IHJvdXRlciBpZiB0aGlzIHJvdXRlciBo YXMgYSBmb3JjZSAxMCBiYXNlIFQ8YnI+b3B0aW9uIGZvciB0aGUgV0FOLiAmbmJzcDtJIGFtIHdp bGxpbmcgdG8gbGlzdGVuIHRvIGFueSBzdWdnZXN0aW9ucy48YnI+PGJyPgo8YnI+PGJyPk9uIEZy aSwgMzAgTm92IDIwMDcgMTY6Mjk6MTcgLTA1MDAsICZxdW90O0pvaG4gU3RvZmZlbCZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG5Ac3RvZmZlbC5vcmciPmpvaG5Ac3RvZmZlbC5vcmc8L2E+ Jmd0Ozxicj5zYWlkOjxicj4KPGRpdj4KPGRpdj48L2Rpdj4KPGRpdiBjbGFzcz0iV2ozQzdjIj4m Z3Q7PGJyPiZndDsga3N0cmF0dG9uJmd0OyBJIGp1c3Qgd2VudCB0aHJvdWdoIHNvbWUgcGFpbmZ1 bCBkZWJ1ZyBzZXNzaW9uKHMpIHdpdGggbXk8YnI+Jmd0OyBrc3RyYXR0b24mZ3Q7IElTUC4gJm5i c3A7Rm9yIHNvbWUgcmVhc29uLCBhZnRlciBmb3JjaW5nIDEwIGJhc2UgVCBoYWxmIGR1cGxleDxi cj4mZ3Q7IGtzdHJhdHRvbiZndDsgdGhyb3VnaCBteSB3aW5kb3dzIGJveCBkaXJlY3RseSB0byBt eSBtb2RlbSAoSSBkbyBub3QKPGJyPiZndDsga3N0cmF0dG9uJmd0OyBleHBlY3QgSVNQcyB0byBz dXBwb3J0IGxpbnV4KSxldmVyeXRoaW5nIHN1ZGRlbmx5IHdvcmtlZDxicj4mZ3Q7IGtzdHJhdHRv biZndDsgKGFmdGVyIHJlY29ubmVjdGlvbiBhbmQgcmUtZW5hYmxpbmcgb2YgY291cnNlKS48YnI+ Jmd0Ozxicj4mZ3Q7IENhbiB5b3UgZ2l2ZSBtb3JlIGRldGFpbHMgb24gdGhlIGNhYmxlIG1vZGVt IGJveCB5b3UmIzM5O3JlIHVzaW5nIGFuZCB0aGUKPGJyPiZndDsgUEMgYXMgd2VsbD8gJm5ic3A7 U3VjaCBhcyB3aGF0IG5ldHdvcmsgY2FyZCBpbiB0aGUgUEMgeW91IGFyZSB1c2luZz88YnI+Jmd0 Ozxicj4mZ3Q7IGtzdHJhdHRvbiZndDsgSG93IG9mdGVuIGRvZXMgdGhpcyBraW5kIG9mIHRoaW5n IGhhcHBlbj8gJm5ic3A7SSBoYXZlIHNlZW4gdGhpczxicj4mZ3Q7IGtzdHJhdHRvbiZndDsga2lu ZCBvZiB0aGluZyBiZWZvcmUgb25seSBvbmNlIGJlZm9yZSwgYW5kIEkgd2FzIHVzaW5nIGFuCjxi cj4mZ3Q7IGtzdHJhdHRvbiZndDsgb2xkIGh1YiB0aGF0IG9ubHkgc3VwcG9ydGVkIDEwIGJhc2Ug VCwgbm90IGEgaG9tZSByb3V0ZXI8YnI+Jmd0OyBrc3RyYXR0b24mZ3Q7IHRoYXQgaXMgc3VwcG9z ZWQgdG8gYXV0b2RldGVjdCB0aGUgcG9ydCB0eXBlLiAmbmJzcDtJIHJlbWVtYmVyPGJyPiZndDsg a3N0cmF0dG9uJmd0OyB0aGF0IHRoZSBtb2RlbSBvbmx5IHN1cHBvcnRzIDEwIGJhc2UgVCwgYnV0 IEkgYW0gbm90IDEwMCUKPGJyPiZndDsga3N0cmF0dG9uJmd0OyBjZXJ0YWluLjxicj4mZ3Q7PGJy PiZndDsgU3VuIGFuZCBDaXNjbyB3ZXJlIG5vdGlyaW91cyBmb3IgaGF2aW5nIHByb2JsZW1zIGZp Z3VyaW5nIG91cjxicj4mZ3Q7IGF1dG9uZWdvdGlhdGlvbiBvbiB0aGUgU3VuIGhtZSAoSGFwcHkg TWVhbCBFdGhlcm5ldCkgY2FyZHMuICZuYnNwO1RoZXkmIzM5O2Q8YnI+Jmd0OyBlbmQgdXAgMTAw RnVsbCBvbiBvbmUgc2lkZSBhbmQgMTAwIEhhbGYgRHVwbGV4IG9uIHRoZSBvdGhlci4gJm5ic3A7 SXQgd291bGQKPGJyPiZndDsgd29yaywganVzdCB2ZXJ5IHNsb3dseS4uLjxicj4mZ3Q7PGJyPiZn dDsga3N0cmF0dG9uJmd0OyBEb2VzIGFueWJvZHkgaGF2ZSBhbiBleHBsYW5hdGlvbiBvZiB3aGF0 IG1vc3QgbGlrZWx5PGJyPiZndDsga3N0cmF0dG9uJmd0OyBoYXBwZW5lZD8gJm5ic3A7RG8gbm90 IGhlc2l0YXRlIHRvIHNraW1wIG9uIHRlY2huaWNhbCBkZXRhaWxzIG9yPGJyPiZndDsga3N0cmF0 dG9uJmd0OyByZWZlcmVuY2VzIGlmIGlzIGNvbnZlbmllbnQuICZuYnNwO0kgZGVzcGVyYXRlbHkg d2FudCB0bwo8YnI+Jmd0OyBrc3RyYXR0b24mZ3Q7IHVuZGVyc3RhbmQgd2hhdCBoYXBwZW5lZC4g Jm5ic3A7LS08YnI+Jmd0Ozxicj4mZ3Q7IFNvbWV0aGluZyBkaWRuJiMzOTt0IGF1dG9uZWdvdGlh dGUgcHJvcGVybHkuICZuYnNwO0RpZCB5b3UgdHJ5IHBvd2VyaW5nIG9mZjxicj4mZ3Q7IGJvdGgg ZGV2aWNlcyBhbmQgdGhlbiBwb3dlcmluZyB0aGVtIG9uIHN0YXJ0aW5nIHdpdGggdGhlIGNhYmxl IGJveD88YnI+Jmd0Owo8YnI+Jmd0OyBBbHNvLCBhbG90IG9mIENhYmxlIENvbXBhbmllcyBsb2Nr IHRoZSBjYWJsZSBib3ggdG8gdGhlIGZpcnN0IE1BQzxicj4mZ3Q7IChldGhlcm5ldCBoYXJkd2Fy ZSBhZGRyZXNzKSB0aGV5IHNlZSBjb21pbmcgb3ZlciB0aGUgbGluay4gJm5ic3A7U28gaWYgeW91 PGJyPiZndDsgYm9vdCB1cCB3aXRoIGEgUEMsIGFuZCB0aGVuIHRyeSB0byBtb3ZlIHRvIHNvbWV0 aGluZyBlbHNlIGxpa2UgYSBOQVQKPGJyPiZndDsgYm94IG9yIGEgbGludXggYm94IGFjdGluZyBh cyBhIE5BVCBib3gsIHRoaW5ncyBjYW4gZ28gd29ua3kuPGJyPiZndDs8YnI+Jmd0OyBVc3VhbGx5 IGEgaGFyZCByZXNldCBvZiB0aGUgQ2FibGVtb2RlbSB3aWxsIGRvIHRoZSB0cmljaywgYnV0PGJy PiZndDsgc29tZXRpbWVzIHlvdSBuZWVkIHRvIGNvbnRhY3QgdGhlIElTUCBhbmQgYXNrIHRoZW0g dG8gcmVzZXQgaXQgZm9yCjxicj4mZ3Q7IHlvdS48YnI+Jmd0Ozxicj4mZ3Q7IEluIHlvdXIgY2Fz ZSwgaXQgcmVhbGx5IHNvdW5kcyBsaWtlIGEgcHJvYmxlbSB3aXRoIEF1dG9uZWdvdGlhdGlvbi48 YnI+Jmd0OyBTb21lIGRldmljZXMganVzdCBkb24mIzM5O3QgZG8gYSBnb29kIGpvYiwgZXNwIG9s ZGVyIGVxdWlwbWVudCBmcm9tIGJlZm9yZTxicj4mZ3Q7IHRoZSBHaWdhYml0IGV0aGVybmV0IHN0 YWdlLjxicj4mZ3Q7Cjxicj4mZ3Q7IEp1c3QgdG8gZXhwYW5kIG9uIEZyYW5rJiMzOTtzIGVtYWls LCB0aGUgcGVvcGxlIHdobyBkZXNpZ25lZCB0aGUgR2lnaWFiaXQ8YnI+Jmd0OyBFdGhlcm5ldCBz dGFuZGFyZCBvdmVyIENvcHBlciAoODAyLnh4eCBJIGNhbiYjMzk7dCByZW1lbWJlcikgc2F3IGFs bCB0aGU8YnI+Jmd0OyBwcm9ibGVtcyB3aXRoIHRoZSAxMDAvMTAgZGV2aWNlcyBhbmQgYXV0b25l Z290aWF0aW9uIGFuZCBleHBsaWNpdHkKPGJyPiZndDsgbWFkZSBBdXRvTmVnIHBhcnQgb2YgdGhl IHNwZWMgaW4gYSB2ZXJ5IHdlbGwgZGV0YWlsZWQgd2F5LCBzbyB0aGF0PGJyPiZndDsgdGhlc2Ug cHJvYmxlbXMgd29uJiMzOTt0IGhhcHBlbiBhZ2Fpbi4gJm5ic3A7QXMgYSBtYXR0ZXIgb2YgZmFj dCwgR2lnYWJpdCBwb3J0czxicj4mZ3Q7IGFyZSBtdWNoIHNtYXJ0ZXIgYW5kIGRvbiYjMzk7dCBy ZXF1aXJlIGNyb3Nzb3ZlciBjYWJsZXMgZWl0aGVyLCB5b3UgY2FuCjxicj4mZ3Q7IGp1c3QgcGx1 ZyB0aGVtIGludG8gYmFjayB0byBiYWNrLCB0aGV5IGZpZ3VyZSBvdXQgd2hhdCYjMzk7cyBnb2lu ZyBvbjxicj4mZ3Q7IGF1dG9tYXRpY2FsbHkgYW5kIGFkanVzdC48YnI+Jmd0Ozxicj4mZ3Q7IFRo ZSBqb3lzIG9mIGJpZyBBU0lDcyE8YnI+Jmd0Ozxicj4mZ3Q7IEpvaG48YnI+Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo8YnI+Jmd0OyBXbHVnIG1h aWxpbmcgbGlzdDxicj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpXbHVnQG1haWwud2x1Zy5vcmciPlds dWdAbWFpbC53bHVnLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJodHRwOi8vbWFpbC53bHVnLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3dsdWciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbWFpbC53bHVn Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dsdWc8L2E+PGJyPgo8L2Rpdj48L2Rpdj48Zm9udCBjb2xv cj0iIzg4ODg4OCI+LS08YnI+PGJyPiZuYnNwOzxhIGhyZWY9Im1haWx0bzprc3RyYXR0b25AZmFz dG1haWwudXMiPmtzdHJhdHRvbkBmYXN0bWFpbC51czwvYT48YnI+PC9mb250Pgo8ZGl2Pgo8ZGl2 PjwvZGl2Pgo8ZGl2IGNsYXNzPSJXajNDN2MiPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj5XbHVnIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJt YWlsdG86V2x1Z0BtYWlsLndsdWcub3JnIj5XbHVnQG1haWwud2x1Zy5vcmc8L2E+PGJyPjxhIGhy ZWY9Imh0dHA6Ly9tYWlsLndsdWcub3JnL21haWxtYW4vbGlzdGluZm8vd2x1ZyIgdGFyZ2V0PSJf YmxhbmsiPgpodHRwOi8vbWFpbC53bHVnLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dsdWc8L2E+PGJy PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4K --===============5554505736880854972==-- From john@stoffel.org Mon Dec 3 12:18:32 2007 From: John Stoffel To: wlug@lists.wlug.org Subject: Re: [Wlug] ISP/Router/Modem Ethernet communications Date: Mon, 03 Dec 2007 12:18:24 -0500 Message-ID: <18260.14944.559380.213968@stoffel.org> In-Reply-To: <1196509151.20189.1224233513@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5529028358305219906==" --===============5529028358305219906== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit kstratton> Thank you everybody for your replies. I now know that this kstratton> autonegotiation issue can be potentially be a much bigger kstratton> problem with 100 base T than I thought. Specifically, kstratton> there is no defined mechanism in the spec to autonegotiate kstratton> for 100 base T cards. If I actually have time for this, I kstratton> guess I will have to find the spec and read it... Don't bother, it's not going to help you really. Just recognize that you can see auto-neg issues and keep it in mind when trouble shooting problems. kstratton> My network driver (windows) is a "NVIDIA nForce MCP kstratton> Networking Controller". It is an integrated network kstratton> connector on a HP pavilion. I do not know of a windows kstratton> equivalent to lspci, so I cannot get the actual reported kstratton> hardware rev. Maybe I have to get a good live CD distro. Hmm... I thought you were having auto-neg problems between your PC and the cable modem, you never said you had a Router in there. At least I don't remember and it's monday and I'm not good at memory... :] kstratton> In this case, resetting the cable modem did not fix the kstratton> problem, although it may have fixed it in the past. kstratton> My router is a four port Linksys Router about 5 to 8 years kstratton> old. My modem is a Speedstream 5280. I am sufficiently kstratton> annoyed by this problem to consider buying a new router if kstratton> this router has a force 10 base T option for the WAN. I am kstratton> willing to listen to any suggestions. So just to rehash the problem, you are seeing problems between the router and the cable modem, or between the router and the PC? Ok, so I just re-read your initial post and it sounds like you pulled the Router out of the mix when debugging with your ISP. What was the initial problem that had you remove the Router? What were the symptoms? It could simply be that one of the hardware boxes is getting flaky and starting to fail. But we need more information to really help. I've got an old Motorola Cable Modem (bought my own replacement) which I'd be willing sell/lend if need be. I think it's a 3200 something or other. Don't remember off hand. I'm with Charter, which might be an issue. Good luck, John --===============5529028358305219906==-- From kstratton@fastmail.us Mon Dec 3 20:32:27 2007 From: kstratton@fastmail.us To: wlug@lists.wlug.org Subject: Re: [Wlug] ISP/Router/Modem Ethernet communications Date: Mon, 03 Dec 2007 20:32:17 -0500 Message-ID: <1196731937.3994.1224625991@webmail.messagingengine.com> In-Reply-To: <18260.14944.559380.213968@stoffel.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6037843146981539221==" --===============6037843146981539221== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit My initial problem was that I lost all connectivity with my router connected to the DSL modem. this was after my setup worked consistently for over 9 months. I was on the phone for over 4 hours total (2 sessions, the first one blamed it on an outage). The ISP technicians can "see" the modem when I was having this problem and confirmed my setup of the router. All the LEDs were positive (green). The ISP technician then asked for me to connect the modem directly to the computer. Various things were tried, including powering down the modem and computer. Still no connection (ping would not work). The last thing tried was to force the computer to talk to the mode at 1/2 duplex 10 base T and try to connect. This seemed to kickstart everything and everything now works with the router or directly to the PC. This may also seem to be a coincidence, but this problem happened about a week and a half after changing the terms on my DSL service (cheaper bundle). It is looking like the solution is one of the following: 1) Buy a new DSL modem that sopports 10 and 100 base T (I think I saw one at best buy, mine only supports 10 base T) 2) Buy a router that I can put linux on so that I can configure the router for 10 base T.this sounds like fun, but the likelyhood of eventually breaking it is great. 3) Buy both a new modem and router. I am confident that my equipment predated the gigabit standard release, so this is not a totally irrational solution (based on the autonegotiation standards). 4) Ignore the issue and kickstart the connection again if the problem re-occurs. My guess is on #4 for now, but #1 then #2 or #3 is still a possibility. Thank you everybody for your help. My biggest issue was not realizing that this kind of autonegotiation issue is not very unusual. I REALLY dislike it when I call tech support and my equipment is at fault. On Mon, 3 Dec 2007 12:18:24 -0500, "John Stoffel" said: > > kstratton> Thank you everybody for your replies. I now know that this > kstratton> autonegotiation issue can be potentially be a much bigger > kstratton> problem with 100 base T than I thought. Specifically, > kstratton> there is no defined mechanism in the spec to autonegotiate > kstratton> for 100 base T cards. If I actually have time for this, I > kstratton> guess I will have to find the spec and read it... > > Don't bother, it's not going to help you really. Just recognize that > you can see auto-neg issues and keep it in mind when trouble shooting > problems. > > kstratton> My network driver (windows) is a "NVIDIA nForce MCP > kstratton> Networking Controller". It is an integrated network > kstratton> connector on a HP pavilion. I do not know of a windows > kstratton> equivalent to lspci, so I cannot get the actual reported > kstratton> hardware rev. Maybe I have to get a good live CD distro. > > Hmm... I thought you were having auto-neg problems between your PC and > the cable modem, you never said you had a Router in there. At least I > don't remember and it's monday and I'm not good at memory... :] > > kstratton> In this case, resetting the cable modem did not fix the > kstratton> problem, although it may have fixed it in the past. > > kstratton> My router is a four port Linksys Router about 5 to 8 years > kstratton> old. My modem is a Speedstream 5280. I am sufficiently > kstratton> annoyed by this problem to consider buying a new router if > kstratton> this router has a force 10 base T option for the WAN. I am > kstratton> willing to listen to any suggestions. > > So just to rehash the problem, you are seeing problems between the > router and the cable modem, or between the router and the PC? > > Ok, so I just re-read your initial post and it sounds like you pulled > the Router out of the mix when debugging with your ISP. What was the > initial problem that had you remove the Router? What were the > symptoms? > > It could simply be that one of the hardware boxes is getting flaky and > starting to fail. But we need more information to really help. > > I've got an old Motorola Cable Modem (bought my own replacement) which > I'd be willing sell/lend if need be. I think it's a 3200 something or > other. Don't remember off hand. I'm with Charter, which might be an > issue. > > Good luck, > John > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug -- kstratton(a)fastmail.us --===============6037843146981539221==-- From vapier@gentoo.org Mon Dec 3 21:52:14 2007 From: Mike Frysinger To: wlug@lists.wlug.org Subject: Re: [Wlug] ISP/Router/Modem Ethernet communications Date: Mon, 03 Dec 2007 21:25:07 -0500 Message-ID: <200712032125.08748.vapier@gentoo.org> In-Reply-To: <1196731937.3994.1224625991@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1442862735281953641==" --===============1442862735281953641== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Monday 03 December 2007, kstratton(a)fastmail.us wrote: > It is looking like the solution is one of the following: > > 1) Buy a new DSL modem that sopports 10 and 100 base T (I think I saw > one at best buy, mine only supports 10 base T) > 2) Buy a router that I can put linux on so that I can configure the > router for 10 base T.this sounds like fun, but the likelyhood of > eventually breaking it is great. > 3) Buy both a new modem and router. I am confident that my equipment > predated the gigabit standard release, so this is not a totally > irrational solution (based on the autonegotiation standards). > 4) Ignore the issue and kickstart the connection again if the problem > re-occurs. > > My guess is on #4 for now, but #1 then #2 or #3 is still a possibility. > > Thank you everybody for your help. My biggest issue was not realizing > that this kind of autonegotiation issue is not very unusual. I REALLY > dislike it when I call tech support and my equipment is at fault. what kind of modem is it ? ive collected a few dsl modems that are just gathering dust in my basement. -mike --===============1442862735281953641== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIuMC43IChHTlUv TGludXgpCgppUUlWQXdVQVIxUzZoRUZqTzUvb04vV0JBUUxBYXcvL1RkRFhKMFVHaEpjMmZMQVB0 NTg5M1JZN3dJbmRvM0xGCm9Hd2JJTVhqZnBTcm1jczEwOG0yUW1XSmVEeTFaNi8xU3BRdEJmNHlO WU02WjlNbzdUeXR3ZnJLb3VrR3FBSkoKVTcvV2lXV3FWRE1leTRmdUJtSDk2TEJUb0gvUjVRNzAv cXZSSVlraHlxOUNOam9UWGsyd3F0NG1xNm90cUdpKwpQTUpzSmlHMjU5MjZvd0toRTBJWHZoQ1dV LzlKbHFsVGtqaG1MSXJqc2xWRDZKVTIxeDdIeEh2Q3Bxamhab3pYCll4QVNzeG9vVGx4RWhwa1lR MVRJS0MxUllYdisxbWFCMUhYTXYrQk1sWW1LYWxPbUQyMzFHUnFRM2ZQT2JHVHEKckluZE05VEhL ZjB3S2xYL1JDeDFWVVVWaS9MeTljcDFjKzdKdzYxREgxN1VkOHVwYkU0TmdtOFM1L1YzV2o1awp2 UlRnblVZQkNpSEs3S0ZOcWtKWUFreG4ybWhkK1NDaGVCKzdVOEpSNmt1WS9pYlJYcEtiRmJLNzJQ UWVBTFdnClJKdnNmQm1PTFJxRHRDNWdDZXhSU1M2VnNWU2k4VmszbTd6RWsrc2pZSW43ZmVZdlUw NFBCazNqWHJqQWRlZ3EKbmFuSlo2ZndyMFBIR2dtVHdSRmZYYVZqUUptOHhIVzFqUFBXVDk2Znc4 ejNyRCttUjRJMTRHTFcxajR3NkpWWgplYzNFcmN5WjRxbitQdUhxaGtqWkVraUdDTThWaENwOUEx bC9nWGpVQVMvNm0zOWVuRmgvUWpmMUY5QVJIYXViClQrUUVCNHEyeXQzZ21xSjc4dXVMZUZsL3ZP NklsREY2bnBRaUFpS2dFRUVvTWhIcjhGZG1ZeXc1ZjhkQXIvTGcKcTZJTERWVGRGMEU9Cj1aeFNW Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============1442862735281953641==--