Re: [linux-cifs-client] Re: SMB support still missing?
On Feb 8 2007 18:53, Christopher R. Hertel wrote: >>> >>> It does seem to me that it is some sort of name resolution issue, but it may >>> have more to do with the multi-homed nature of your setup. >>> >>> Did you try: >>> >>> mount.cifs //CL0/c /mnt >> >> Yes, that one _fails_ with "mount error 112 = Host is down" (though tcpdump >> _does_ show that cifs connects to port 139 and then disconnects using FIN) > >It would be interesting to see that capture. 01:39:02.089070 IP 192.168.222.94.2019 > 192.168.222.33.445: S 870214128:870214128(0) win 5840 0x: 4500 003c ca4d 4000 4006 329d c0a8 de5e E..<[EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 07e3 01bd 33de 69f0 ...!3.i. 0x0020: a002 16d0 a82c 0204 05b4 0402 080a .,.. 0x0030: 000c a3bd 0103 0301 01:39:02.092572 IP 192.168.222.33.445 > 192.168.222.94.2019: R 0:0(0) ack 870214129 win 0 0x: 4500 0028 f300 8006 09fe c0a8 de21 E..(...! 0x0010: c0a8 de5e 01bd 07e3 33de 69f1 ...^3.i. 0x0020: 5014 ca8f P. 01:39:02.096738 IP 192.168.222.94.1343 > 192.168.222.33.139: S 870214131:870214131(0) win 5840 0x: 4500 003c ca33 4000 4006 32b7 c0a8 de5e E..<[EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 053f 008b 33de 69f3 ...!.?..3.i. 0x0020: a002 16d0 abfc 0204 05b4 0402 080a 0x0030: 000c a3c0 0103 0301 01:39:02.102544 IP 192.168.222.33.139 > 192.168.222.94.1343: S 4435509:4435509(0) ack 870214132 win 8760 0x: 4500 0030 f400 4000 8006 c8f5 c0a8 de21 [EMAIL PROTECTED] 0x0010: c0a8 de5e 008b 053f 0043 ae35 33de 69f4 ...^...?.C.53.i. 0x0020: 7012 2238 d0f0 0204 05b4 0101 0402 p."8 01:39:02.104880 IP 192.168.222.94.1343 > 192.168.222.33.139: . ack 1 win 5840 0x: 4500 0028 ca34 4000 4006 32ca c0a8 de5e E..([EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 053f 008b 33de 69f4 0043 ae36 ...!.?..3.i..C.6 0x0020: 5010 16d0 091d P... 01:39:02.117326 IP 192.168.222.94.1343 > 192.168.222.33.139: P 1:73(72) ack 1 win 5840 NBT Session Packet: Session Request 0x: 4500 0070 ca35 4000 4006 3281 c0a8 de5e [EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 053f 008b 33de 69f4 0043 ae36 ...!.?..3.i..C.6 0x0020: 5018 16d0 3e34 8100 0044 2043 4b46 P...>4.D.CKF 0x0030: 4445 4e45 4346 4445 4646 4346 4745 4646 DENECFDEFFCFGEFF 0x0040: 4343 4143 4143 4143 4143 4143 4100 2046 CCACACACACACA..F 0x0050: 4445 4c44 4143 4143 4143 4143 4143 4143 DELDACACACACACAC 0x0060: 4143 4143 4143 4143 4143 4143 4141 4100 ACACACACACACAAA. 01:39:02.121140 IP 192.168.222.33.139 > 192.168.222.94.1343: FP 1:6(5) ack 73 win 8688 NBT Session Packet: [|SMB] 0x: 4500 002d f500 4000 8006 c7f8 c0a8 de21 [EMAIL PROTECTED] 0x0010: c0a8 de5e 008b 053f 0043 ae36 33de 6a3c ...^...?.C.63.j< 0x0020: 5019 21f0 f8a4 8300 0001 8253 P.!..S 01:39:02.162638 IP 192.168.222.94.1343 > 192.168.222.33.139: . ack 7 win 5840 0x: 4500 0028 ca36 4000 4006 32c8 c0a8 de5e E..([EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 053f 008b 33de 6a3c 0043 ae3c ...!.?..3.j<.C.< 0x0020: 5010 16d0 08cf P... 01:39:02.173013 IP 192.168.222.94.1343 > 192.168.222.33.139: P 73:155(82) ack 7 win 5840 NBT Session Packet: Session Message 0x: 4500 007a ca37 4000 4006 3275 c0a8 de5e [EMAIL PROTECTED]@.2u...^ 0x0010: c0a8 de21 053f 008b 33de 6a3c 0043 ae3c ...!.?..3.j<.C.< 0x0020: 5018 16d0 3e3e 004e ff53 4d42 P...>>.N.SMB 0x0030: 7200 0180 r... 0x0040: 950d 0100 002b 0002 .+.. 0x0050: 4c4d 312e 3258 3030 3200 024c 414e 4d41 LM1.2X002..LANMA 0x0060: 4e32 2e31 0002 4e54 204c 4d20 302e 3132 N2.1..NT.LM.0.12 0x0070: 0002 504f 5349 5820 3200 ..POSIX.2. 01:39:02.317447 IP 192.168.222.94.1343 > 192.168.222.33.139: R 155:155(0) ack 7 win 5840 0x: 4500 0028 ca38 4000 4006 32c6 c0a8 de5e E..([EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 053f 008b 33de 6a8e 0043 ae3c ...!.?..3.j..C.< 0x0020: 5014 16d0 0879 Py.. Jan -- ft: http://freshmeat.net/p/chaostables/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
On Feb 8 2007 18:58, Christopher R. Hertel wrote: >Shirish S Pargaonkar wrote: >> >> So >> 1) try tcp connection on 445, >> then if it works send SMB negprot >> 2) else try tcp connection on port 139 >> then if it works send nbss request to *SMBSERVER or to the name >> specified on servernetbiosname >> (cifs really should do an ASTAT command and list the valid names and >> find one if that approach fails but we don't have code for this yet) > >This is all correct, and also note that W/9x systems do not support the >"*SMBSERVER" name. > >On the other hand, the name was resolved somehow. The typical work-arounds >to not knowning the NBT name of the server are: >1) Use the name you just resolved (in this case, "CL0"). >2) Send a Node Status Query and look for the first unique <20> name. I'd just do this: (1) try 445/tcp (2) try 139/tcp (3) try 139/tcp with uppercase hostname (mount //hostname/share) as default servernetbiosname Jan -- ft: http://freshmeat.net/p/chaostables/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
Shirish S Pargaonkar wrote: : > This is what Steve had mailed me once, a while ago > > Win9x and Windows ME and OS/2 only listen on port 139 > > WindowsNT 4 (?) and later listen on port 445 and port 139. > > When you connect on the older port 139, you are supposed to send a > RFC1001 (NBSS Session Request to indicate your client netbios name, but > the problem is that you don't know the target netbios name of the server > - which is why the either needs to support the fake name "*SMBSERVER" or > the client needs to specify the "servernetbiosname=" option on > mount to identify which name on the server to try to connect to. > > So > 1) try tcp connection on 445, > then if it works send SMB negprot > 2) else try tcp connection on port 139 > then if it works send nbss request to *SMBSERVER or to the name > specified on servernetbiosname > (cifs really should do an ASTAT command and list the valid names and > find one if that approach fails but we don't have code for this yet) This is all correct, and also note that W/9x systems do not support the "*SMBSERVER" name. On the other hand, the name was resolved somehow. The typical work-arounds to not knowning the NBT name of the server are: 1) Use the name you just resolved (in this case, "CL0"). 2) Send a Node Status Query and look for the first unique <20> name. The second (as Steve explained to me a long time ago) is less reliable because there are some applications out there which (incorrectly) register names with a suffix byte of <20>. Chris -)- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
Jan Engelhardt wrote: > On Feb 8 2007 18:29, Christopher R. Hertel wrote: >> Jan Engelhardt wrote: >> >> It does seem to me that it is some sort of name resolution issue, but it may >> have more to do with the multi-homed nature of your setup. >> >> Did you try: >> >> mount.cifs //CL0/c /mnt > > Yes, that one _fails_ with "mount error 112 = Host is down" (though tcpdump > _does_ show that cifs connects to port 139 and then disconnects using FIN) It would be interesting to see that capture. - The client is clearly finding the server (via NBT lookup or DNS lookup--doesn't matter, it's being found). - The client is creating the TCP connection. - The server (W9x) is closing the connection. Why? + The most likely reason is 0x82: Called Name Not Present That's my guess, anyway. My bet is that W9x is being picky about the case of the CALLED NAME. It would not surprise me that the NBT name resolution code *does* convert the case as part of the NBT encoding (that weird string that reads EDEMDACACACACACACACACACACACACACA). It would also not surprise me if the NBT Session Request code *doesn't* convert the case. The Session Request uses the un-encoded string (in this case, "cl0"). The Windows 9x implementation of the NBT layer tends to be much more "correct" than the NT family and its descendants. As a result, W9x is pickier about things like exact matches to the CALLED NAME. That's all a guess, mind you, but it's something more to go on. Again, the capture would hold the answer. Chris -)- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
On Feb 8 2007 18:29, Christopher R. Hertel wrote: >Jan Engelhardt wrote: > >It does seem to me that it is some sort of name resolution issue, but it may >have more to do with the multi-homed nature of your setup. > >Did you try: > > mount.cifs //CL0/c /mnt Yes, that one _fails_ with "mount error 112 = Host is down" (though tcpdump _does_ show that cifs connects to port 139 and then disconnects using FIN) >If mount.cifs is not converting the case, that should fix the problem. >Curious to know... Jan -- ft: http://freshmeat.net/p/chaostables/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
Jan Engelhardt wrote: > Hi, > > > I tried the various suggestions from the last mails, but nothing of > that worked. --verbose did not return anything useful. It's the kernel > module that returns -EHOSTDOWN. > > ... > > Eventually I found out that this one works: > > mount.cifs //cl0/c /mnt -o servernetbiosname=CL0 > > So what did I change? Casing. Note that "CL0" is entirely uppercase. > Although strange, it actually coincides with how LANMAN works. > Everything is uppercased in lanman, hostnames, usernames, heck, even > plaintext passwords (samba-smbd has a good time trying a ton of > combinations in such setups). > > No other options like sec=none or thelike were needed. Login as > anonymous worked directly. > > > Please consider updating the cifs kernel module to account for the LM > oddity of uppercasing things. (Then, smbfs can finally be ripped out I > hope.) ...assuming that's really the problem. It does seem to me that it is some sort of name resolution issue, but it may have more to do with the multi-homed nature of your setup. Did you try: mount.cifs //CL0/c /mnt ? If mount.cifs is not converting the case, that should fix the problem. Curious to know... Chris -)- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[linux-cifs-client] Re: SMB support still missing?
Hi, I tried the various suggestions from the last mails, but nothing of that worked. --verbose did not return anything useful. It's the kernel module that returns -EHOSTDOWN. ... Eventually I found out that this one works: mount.cifs //cl0/c /mnt -o servernetbiosname=CL0 So what did I change? Casing. Note that "CL0" is entirely uppercase. Although strange, it actually coincides with how LANMAN works. Everything is uppercased in lanman, hostnames, usernames, heck, even plaintext passwords (samba-smbd has a good time trying a ton of combinations in such setups). No other options like sec=none or thelike were needed. Login as anonymous worked directly. Please consider updating the cifs kernel module to account for the LM oddity of uppercasing things. (Then, smbfs can finally be ripped out I hope.) Jan -- ft: http://freshmeat.net/p/chaostables/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[linux-cifs-client] Re: SMB support still missing?
Hi, I tried the various suggestions from the last mails, but nothing of that worked. --verbose did not return anything useful. It's the kernel module that returns -EHOSTDOWN. ... Eventually I found out that this one works: mount.cifs //cl0/c /mnt -o servernetbiosname=CL0 So what did I change? Casing. Note that CL0 is entirely uppercase. Although strange, it actually coincides with how LANMAN works. Everything is uppercased in lanman, hostnames, usernames, heck, even plaintext passwords (samba-smbd has a good time trying a ton of combinations in such setups). No other options like sec=none or thelike were needed. Login as anonymous worked directly. Please consider updating the cifs kernel module to account for the LM oddity of uppercasing things. (Then, smbfs can finally be ripped out I hope.) Jan -- ft: http://freshmeat.net/p/chaostables/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
Jan Engelhardt wrote: Hi, I tried the various suggestions from the last mails, but nothing of that worked. --verbose did not return anything useful. It's the kernel module that returns -EHOSTDOWN. ... Eventually I found out that this one works: mount.cifs //cl0/c /mnt -o servernetbiosname=CL0 So what did I change? Casing. Note that CL0 is entirely uppercase. Although strange, it actually coincides with how LANMAN works. Everything is uppercased in lanman, hostnames, usernames, heck, even plaintext passwords (samba-smbd has a good time trying a ton of combinations in such setups). No other options like sec=none or thelike were needed. Login as anonymous worked directly. Please consider updating the cifs kernel module to account for the LM oddity of uppercasing things. (Then, smbfs can finally be ripped out I hope.) ...assuming that's really the problem. It does seem to me that it is some sort of name resolution issue, but it may have more to do with the multi-homed nature of your setup. Did you try: mount.cifs //CL0/c /mnt ? If mount.cifs is not converting the case, that should fix the problem. Curious to know... Chris -)- -- Implementing CIFS - the Common Internet FileSystem ISBN: 013047116X Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
On Feb 8 2007 18:29, Christopher R. Hertel wrote: Jan Engelhardt wrote: It does seem to me that it is some sort of name resolution issue, but it may have more to do with the multi-homed nature of your setup. Did you try: mount.cifs //CL0/c /mnt Yes, that one _fails_ with mount error 112 = Host is down (though tcpdump _does_ show that cifs connects to port 139 and then disconnects using FIN) If mount.cifs is not converting the case, that should fix the problem. Curious to know... Jan -- ft: http://freshmeat.net/p/chaostables/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
Jan Engelhardt wrote: On Feb 8 2007 18:29, Christopher R. Hertel wrote: Jan Engelhardt wrote: It does seem to me that it is some sort of name resolution issue, but it may have more to do with the multi-homed nature of your setup. Did you try: mount.cifs //CL0/c /mnt Yes, that one _fails_ with mount error 112 = Host is down (though tcpdump _does_ show that cifs connects to port 139 and then disconnects using FIN) It would be interesting to see that capture. - The client is clearly finding the server (via NBT lookup or DNS lookup--doesn't matter, it's being found). - The client is creating the TCP connection. - The server (W9x) is closing the connection. Why? + The most likely reason is 0x82: Called Name Not Present That's my guess, anyway. My bet is that W9x is being picky about the case of the CALLED NAME. It would not surprise me that the NBT name resolution code *does* convert the case as part of the NBT encoding (that weird string that reads EDEMDACACACACACACACACACACACACACA). It would also not surprise me if the NBT Session Request code *doesn't* convert the case. The Session Request uses the un-encoded string (in this case, cl0). The Windows 9x implementation of the NBT layer tends to be much more correct than the NT family and its descendants. As a result, W9x is pickier about things like exact matches to the CALLED NAME. That's all a guess, mind you, but it's something more to go on. Again, the capture would hold the answer. Chris -)- -- Implementing CIFS - the Common Internet FileSystem ISBN: 013047116X Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
Shirish S Pargaonkar wrote: : This is what Steve had mailed me once, a while ago Win9x and Windows ME and OS/2 only listen on port 139 WindowsNT 4 (?) and later listen on port 445 and port 139. When you connect on the older port 139, you are supposed to send a RFC1001 (NBSS Session Request to indicate your client netbios name, but the problem is that you don't know the target netbios name of the server - which is why the either needs to support the fake name *SMBSERVER or the client needs to specify the servernetbiosname=name option on mount to identify which name on the server to try to connect to. So 1) try tcp connection on 445, then if it works send SMB negprot 2) else try tcp connection on port 139 then if it works send nbss request to *SMBSERVER or to the name specified on servernetbiosname (cifs really should do an ASTAT command and list the valid names and find one if that approach fails but we don't have code for this yet) This is all correct, and also note that W/9x systems do not support the *SMBSERVER name. On the other hand, the name was resolved somehow. The typical work-arounds to not knowning the NBT name of the server are: 1) Use the name you just resolved (in this case, CL0). 2) Send a Node Status Query and look for the first unique 20 name. The second (as Steve explained to me a long time ago) is less reliable because there are some applications out there which (incorrectly) register names with a suffix byte of 20. Chris -)- -- Implementing CIFS - the Common Internet FileSystem ISBN: 013047116X Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
On Feb 8 2007 18:58, Christopher R. Hertel wrote: Shirish S Pargaonkar wrote: So 1) try tcp connection on 445, then if it works send SMB negprot 2) else try tcp connection on port 139 then if it works send nbss request to *SMBSERVER or to the name specified on servernetbiosname (cifs really should do an ASTAT command and list the valid names and find one if that approach fails but we don't have code for this yet) This is all correct, and also note that W/9x systems do not support the *SMBSERVER name. On the other hand, the name was resolved somehow. The typical work-arounds to not knowning the NBT name of the server are: 1) Use the name you just resolved (in this case, CL0). 2) Send a Node Status Query and look for the first unique 20 name. I'd just do this: (1) try 445/tcp (2) try 139/tcp (3) try 139/tcp with uppercase hostname (mount //hostname/share) as default servernetbiosname Jan -- ft: http://freshmeat.net/p/chaostables/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: SMB support still missing?
On Feb 8 2007 18:53, Christopher R. Hertel wrote: It does seem to me that it is some sort of name resolution issue, but it may have more to do with the multi-homed nature of your setup. Did you try: mount.cifs //CL0/c /mnt Yes, that one _fails_ with mount error 112 = Host is down (though tcpdump _does_ show that cifs connects to port 139 and then disconnects using FIN) It would be interesting to see that capture. 01:39:02.089070 IP 192.168.222.94.2019 192.168.222.33.445: S 870214128:870214128(0) win 5840 mss 1460,sackOK,timestamp 828349 0,nop,wscale 1 0x: 4500 003c ca4d 4000 4006 329d c0a8 de5e E..[EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 07e3 01bd 33de 69f0 ...!3.i. 0x0020: a002 16d0 a82c 0204 05b4 0402 080a .,.. 0x0030: 000c a3bd 0103 0301 01:39:02.092572 IP 192.168.222.33.445 192.168.222.94.2019: R 0:0(0) ack 870214129 win 0 0x: 4500 0028 f300 8006 09fe c0a8 de21 E..(...! 0x0010: c0a8 de5e 01bd 07e3 33de 69f1 ...^3.i. 0x0020: 5014 ca8f P. 01:39:02.096738 IP 192.168.222.94.1343 192.168.222.33.139: S 870214131:870214131(0) win 5840 mss 1460,sackOK,timestamp 828352 0,nop,wscale 1 0x: 4500 003c ca33 4000 4006 32b7 c0a8 de5e E..[EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 053f 008b 33de 69f3 ...!.?..3.i. 0x0020: a002 16d0 abfc 0204 05b4 0402 080a 0x0030: 000c a3c0 0103 0301 01:39:02.102544 IP 192.168.222.33.139 192.168.222.94.1343: S 4435509:4435509(0) ack 870214132 win 8760 mss 1460,nop,nop,sackOK 0x: 4500 0030 f400 4000 8006 c8f5 c0a8 de21 [EMAIL PROTECTED] 0x0010: c0a8 de5e 008b 053f 0043 ae35 33de 69f4 ...^...?.C.53.i. 0x0020: 7012 2238 d0f0 0204 05b4 0101 0402 p.8 01:39:02.104880 IP 192.168.222.94.1343 192.168.222.33.139: . ack 1 win 5840 0x: 4500 0028 ca34 4000 4006 32ca c0a8 de5e E..([EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 053f 008b 33de 69f4 0043 ae36 ...!.?..3.i..C.6 0x0020: 5010 16d0 091d P... 01:39:02.117326 IP 192.168.222.94.1343 192.168.222.33.139: P 1:73(72) ack 1 win 5840 NBT Session Packet: Session Request 0x: 4500 0070 ca35 4000 4006 3281 c0a8 de5e [EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 053f 008b 33de 69f4 0043 ae36 ...!.?..3.i..C.6 0x0020: 5018 16d0 3e34 8100 0044 2043 4b46 P...4.D.CKF 0x0030: 4445 4e45 4346 4445 4646 4346 4745 4646 DENECFDEFFCFGEFF 0x0040: 4343 4143 4143 4143 4143 4143 4100 2046 CCACACACACACA..F 0x0050: 4445 4c44 4143 4143 4143 4143 4143 4143 DELDACACACACACAC 0x0060: 4143 4143 4143 4143 4143 4143 4141 4100 ACACACACACACAAA. 01:39:02.121140 IP 192.168.222.33.139 192.168.222.94.1343: FP 1:6(5) ack 73 win 8688 NBT Session Packet: [|SMB] 0x: 4500 002d f500 4000 8006 c7f8 c0a8 de21 [EMAIL PROTECTED] 0x0010: c0a8 de5e 008b 053f 0043 ae36 33de 6a3c ...^...?.C.63.j 0x0020: 5019 21f0 f8a4 8300 0001 8253 P.!..S 01:39:02.162638 IP 192.168.222.94.1343 192.168.222.33.139: . ack 7 win 5840 0x: 4500 0028 ca36 4000 4006 32c8 c0a8 de5e E..([EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 053f 008b 33de 6a3c 0043 ae3c ...!.?..3.j.C. 0x0020: 5010 16d0 08cf P... 01:39:02.173013 IP 192.168.222.94.1343 192.168.222.33.139: P 73:155(82) ack 7 win 5840 NBT Session Packet: Session Message 0x: 4500 007a ca37 4000 4006 3275 c0a8 de5e [EMAIL PROTECTED]@.2u...^ 0x0010: c0a8 de21 053f 008b 33de 6a3c 0043 ae3c ...!.?..3.j.C. 0x0020: 5018 16d0 3e3e 004e ff53 4d42 PN.SMB 0x0030: 7200 0180 r... 0x0040: 950d 0100 002b 0002 .+.. 0x0050: 4c4d 312e 3258 3030 3200 024c 414e 4d41 LM1.2X002..LANMA 0x0060: 4e32 2e31 0002 4e54 204c 4d20 302e 3132 N2.1..NT.LM.0.12 0x0070: 0002 504f 5349 5820 3200 ..POSIX.2. 01:39:02.317447 IP 192.168.222.94.1343 192.168.222.33.139: R 155:155(0) ack 7 win 5840 0x: 4500 0028 ca38 4000 4006 32c6 c0a8 de5e E..([EMAIL PROTECTED]@.2^ 0x0010: c0a8 de21 053f 008b 33de 6a8e 0043 ae3c ...!.?..3.j..C. 0x0020: 5014 16d0 0879 Py.. Jan -- ft: http://freshmeat.net/p/chaostables/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
